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

[Mark Rutland]

On Tue, Nov 11, 2014 at 09:33:12PM +0000, Christoffer Dall wrote:
> 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 <address@hidden> 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

Thanks.

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

Sounds good to me. That might be worth running as a separate thread so
as not to confuse matters.

Perhaps just using memory nodes is fine, but so far all of the
discussions I've been in (on mailing lists and in person) regarding ACPI
have had the fundamental assumption that ACPI would require UEFI, and
the UEFI memory map is in use. Given that assumption seems to be broken
for this case, we need to revisit those discussions.

There's also a problem in that this opens the possibility of non-Xen
!UEFI + ACPI configurations, which I don't think is something we want to
encourage. Xen is somewhat a special case because of the symbiotic
relationship with Dom0.

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

I believe that on x86 the fallback for !UEFI would be the e820 memory
map, which provides info regarding the type of the memory mapping, as
opposed to just the base + size. That said, I'm not that familiar with
e820, and from a quick look the provided information doesn't seem to be
that detailed.

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

Ah, that's not something I'd heard of.

I'm not a fan of placing fundamentally required system description on
the command line. It's fine for explicit overrides but I don't think it
should be the default mechanism as that causes its own set of problems
(who wants to fight with their hypervisor to pass a command line to a
guest kernel?).

Thanks,
Mark.