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

[Mark Rutland]

On Thu, Nov 06, 2014 at 06:53:03AM +0000, Hanjun Guo wrote:
> On 2014-10-31 2:02, Mark Rutland wrote:
> > 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. 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.)
> > 
> > Depending on why people want ACPI in a guest environment, generating
> > ACPI tables from a DTB might not be possible (e.g. if they want to use
> > AML for some reason).
> 
> Agreed.
> 
> > 
> > So the important question is _why_ the guest needs to see an ACPI
> > environment. What exactly can ACPI provide to the guest that DT does not
> > already provide, and why is that necessary? What infrastrucutre is
> > needed for that use case?
> 
> There is important feature called system device dynamic reconfiguration,
> you know, hot-add/remove, if a gust need more/less memory or CPU, can we
> add or remove them dynamically with DT? ACPI can do this, but I have no
> idea if DT can. (Sorry, I don't know much about DT)

There is no way of doing this with DT. There has been work into DT
fragments/overlays where portions can be added to the tree dynamically,
but that's controlled by the OS rather than the hypervisor, and there's
no standard for communicating what has been hotplugged to trigger
changes to the tree, so it's not quite the same. It really only works
for tightly coupled hw/kernel/userspace combinations (i.e. embedded).

Depending on how you implement the hot-add/remove you might be able to
get away with an initial static configuration translated from DT. If you
need to describe what might be hotplugged from the start, then I suspect
you cannot get away with translating a DT in general.

Thanks,
Mark.