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

[Mark Rutland]

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?

>From experience with Linux, querying this information from UEFI is a
trivial overhead, though a UEFI implementation might take a while to
boot to the point where that is possible. It would be more generally
helpful to have an optimized virtualised UEFI for this case (or perhaps
just a UEFI frontend that presents the same interface to EFI
applications but doesn't have to do any heavy lifting at boot).

So far the general trend with AArch64 at the system level is to use
generic interfaces as far as possible. The generic interface for
discovering ACPI tables is to boot as an EFI application and then to
query the tables from UEFI. That is the interface others are likely to
follow, and ACPI without UEFI is unlikely to be of much use to anyone
else.

Why is it worth expending the effort on the boot protocol you suggest
(which so far is not well defined) when there is already a portable,
well-defined standard that others are already following?

Thanks,
Mark.