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.mayd...@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? 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. > 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. > But, what I hear from Huawei is that they don't want any DT and don't > want any UEFI, so not sure how they plan on accomplishing that. Indeed. Thanks, Mark.
