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

[Arnd Bergmann]

On Wednesday 12 November 2014 12:34:01 Christoffer Dall wrote:
> On Wed, Nov 12, 2014 at 12:15:08PM +0100, Arnd Bergmann wrote:
> > On Wednesday 12 November 2014 10:56:40 Mark Rutland wrote:
> > > 
> > > For the features which ACPI provides which device trees do not (e.g. the
> > > dynamic addition and removal of memory and CPUs), there will need to be
> > > some sort of interface between QEMU and the ACPI implementation. That's
> > > already outside of the realm of DT, so as previously mentioned a simple
> > > conversion doesn't cover the general case.
> > 
> > I think we need to support the low-level interfaces in the kernel for
> > this anyway, we should not have to use ACPI just to do memory and CPU
> > hotplugging in KVM, that would be silly.
> 
> I had that same intuitive feeling, but lacked good tecnical arguments
> for it.  Care to elaborate on that?

ACPI always has to interface back to the hypervisor to do anything that
changes the hardware configuration, so it essentially has to perform
a hypercall or touch some virtual register.

If we need to architect that interface in qemu anyway, we should make
it sane enough for the kernel to use directly, without having to go
through ACPI, as not everyone will want to run ACPI.
 
> > If ACPI is present, it can
> > provide a wrapper for the same interface, but KVM should not need to
> > be aware of the fact that ACPI is used in the guest, after it has
> > passed the initial ACPI blob to the kernel.
> 
> That's where things begin to be a bit foggy for me.  AFAIU ACPI already
> has a method for doing this and I speculate that there is some IRQ
> assigned to an ACPI event that causes some AML code to be interpreted by
> your OS.  Wouldn't it be a matter of QEMU putting the right AML table
> fragments in place to wire this up then?

Yes, that is what I meant with a wrapper. The two choices are:

1. have an interrupt and a hypercall or mmio interface. When the
   interrupt gets triggered, we ask the interface what happened and
   do something on the same interface depending on the state of the
   system.

2. have an interrupt that causes AML code to be run, that code will
   use the hypercall or mmio interface to find out what happened and
   create an ACPI event. This event is enqueued to the generic ACPI
   hotplug handler, which depending on the state of the system decides
   to do something by calling into AML code again, which will trigger
   the underlying interface.

>From qemu's point of view, the two are doing exactly the same thing,
except that the MMIO access can be hidden in AML so the OS doesn't have
to know the interface. Note that in case of Xen, the use of hypercalls
means that the OS has to know the interface after all, so the second
half of the process is handled by drivers/xen/xen-acpi-*hotplug.c.

Note how the implementation that uses the ACPI wrapper is much
more complex than the native one that does the same thing:

-rw-r--r-- 1 arnd arnd  2119 Nov 10 16:43 drivers/xen/cpu_hotplug.c
-rw-r--r-- 1 arnd arnd 10987 Nov 10 16:43 drivers/xen/xen-acpi-cpuhotplug.c

-rw-r--r-- 1 arnd arnd  6894 Nov 10 16:43 drivers/xen/xen-balloon.c
-rw-r--r-- 1 arnd arnd 12085 Nov 10 16:43 drivers/xen/xen-acpi-memhotplug.c

        Arnd