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 19:10, Peter Maydell wrote:
> On 12 November 2014 09:08, Claudio Fontana <claudio.fontana@huawei.com> wrote:
>> As mentioned by others, I'd rather see an implementation of ACPI in QEMU which
>> learns from the experience of X86 (and possibly shares some code if possible),
>> rather than going in a different direction by creating device trees first,
>> and then converting them to ACPI tables somewhere in the firmware, just because
>> device trees are "already there", for the reasons which have already been
>> mentioned before by Igor and others.
> 
> I think the motivation for "leave ACPI entirely to the firmware" is not
> just that the device trees are already there, but because it allows
> for a cleaner separation of concerns between QEMU and the firmware
> and thus makes QEMU simpler and easier to maintain in future.
> However as a result of the discussion in this thread and on IRC about
> what x86 QEMU/OVMF do and what the complexities of handling this in
> UEFI are, I'm not as sure as I was that it's actually feasible in
> practice.
> 
> I agree with you that if we have QEMU generating ACPI information
> itself then we should definitely follow the existing tested approach
> that x86 QEMU+OVMF have, and share code, both in QEMU and in the
> UEFI firmware. (As I understand it there is a common source code
> base between OVMF and the Tianocore code we're using for the ARM
> QEMU UEFI firmware. I've probably got the project names wrong here;
> I'm not familiar with the distinctions between Tianocore, EDK2,
> OVMF, etc.)
> 
> The x86 QEMU-generating-APCI approach is more complicated than
> what this RFC patchset does,

I think that the RFC was useful in its goal, as it generated a lot of comments,
and we will also be using it to do some internal early tests with ACPI on the
guest to speed up development.

I agree with you that as a result of this discussion, the solution for QEMU
upstreaming purposes needs to take everything discussed (possibly more)
into account.

> since it generates various separate
> tables and hands them individually to the firmware, rather than
> creating a single (non-relocatable) complete ACPI blob. I would
> hope we didn't need to support both "provide separated tables to
> firmware" and "provide a single blob to a standalone guest kernel";
> if we're agreed that ACPI should imply UEFI we can forget about
> the latter, though.
> 

As I mentioned I am personally fine with the ACPI -> UEFI implication, also
Paul (who represents my employer here) mentioned that we can live with this
implication if we have to.
The hope is to try to keep what needs to be implemented under control,
as to have as small an impact on boot time as possible, while still complying
to the specifications.

Thanks,

Claudio