typo: ddb.geometry.biosCylinders = “83257” * Sam
> On 13 Jun 2019, at 10:41, Sam Eiderman <shmuel.eider...@oracle.com> wrote: > > > >> On 12 Jun 2019, at 22:18, Gerd Hoffmann <kra...@redhat.com >> <mailto:kra...@redhat.com>> wrote: >> >> On Wed, Jun 12, 2019 at 04:30:03PM +0300, Sam Eiderman wrote: >>> >>> >>>> On 12 Jun 2019, at 16:06, Gerd Hoffmann <kra...@redhat.com >>>> <mailto:kra...@redhat.com>> 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
