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

[Christoffer Dall]

On Wed, Nov 12, 2014 at 12:15:08PM +0100, Arnd Bergmann wrote:
> On Wednesday 12 November 2014 10:56:40 Mark Rutland wrote:
> > On Wed, Nov 12, 2014 at 09:08:55AM +0000, Claudio Fontana wrote:
> > > On 11.11.2014 16:29, Mark Rutland wrote:
> > > 
> > > I tend to mostly agree with this, we might look for alternative
> > > solutions for speeding up guest startup in the future but in general
> > > if getting ACPI in the guest for ARM64 requires also getting UEFI,
> > > then I can personally live with that, especially if we strive to have
> > > the kind of optimized virtualized UEFI you mention.
> > 
> > Given that UEFI will be required for other guests (e.g. if you want to
> > boot a distribution's ISO image), I hope that virtualised UEFI will see
> > some optimisation work.
> 
> I think the requirement it just for KVM to provide something that
> behaves exactly like UEFI, it doesn't have to be the full Tianocore
> implementation if it's easier to reimplement the boot interface.

We already have a port of Tinaocode that works for virt, but yes,
implementing something ligther is certainly possible.

> 
> > > 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.
> > 
> > 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?

> 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?

-Christoffer