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