On 08/27/14 11:47, Paolo Bonzini wrote: > Il 26/08/2014 18:49, Laszlo Ersek ha scritto: >> 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. > > Right, the FADT's pointers to FACS and DSDT are an exception. But are > there others? And you don't really care about _where_ the tables are, > just if they are there, and you know that FACS+DSDT are always provided > by QEMU.
This is probably implementable, if someone can come up with a clear list of reasonably future-proof rules. It would be good to avoid revisiting this OVMF code every now and then, whenever QEMU's ACPI generator undergoes a bit more intrusive changes. >> 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). > > Yes, this is unfortunate. But I still believe that all you need to know > is the format of the RSDT/XSDT. > > Is it possible to at least provide a *dummy* implementation of the ACPI > table protocol, that returns an error? This would avoid weird > situations where booting from iSCSI breaks CPU hotplug or something like > that. Sure, that's certainly possible; it crossed my mind too. (We could also consistently lie and return EFI_SUCCESS -- who knows which one would do less damage. Drivers that depend on EFI_ACPI_TABLE_PROTOCOL *and* have sensible error handling would cope with a persistent error just fine (at worst the service wouldn't be available). But some drivers are lazy and just say ASSERT_EFI_ERROR(), and then an error would halt the firmware.) Anyway, implementing such a dummy driver would take a build time flag (-D ...), and when it was present, we'd build and include this dummy protocol implementation in the firmware, rather than the one from MdeModulePkg. (Because, although EFI_ACPI_TABLE_PROTOCOL is not an "architectural" protocol, it's definitely a "singleton" one, so clients just grab the first instance they find.) Not sure how Jordan would like this though :) Thanks 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
