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

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

> On 13 Jun 2019, at 12:38, Gerd Hoffmann <kraxel@redhat.com> wrote:
> 
>  Hi,
> 
>> 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)
> 
> Ok.
> 
>>> 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)
> 
>>> 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.
> 
> Well, that LCHS change happens because you move the guest from vmware to
> qemu and seabios uses 63 spt no matter what if the disk is too big for
> chs addressing.
> 
> When seabios is changed to look at the MBR to figure what the lchs of
> the disk is that will make your guest boot.

See below

> 
>> 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.
> 
> Sure, if the guess is wrong then the guest will not boot.  That isn't
> worse than the situation we have today where seabios will not even try
> to figure what the lchs of the disk is.
> 
> And, no, downgrading seabios will not make your vmware guest with 56 spt
> boot.

I’m not talking about the vmware case here.
If you introduce MBR guessing into SeaBIOS and change its default behaviour you
risk making operating systems such as Windows XP / 2003 / 2000 created on
QEMU to not work anymore.

Example:

	Consider a Windows XP that works with the following geometries on standard
	QEMU/SeaBIOS today:
	
	Disk is very large, therefore INT13 AH=02:

		255 heads, 63 spt

	Now you change SeaBIOS to guess from the MBR.
	In some cases the MBR guess can be incorrect so now SeaBIOS will guess:

		255 heads, 62 spt

	The guest no longer boots with these geometries and you broke compatibility.
	
Can there be a guest that will fail the MBR in such a way? Yes.
Look at the following MBR partition table of a Windows XP guest in our production
environment:

Disk size in sectors: 16777216

Binary (only one partition 16 bytes): 80 01 01 00 07 fe ff ff 3f 00 00 00 d5 ea ff 00
Start: (0, 1, 1, 63)
End: (1023, 254, 63, 16771859)

As can be easily seen, any MBR guessing algorithm should guess:

	255 heads (since a value of 254 appears), 63 spt (since a value of 63 appears)

Turns out that this image does not work with 255, 63 but actually requires

	16 heads, 63 spt

to boot.

So relying on MBR partitions alone is not always enough and sometimes manual intervention
is required.

(VMware solves this by specifying 16 heads, 63 spt in the descriptor file and overrides its
default guessing algorithm which also fails here)

(By the way this is not a VMware specific problem, the disk itself was imported to VMware in
a P2V scenario, so that probably explains why the ddb.geometry.bios* values appear in the
VMDK in the first place)


> 
> cheers,
>  Gerd
>