[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI

From: Leif Lindholm
Subject: Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation
Date: Mon, 9 Mar 2015 12:12:37 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

Sorry for being late to the party, missed this set when it went out.

On Thu, Oct 30, 2014 at 05:52:44PM +0000, Peter Maydell wrote:
> On 30 October 2014 17:43, Alexander Spyridakis
> <address@hidden> wrote:
> > Currently, the virt machine model generates Device Tree information 
> > dynamically based on the existing devices in the system. This patch series 
> > extends the same concept but for ACPI information instead. A total of seven 
> > tables have been
> > implemented in this patch series, which is the minimum for a basic ARM 
> > support.
> >
> > The set of generated tables are:
> > - RSDP
> > - XSDT
> > - MADT
> > - GTDT
> > - FADT
> > - FACS
> > - DSDT
> >
> > The tables are created in standalone buffers, taking into account the
> > needed information passed from the virt machine model. When the generation
> > is finalized, the individual buffers are compacted to a single ACPI binary
> > blob, where it is injected on the guest memory space in a fixed location.
> > The guest kernel can find the ACPI tables by providing to it the physical
> > address of the ACPI blob (e.g. acpi_rsdp=0x47000000 boot argument).
> (Sorry, I should have waited for the cover letter to arrive before replying.)
> I think this is definitely the wrong approach. We already have to
> generate device tree information for the hardware we have, and having
> an equivalent parallel infrastructure for generating ACPI as well
> seems like it would be a tremendous mess.

I don't see this as duplication, I see this as platform completeness.
And it would be really useful for firmware validation.

> We should support guests
> that require ACPI by having QEMU boot a UEFI bios blob and have that
> UEFI code generate ACPI tables based on the DTB we hand it.
> (Chances seem good that any guest that wants ACPI is going to want
> UEFI runtime services anyway.)

Yes, we could do that, but in doing so we would be treating ACPI as
some artificial tickbox thing rather than a platform property. And it
would introduce an entirely new class of ARM-specific errors.

Moreover, we currently have separate EDK2 platforms for ARM*/x86 QEMU
(ArmVirtualizationQEMU vs. Ovmf). The goal there is to progressively
move towards greater amounts of shared code between the two, and
hopefully merge them into one eventually.

Deferring specifically on ARM the responsibility of generating (all)
ACPI tables to the firmware leads to reduced amount of code shared
between ARM/x86 in both QEMU and EDK2. And reduced ability to share
future developments in that area (x86 QEMU seems well on the way
towards letting you inject AML blobs from the command line).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]