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

[Sam Eiderman <shmuel.eiderman@oracle.com>]

> On 12 Jun 2019, at 16:06, Gerd Hoffmann <kraxel@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.

> 
>> 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,
or letting the user set these values manually.

> 
> 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.
Much like smbios, acpi and mptables - I believe that the correct place to
use MBR guessing is QEMU (which already has one, with some issues)
and pass the guess using fw_cfg - this will allow using the compat system
in qemu itself.

Sam

> 
> cheers,
>  Gerd
>