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

[Christoffer Dall <christoffer.dall@linaro.org>]

On Tue, Nov 11, 2014 at 04:48:07PM +0000, Mark Rutland wrote:
> Hi Christoffer,
> 
> On Tue, Nov 11, 2014 at 04:31:01PM +0000, Christoffer Dall wrote:
> > On Tue, Nov 11, 2014 at 03:29:33PM +0000, Mark Rutland wrote:
> > > Hi,
> > > 
> > > On Thu, Nov 06, 2014 at 01:33:20PM +0000, Alexander Spyridakis wrote:
> > > > On 6 November 2014 14:44, Peter Maydell <peter.maydell@linaro.org> wrote:
> > > > >
> > > > >
> > > > > > We need ACPI guest support in QEMU for AArch64 over here, with all features
> > > > > > (including the ability to run ACPI code and add specific tables), for
> > > > > > ACPI-based guests.
> > > > >
> > > > > The plan for providing ACPI to guests is that we run a UEFI BIOS
> > > > > blob which is what is responsible for providing ACPI and UEFI
> > > > > runtime services to guests which need them. (The UEFI blob finds
> > > > > out about its hardware by looking at a device tree that QEMU
> > > > > passes it, but that's a detail between QEMU and its bios blob).
> > > > > This pretty much looks like what x86 QEMU used to do with ACPI
> > > > > for a very long time, so we know it's a feasible approach.
> > > > 
> > > > Hi Peter,
> > > > 
> > > > The rational in the proposed approach is meant for cases where the
> > > > user does not want to rely on external firmware layers. While UEFI
> > > > could do what you are describing, the point is to avoid this not so
> > > > trivial overhead in the booting process. Especially in the case of
> > > > thin guests, where another software dependency is undesired.
> > > 
> > > I'm not sure how you plan to use ACPI without UEFI, as there are several
> > > pieces of information which ACPI misses, such as the memory map, which
> > > must be discovered from UEFI. How do you intend to discover the memory
> > > map without UEFI?
> > > 
> > > Additionally, with Linux and other generic OSs, the expectation is that
> > > the ACPI tables are discovered via the UEFI system table. How do you
> > > intend to discover the ACPI tables? Or other system information?
> > 
> > FWIW, Xen needs to pass the RDSP pointer along with a tiny DT containing
> > the command line and memory information to Dom0 as well.
> 
> When you say "memory information", is that pointers to a UEFI memory
> map, or memory nodes? The former should work for ACPI, but I don't think
> the latter will. I think there's a need for some discussion regarding
> the Dom0 boot flow for ACPI. Is there any tree I can take a peek at?

Plain memory nodes.  There is no UEFI instance for Dom0.  AFAIU x86 does
something similar (although with some custom PV thing instead of DT),
and when Dom0 needs UEFI runtime services, this is done through specific
hypercalls.

The Xen code is incomplete for this work, but can be followed here:
https://git.linaro.org/people/parth.dixit/acpi-rsdp/xen.git/shortlog/refs/heads/explore-rsdp

The Linux side is stuff based on the LEG kernel I think, not sure if
it's pushed anywhere yet.

I'm cc'ing Parth and Julien here, but I agree that having a discussion
on this could probably be good.

> 
> Passing just the RDSP will mean that Dom0 won't get SMBIOS tables and
> other potentially useful things, in addition to simply being yet another
> potential boot configuration. I'm a little concerned about that.
> 

I share your concern, but running another UEFI instance for Dom0 doesn't
seem like a viable alternative either.  Why is this a problem on ARM and
not on x86 though?

> > We are currently suggesting adding an RDSP property to the chosen node
> > in the tiny DT, but a command-line arguement like kexec proposed could
> > be another option I guess, albeit not a very pretty one.
> 
> I'm not sure what an RDSP command line property would have to do with
> kexec. I'll assume I've misunderstood something.
> 

I thought the kexec patches proposed passing the RDSP on the
command-line to boot the secondary kernel, so if that ended up being
supported by the kernel for kexec, maybe that could be leveraged by
Xen's boot protocol.  It was an idea someone brought to me, just thought
I'd mention it.

-Christoffer