On 12 November 2014 12:04, Mark Rutland mark.rutland@arm.com wrote:
On Wed, Nov 12, 2014 at 11:52:22AM +0000, Paolo Bonzini wrote:
SeaBIOS fishes out information from fw_cfg, and puts it in low memory. On ARM you could use DT binary blobs instead of fw_cfg, as proposed already (I don't remember if it was in this thread or IRC). Then if you want to go !UEFI you can extract the tables from those binary blobs.
This sounds broken. I am very much not a fan of shoving binary blobs into DT to workaround a shoddy boot interface.
My understanding from an IRC conversation yesterday was that at least some of these ACPI blobs contain data which has to be constructed at the point it is requested (ie is not fixed at the point when QEMU starts up), because OVMF will do: * startup * prod some parts of the hardware to configure it * request ACPI tables via fw_cfg and the ACPI tables have to reflect the statu of the hardware after OVMF's poking, not before.
It wasn't entirely clear to me whether this applies equally to the ARM UEFI setup as to x86 + OVMF, but it does suggest that it would be better to define a memory-mapped variant of fw_cfg rather than stuffing the blobs into the device tree. (I didn't much like throwing the blobs in the dtb myself either.)
If somebody with more x86/ACPI knowledge could clarify what the dynamically-constructed parts of the tables are and whether they're likely to apply to use that would be good. I think they involved PCI in some way, but I don't have access to my irc logs right now to check. (I could imagine that ARM UEFI might not need to prod and configure a PCI bus and devices in the way that an x86 BIOS expects it has to, but that's speculation on my part, and I dunno that I'd care to bake that assumption into the design anyway.)
-- PMM