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

[Kevin O'Connor]

On Wed, Jul 26, 2017 at 04:21:23PM -0400, Paolo Bonzini wrote:
> > 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).

Parsing the XSDT is a different code path in the OSes - it could
expose a quirk.  I'm fine with the new layout of the ACPI tables, but
I think we need to be prepared that the change could have a ripple
effect.

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

I'd argue that the shared ownership in the EDK2 code was a poor design
choice.  Case in point - we're only having this conversation because
of its limitations - SeaBIOS is capable of deploying the acpi tables
in the proposed layout without any code changes today.  I'm not
against changing SeaBIOS, but it's a priority for me that we continue
to make it possible to deploy future ACPI table changes (no matter how
quirky) in a way that does not require future SeaBIOS releases.

-Kevin