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

[Sam Eiderman]

> On 17 Jun 2019, at 9:50, Gerd Hoffmann  wrote:
> 
>  Hi,
> 
>>> Ok, given that seabios has no setup any manual configuration needs to be 
>>> done via qemu.
>>> 
>>> But why do we need a new interface for that?  IDE can pass the geometry
>>> to the guest.  virtio-blk has support too (VIRTIO_BLK_F_GEOMETRY).
>>> Likewise scsi (MODE_PAGE_HD_GEOMETRY).  So this should be doable without
>>> any qemu changes.
>> 
>> This was indeed considered (all 3 methods) but it has the following issues:
>> 
>> Physical geometries of devices must now also be logical geometries with 
>> translation=none.
> 
> Yes.
> 
>> When the OS will query these devices - It will now see different physical 
>> geometries, adapted to be logical geometries.
> 
> Yes.
> 
>> I’m not sure even how to implement this without breaking existing
>> compatibility - since we don’t want to affect logical geometries of
>> currently used guests.
> 
> We can copy the logic which calculates lchs from seabios to qemu and use
> it for pchs.
> 
> The tricky part of this is how to do the switch without requiring a
> lockstep update of seabios and qemu.  seabios can't easily know whenever
> it should use the current logic (current qemu) or whenever it should
> simply use pchs with translation=none (updated qemu).
> 
> Hmm ...
> 
>> MODE_PAGE_HD_GEOMETRY does not contain the spts, only cylinders (as 3
>> byte number) and heads (as 1 byte number) and computes the spts using:
> 
> Well, there also is MODE_PAGE_FLEXIBLE_DISK_GEOMETRY.
> 
>> Moving a scsi-hd/virtio-blk with 255 physical heads to ide-hd, we will
>> still need to report 255 heads - this is possible since a whole byte
>> can be used in the “ide identify” command, but goes against the spec
>> of a maximum of 16 heads for IDE.
> 
> Why do you want migrate _to_ IDE?

Even without migration, now under SeaBIOS probably most IDE disks
report 255 heads and 63 spts due to LBA translation, while exposing
up to 16 physical heads (IDE spec).
So you can’t really report in ATA identify command your wanted logical
heads (255).

This can be solved in a very complicated way:

For virtio-blk disks - report bios geometries as physical geometries.
This might break current compatibility (showing different physical geometries)
For scsi disks - report bios geometries as physical geometries.
Implement MODE_PAGE_FLEXIBLE_DISK_GEOMETRY and translation=none - this new 
interface will help with compatibility
For IDE disks - specially craft valid physical geometries (heads <= 16) with a 
specific translation,
This is super complicated, for example to make an IDE disk report lchs of 32 
heads, 56 spts, you need a physical geometry of 16 heads, 56 spts and report 
2046 cylinders with a "large" translation - which will effectively cut down the 
number of cylinders by 2 to 1023 and multiply the heads by 2 to 32, achieving 
the desired lchs. Also we can not even make an IDE report 255 heads with 56 
spts with any translation (this is an actual value from production) - so the 
disk must be moved to scsi-hd/virtio-blk - which also breaks compatibility.

This implementation creates 3 different non conventional (PV) ways of reporting 
lchs directly between Qemu and SeaBIOS - which add a lot of technical depth for 
resolving a legacy issue. A fw-cfg value named “bootdevices” (or 
“bios-geometry”) is much more straightforward and makes it more 
readable/explicit.

WDYT?

> 
>> Overall this approach is much more complicated.
> 
> Well, adding new fw_cfg interfaces has a long term maintenance cost.
> So there should be a pretty good reason for them.
> 
> cheers,
>  Gerd
> 

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

[Gerd Hoffmann]

  Hi,

> > Ok, given that seabios has no setup any manual configuration needs to be 
> > done via qemu.
> > 
> > But why do we need a new interface for that?  IDE can pass the geometry
> > to the guest.  virtio-blk has support too (VIRTIO_BLK_F_GEOMETRY).
> > Likewise scsi (MODE_PAGE_HD_GEOMETRY).  So this should be doable without
> > any qemu changes.
> 
> This was indeed considered (all 3 methods) but it has the following issues:
> 
> Physical geometries of devices must now also be logical geometries with 
> translation=none.

Yes.

> When the OS will query these devices - It will now see different physical 
> geometries, adapted to be logical geometries.

Yes.

> I’m not sure even how to implement this without breaking existing
> compatibility - since we don’t want to affect logical geometries of
> currently used guests.

We can copy the logic which calculates lchs from seabios to qemu and use
it for pchs.

The tricky part of this is how to do the switch without requiring a
lockstep update of seabios and qemu.  seabios can't easily know whenever
it should use the current logic (current qemu) or whenever it should
simply use pchs with translation=none (updated qemu).

Hmm ...

> MODE_PAGE_HD_GEOMETRY does not contain the spts, only cylinders (as 3
> byte number) and heads (as 1 byte number) and computes the spts using:

Well, there also is MODE_PAGE_FLEXIBLE_DISK_GEOMETRY.

> Moving a scsi-hd/virtio-blk with 255 physical heads to ide-hd, we will
> still need to report 255 heads - this is possible since a whole byte
> can be used in the “ide identify” command, but goes against the spec
> of a maximum of 16 heads for IDE.

Why do you want migrate _to_ IDE?

> Overall this approach is much more complicated.

Well, adding new fw_cfg interfaces has a long term maintenance cost.
So there should be a pretty good reason for them.

cheers,
  Gerd

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

[Sam Eiderman]

> On 14 Jun 2019, at 7:43, Gerd Hoffmann  wrote:
> 
>  Hi,
> 
>> 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.
> 
> Ok, given that seabios has no setup any manual configuration needs to be done 
> via qemu.
> 
> But why do we need a new interface for that?  IDE can pass the geometry
> to the guest.  virtio-blk has support too (VIRTIO_BLK_F_GEOMETRY).
> Likewise scsi (MODE_PAGE_HD_GEOMETRY).  So this should be doable without
> any qemu changes.

This was indeed considered (all 3 methods) but it has the following issues:

Physical geometries of devices must now also be logical geometries with 
translation=none.
When the OS will query these devices - It will now see different physical 
geometries, adapted to be logical geometries.
I’m not sure even how to implement this without breaking existing compatibility 
- since we don’t want to affect logical geometries of currently used guests.
MODE_PAGE_HD_GEOMETRY does not contain the spts, only cylinders (as 3 byte 
number) and heads (as 1 byte number) and computes the spts using: 
number_of_total_sectors / (heads * cylinders), this means that qemu now must 
report number_of_total_sectors as heads * cylinders * spt for SeaBIOS to 
correctly receive the number of spts - this is not optimal since 
number_of_total_sectors can not reflect the real amount of sectors in the disk 
which should be reported from CDB_CMD_READ_CAPACITY.
Moving a scsi-hd/virtio-blk with 255 physical heads to ide-hd, we will still 
need to report 255 heads - this is possible since a whole byte can be used in 
the “ide identify” command, but goes against the spec of a maximum of 16 heads 
for IDE.

Overall this approach is much more complicated.

Sam

> 
> cheers,
>  Gerd
> 

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

[Gerd Hoffmann]

  Hi,

> 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.

Ok, given that seabios has no setup any manual configuration needs to be done 
via qemu.

But why do we need a new interface for that?  IDE can pass the geometry
to the guest.  virtio-blk has support too (VIRTIO_BLK_F_GEOMETRY).
Likewise scsi (MODE_PAGE_HD_GEOMETRY).  So this should be doable without
any qemu changes.

cheers,
  Gerd

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

[Sam Eiderman]

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

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

[Gerd Hoffmann]

  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.

> 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.

cheers,
  Gerd

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

[Sam Eiderman]

typo:
ddb.geometry.biosCylinders = “83257” *

Sam

> On 13 Jun 2019, at 10:41, Sam Eiderman  wrote:
> 
> 
> 
>> On 12 Jun 2019, at 22:18, Gerd Hoffmann > > wrote:
>> 
>> On Wed, Jun 12, 2019 at 04:30:03PM +0300, Sam Eiderman wrote:
>>> 
>>> 
 On 12 Jun 2019, at 16:06, Gerd Hoffmann >>> > 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 

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

[Sam Eiderman]

> On 12 Jun 2019, at 22:18, Gerd Hoffmann  wrote:
> 
> On Wed, Jun 12, 2019 at 04:30:03PM +0300, Sam Eiderman wrote:
>> 
>> 
>>> On 12 Jun 2019, at 16:06, Gerd Hoffmann  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

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

[Gerd Hoffmann]

On Wed, Jun 12, 2019 at 04:30:03PM +0300, Sam Eiderman wrote:
> 
> 
> > On 12 Jun 2019, at 16:06, Gerd Hoffmann  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?

> >> 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.

> > 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".

cheers,
  Gerd

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

[Sam Eiderman]

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

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

[Gerd Hoffmann]

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?

> 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.

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.

cheers,
  Gerd

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

[Sam Eiderman]

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.

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.

By supplying the logical geometies directly we are able to support such
"exotic" disks.

We will use fw_cfg to do just that.

v2:

Fix missing parenthesis check in
"hd-geo-test: Add tests for lchs override"

Sam Eiderman (8):
  block: Refactor macros - fix tabbing
  block: Support providing LCHS from user
  bootdevice: Add interface to gather LCHS
  scsi: Propagate unrealize() callback to scsi-hd
  bootdevice: Gather LCHS from all relevant devices
  bootdevice: Refactor get_boot_devices_list
  bootdevice: FW_CFG interface for LCHS values
  hd-geo-test: Add tests for lchs override

 bootdevice.c | 158 ++---
 hw/block/virtio-blk.c|   6 +
 hw/ide/qdev.c|   7 +-
 hw/nvram/fw_cfg.c|  14 +-
 hw/scsi/scsi-bus.c   |  15 ++
 hw/scsi/scsi-disk.c  |  14 ++
 include/hw/block/block.h |  22 +-
 include/hw/scsi/scsi.h   |   1 +
 include/sysemu/sysemu.h  |   4 +
 tests/Makefile.include   |   2 +-
 tests/hd-geo-test.c  | 565 +++
 11 files changed, 767 insertions(+), 41 deletions(-)

-- 
2.13.3