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

[Claudio Fontana]

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.

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?

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.

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.

Thanks,

Claudio