On 08/26/14 16:33, Paolo Bonzini wrote: > Il 26/08/2014 03:03, Laszlo Ersek ha scritto: >> >> The only way you could reliably fish out tables, operation regions etc. >> from the qemu payload would be to write a near-full ACPI interpreter. >> The goal of the interface is the polar opposite, ie. to require the >> firmware to know the least possible about ACPI table specifics. > > Could OvmfPkg include its own minimal implementation of > AcpiTableProtocol? You can check that InstallAcpiTable calls do not > override QEMU-provided tables (which is currently the case), and abort > if that happens.
The problem is that for this check I need to determine the set of ACPI tables that QEMU provides. (Otherwise I can't detect a conflict in the InstallAcpiTable function().) In order to determine the QEMU provided set of tables, I need to locate all of the ACPI table headers in the fw_cfg blobs. Which is exactly what the current, in-tree code does (not in order to look for conflicts, but to pass those tables to EFI_ACPI_TABLE_PROTOCOL, one by one); and that approach is too brittle. > OvmfPkg does not need to expose AcpiSdtProtocol---which I'm not even > sure who uses; SDT is used in code that has intimate knowledge of some AML (binary) code, and needs to navigate the nodes to a specific node, to read or write some scalar value. It is quite similar to an absolutely minimal XPath implementation, conceptually. > AcpiTableProtocol is small(ish) and a lot of code could > go away as far as OVMF is concerned if you drop support for three ACPI > versions. > > If you do that, you can parse only the QEMU-provided RSD PTR and RSDT > (to find out which tables QEMU provides and avoid overriding them). The problem is that a number of tables are not linked into the RSDT, they are referenced by other tables. Basically, all the pointer fields in all tables that are updated (relocated / absolutized) by AddPointer commands, point *potentially* to further ACPI tables. (Not necessarily though. For example, the LASA field in TCPA is a pointer, but its pointee is not an ACPI table header. Another example is BGRT, whose ImageAddress field is a pointer, but doesn't point to another table. The current linker-loader *can* export an ACPI payload that includes some placeholder area pointed-to by TCPA.LASA. Similarly it could export an fw_cfg blob that contains the boot logo (the image data) itself, and a BGRT table whose ImageAddress field gets relocated to the image data with an AddPointer command.) So, in order to determine the full set of QEMU-exported ACPI tables, it doesn't suffice to scan the RSDT. We'd have to follow all pointer fields, recursively (eg. RSDT->FACP->DSDT), and even know if *under* each pointer we'll find another table, or just some header-less stuff. The above would mean two things at the same time: - precisely the ACPI knowledge that the linker/loader interface is supposed to obviate in the firmware, - precisely the ACPI knowledge that the current implementation of EFI_ACPI_TABLE_PROTOCOL encodes, and updates from time to time, when some new table is standardized (or when something already standardized breaks simply due to bugs). > In the meanwhile, UEFI could work on a new v2 AcpiTableProtocol that has > an InstallAcpiTableNoRelocate function. With it, the QEMU ACPI table > linker can, again, parse the RSDT, pass each table to > InstallAcpiTableNoRelocate, and then discard the QEMU-provided RSDT. > >> RSD PTR being referenced in the config table is not even part of the >> UEFI spec (if I searched it right); it's described in the ACPI spec. The >> UEFI spec only names the relevant GUIDs, but doesn't explain how to use >> them. >> >> In any case, under the IBFT example you name, we have a conflict because >> ACPI tables have two genuine, distinct sources. IBFT comes from the >> firmware, while the rest would come from QEMU. >> >> (I don't know if IBFT could be provided by QEMU. The ACPI 5.1 spec >> doesn't describe the table. Googling led me to a license acceptance >> window at Microsoft's site, which I closed.) > > No, it couldn't. The iBFT information depends on where the system boots > from. Basically it's how the firmware tells the OS "I booted you from > here, that's where you can get any other files you need". Basically it > lets you configure your network and iSCSI initiator before you have a > DHCP client. > > ftp://ftp.software.ibm.com/systems/support/bladecenter/iscsi_boot_firmware_table_v1.03.pdf Sigh. I suspected that iBFT would store stuff like UEFI device paths or some such (similarly to EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL), which qemu has no clue at all about. Thanks for the info though. Cheers Laszlo ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
