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

[Claudio Fontana <claudio.fontana@huawei.com>]

On 12.11.2014 14:27, Peter Maydell wrote:
> 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.)

Would the last step you mention allow for guests to start with an already existing PCI interrupt map
and the BAR registers preprogrammed to point to somewhere sane?

I ask because on OSv at the moment, the situation is that for x86 we don't need to reprogram anything on PCI,
as everything is already nicely set up by the time the guest starts, and thus the BAR addresses can be read directly.
On ARM we have to reprogram the BARs manually for all devices.

Couldn't we give an easier time to each OS guest by having everything nicely set up on AArch64 as well?

Claudio