On 07/27/17 16:59, Kevin O'Connor wrote:
On Wed, Jul 26, 2017 at 04:21:23PM -0400, Paolo Bonzini wrote:
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.
The reason we can't just exclude the reference implementation of EFI_ACPI_TABLE_PROTOCOL from OVMF whole-sale, and reimplement the ACPI linker/loader from scratch, is that some other (independent) edk2 modules will want to use EFI_ACPI_TABLE_PROTOCOL for installing their own (one-off) tables, such as IBFT, BGRT and so on, *in addition to* QEMU's. Given that these ACPI tables mostly do *not* describe hardware (but software features and/or configuration), it's hard to claim that they should also be generated by QEMU.
Therefore the dual origin for ACPI tables looks unavoidable in UEFI, it's just that there should be a lot more flexible "connect" from QEMU's linker/loader to the installed ACPI tables than EFI_ACPI_TABLE_PROTOCOL.
Basically this is a fight over ownership. Each of QEMU's ACPI linker/loader and EFI_ACPI_TABLE_PROTOCOL thinks that it fully owns the root of the table tree. :(
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.
Yes.
But let's not forget that SeaBIOS is capable of delegating the full low-level construction of the table tree to QEMU because no independent / 3rd party BIOS-level code wants to install its own tables (again, IBFT, BGRT, ...) This is not true of UEFI, where the guiding principle of the standardized interfaces is to enable cooperation between independent, binary-only modules. (So, for example, if you shove a new PCI add-on card in your motherboard, the UEFI driver in that oprom could install a separate ACPI table, by looking up and calling EFI_ACPI_TABLE_PROTOCOL.)
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.
It's a good goal.
I apologize for forgetting the context, but what exactly was the argument against:
- splitting modern ACPI generation from ancient ACPI generation (so that we can assign separate maintainers to ancient vs. modern),
- restricting ancient ACPI generation to old machine types?
Thanks, Laszlo