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