[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interfac
From: |
Sam Eiderman |
Subject: |
Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface |
Date: |
Thu, 13 Jun 2019 10:44:38 +0300 |
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
- [Qemu-devel] [QEMU] [PATCH v2 6/8] bootdevice: Refactor get_boot_devices_list, (continued)
- [Qemu-devel] [QEMU] [PATCH v2 6/8] bootdevice: Refactor get_boot_devices_list, Sam Eiderman, 2019/06/12
- [Qemu-devel] [QEMU] [PATCH v2 5/8] bootdevice: Gather LCHS from all relevant devices, Sam Eiderman, 2019/06/12
- [Qemu-devel] [QEMU] [PATCH v2 3/8] bootdevice: Add interface to gather LCHS, Sam Eiderman, 2019/06/12
- [Qemu-devel] [QEMU] [PATCH v2 2/8] block: Support providing LCHS from user, Sam Eiderman, 2019/06/12
- [Qemu-devel] [QEMU] [PATCH v2 1/8] block: Refactor macros - fix tabbing, Sam Eiderman, 2019/06/12
- Re: [Qemu-devel] [SeaBIOS] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface, no-reply, 2019/06/12
- Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface, Gerd Hoffmann, 2019/06/12
- Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface, Sam Eiderman, 2019/06/12
- Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface, Gerd Hoffmann, 2019/06/12
- Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface, Sam Eiderman, 2019/06/13
- Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface,
Sam Eiderman <=
- Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface, Gerd Hoffmann, 2019/06/13
- Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface, Sam Eiderman, 2019/06/13
- Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface, Gerd Hoffmann, 2019/06/14
- Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface, Sam Eiderman, 2019/06/14
- Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface, Gerd Hoffmann, 2019/06/17
- Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface, Sam Eiderman, 2019/06/17
Re: [Qemu-devel] [SeaBIOS] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface, no-reply, 2019/06/12