[SeaBIOS] [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support
Kevin O'Connor
kevin at koconnor.net
Thu Jul 27 16:59:29 CEST 2017
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
More information about the SeaBIOS
mailing list