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