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

[Mark Rutland]

On Wed, Nov 12, 2014 at 09:08:55AM +0000, Claudio Fontana wrote:
> On 11.11.2014 16:29, 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?
> > 
> > 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.
> > 
> 
> Hi,
> 
> 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.

> We can in the meantime use these patches to test the "fast path" to
> the guest by just hardcoding or passing on the command line what is
> needed to be able to test information reading from ACPI from the guest
> side.
> 
> I cc: my colleagues Jani and Paul which have more the use case in mind
> and
> might correct me there.
> 
> For x86 though what is the state of UEFI in QEMU? Is it relying on the
> OVMF project to provide the firmware images if I understand
> correctly..
> How is it working out in practice?
> Should the same kind of approach be taken for ARM64?

I'm unfortunately not familiar enough with OVMF to answer any of these
questions.

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

For most static things, device tree should be suitable as-is (i.e.
without translation to ACPI) for all currently supported guests.

I think any ACPI implemenation for a hypervisor should provide a
demonstrable useful feature (e.g. hot-add of CPUs) before merging so we
know the infrastructure is suitable.

> I wouldn't want for ACPI to be "sort of" supported in QEMU, but with a
> limited functionality which makes it not fully useful in practice. I'd
> rather see it as a first class citizen instead, including the ability
> to run AML code.

I agree that there's no point in having ACPI in a guest unless it
provides something which dt does not. I don't know how it should be
structured to provide those useful features.

Thanks,
Mark.