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

[Sam Eiderman]

On 13 Jun 2019, at 12:38, Gerd Hoffmann <address@hidden> 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