Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface

[Sam Eiderman]

typo:
ddb.geometry.biosCylinders = “83257” *

Sam

> On 13 Jun 2019, at 10:41, Sam Eiderman <address@hidden> wrote:
> 
> 
> 
>> On 12 Jun 2019, at 22:18, Gerd Hoffmann <address@hidden 
>> <mailto:address@hidden>> wrote:
>> 
>> On Wed, Jun 12, 2019 at 04:30:03PM +0300, Sam Eiderman wrote:
>>> 
>>> 
>>>> On 12 Jun 2019, at 16:06, Gerd Hoffmann <address@hidden 
>>>> <mailto:address@hidden>> wrote:
>>>> 
>>>> On Wed, Jun 12, 2019 at 02:59:31PM +0300, Sam Eiderman wrote:
>>>>> v1:
>>>>> 
>>>>> Non-standard logical geometries break under QEMU.
>>>>> 
>>>>> A virtual disk which contains an operating system which depends on
>>>>> logical geometries (consistent values being reported from BIOS INT13
>>>>> AH=08) will most likely break under QEMU/SeaBIOS if it has non-standard
>>>>> logical geometries - for example 56 SPT (sectors per track).
>>>>> No matter what QEMU will guess - SeaBIOS, for large enough disks - will
>>>>> use LBA translation, which will report 63 SPT instead.
>>>> 
>>>> --verbose please.
>>>> 
>>>> As far I know seabios switches to LBA mode when the disk is simply too
>>>> big for LCHS addressing.  So I fail to see which problem is solved by
>>>> this.  If your guest needs LCHS, why do you assign a disk which can't
>>>> be fully accessed using LCHS addressing?
>>> 
>>> The scenario is as follows:
>>> 
>>> A user has a disk with 56 spts.
>>> This disk has been already created under a bios that reported 56 spts.
>>> When migrating this disk to QEMU/SeaBIOS, SeaBIOS will report 63 spts
>>> (under LBA translation) - this will break the boot for this guest.
>> 
>> You sayed so already.  I was looking for a real world example.  Guests
>> which can't deal with LBA should be pretty rare these days.  What kind
>> of guest?  What other bios?  Or is this a purely theoretical issue?
> 
> Yes they are pretty rare.
> Windows 2000 and Windows XP guests migrated from VMware to Qemu/KVM
> would not boot due to incorrect disk geometries (some had 32/56 spt instead of
> 56. Also number of heads was not entirely correct)
> 
>> 
>>>>> In addition we can not enforce SeaBIOS to rely on phyiscal geometries at
>>>>> all. A virtio-blk-pci virtual disk with 255 phyiscal heads can not
>>>>> report more than 16 physical heads when moved to an IDE controller, the
>>>>> ATA spec allows a maximum of 16 heads - this is an artifact of
>>>>> virtualization.
>>>> 
>>>> Well, not really.  Moving disks from one controller to another when the
>>>> OS depends on LHCS addressing never is a good idea.  That already caused
>>>> problems in the 90-ies, when moving scsi disks from one scsi host
>>>> adapter to another type, *way* before virtualization became a thing.
>>> 
>>> I agree, but this is easily solvable in virtualized environments where the
>>> hypervisor can guess the correct LCHS values by inspecting the MBR,
>> 
>> Yes.  This is exactly what the more clever scsi host adapter int13 rom
>> implementations ended up doing too.  Look at MBR to figure which LCHS
>> they should use.
>> 
>>> or letting the user set these values manually.
>> 
>> Why?  Asking the user to deal with the mess is pretty lame if there are
>> better options.  And IMO doing this fully automatic in seabios is
>> better.
> 
> I’m not against an automatic approach, however I do think that doing this
> in SeaBIOS might break compatibility for already existing guests that will
> suddenly see different LCHS values. (Explanation below)
> 
> Notice that already today it is possible to pass “cyls", “heads", “sectors” 
> and
> even “chs-trans” (IDE only) for devices in QEMU, but these are only the
> physical geometries of the disks which later on SeaBIOS might use to
> determine the logical geometries.
> "chs-trans" is an already existing PV interface between QEMU and
> SeaBIOS for that matter (although it only supports 4 IDE disks).
> 
> I believe that the steps to bring this issue to a more stable state are:
> Create a PV interface between QEMU and SeaBIOS to pass LCHS (Implemented here)
> Allow users to manually set values for LCHS values in QEMU (Implemented here)
> (Up until here, we do not break any existing functionality)
> Implement a better LCHS guessing algorithm in QEMU - the existing ones 
> contains some issues
> On new machine versions - pass guessed LCHS directly to SeaBIOS
> At the moment QEMU does not propagate its MBR guessed LCHS values, but only 
> uses them to set PCHS values for disks - so SeaBIOS has to guess again
> (Also here we will not break compatibility for older machine versions)
> 
> In addition, QEMU allows the use of VMDKs, some VMDK descriptors contain the 
> following values:
>     ddb.geometry.biosHeads = “16”
>     ddb.geometry.biosHeads = “83257”
> Which override the guessing algorithm in VMware and request the following 
> values to be set.
> 
> Providing such PV interface will allow to support these VMDKs too.
> 
>> 
>>>> BTW:  One possible way to figure which LCHS layout a disk uses is to
>>>> check the MBR partition table.  With that we (a) don't need a new
>>>> interface between qemu and seabios and (b) it is not needed to manually
>>>> specify the geometry.
>>> 
>>> In my opinion SeaBIOS is not the correct place for this change since
>>> “enhancing” the detection of LCHS values in SeaBIOS may cause it to
>>> suddenly report different values for already existing guests which rely on
>>> LCHS - thus, breaking compatibility.
>> 
>> I can't see how this can break guests.  It should either have no effect
>> (guests using LBA) or unbreak guests due to LCHS changing from "wrong"
>> to "correct”.
> 
> I’m not sure what do you mean by "unbreak guests” if you change an existing
> guest that uses LCHS from 56 spt to LBA (63 spt) it will stop booting.
> Your guessing algorithm will have to guess 56, if it will fail guessing 56 
> correctly,
> the user can not perform any action beside downgrading SeaBIOS in order to run
> the guest.
> 
> Sam
> 
>> 
>> cheers,
>>  Gerd