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 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?
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/he...
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.
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?
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.
-Christoffer