[SeaBIOS] [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support

[Paolo Bonzini]

> > (4) would be acceptable I guess.  However I think it's a bit worse
> > because fw-cfg files are a somewhat scarce resource.  The "legacy"
> > aspect is something that SeaBIOS is in the best position to address,
> > because it knows what OSes are running on it; QEMU instead only takes
> > care of describing the hardware.
> 
> SeaBIOS is used with both modern and legacy OSes, and it doesn't have
> any knowledge about what kind of OS will be used.  If anything, I'd
> argue that QEMU has more knowledge about the guest OS than SeaBIOS
> does (due to command-line options like machine version).

No, the machine type is independent from the guest OS.  The aim is to
let "qemu-system-x86_64 -m MEMORYSZ image.qcow2" work just fine with
every guest OS.

> As I see it, fundamentally the proposal here is to deploy different
> ACPI tables when using SeaBIOS then when using OVMF.  I think that's
> fine, but I think we should directly address that issue then.

The different ACPI tables are essentially a bug in OVMF.  They can be
fixed to be the same.

> Specifically, I have the following concerns with the original approach:
> 
> A - It would require deploying SeaBIOS and QEMU in lock-step.  To get
>     this in for QEMU v2.10 would require making QEMU changes during
>     the soft freeze and would require a SeaBIOS "stable" release that
>     introduces ACPI table manipulation.

Yes.

> B - I don't have full confidence the proposed ACPI changes wont expose
>     a quirk in some obscure OS from the last 25 years.  If it does
>     expose a quirk, any work-around would likely require deploying a
>     new SeaBIOS and QEMU in lock-step.

Well, the solution is proposed by ACPI itself, and the worst that can
happen is that some OS prefers the RSDT to the XSDT (which we already
test on Windows 2000).

> C - We'd be introducing "shared ownership" of the acpi tables.  Some
>     of the tables would be produced by QEMU and some of them by
>     SeaBIOS.  Explaining when and why to future developers would be a
>     challenge.

The advantage is that the same shared ownership is already present in
OVMF.  The RSDP/RSDT/XSDT are entirely created by the firmware in OVMF.
(The rev1 FADT isn't but that's just missing code; the table manager
in general would be ready for that).  In any case this doesn't seem
like something that cannot be solved by code comments.

Paolo