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

[Gerd Hoffmann <kraxel@redhat.com>]

  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