Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Peter Maydell]

On 12 November 2014 12:04, Mark Rutland <address@hidden> 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