On Wed, Nov 12, 2014 at 10:38:54AM +0000, Mark Rutland wrote:
On Tue, Nov 11, 2014 at 09:33:12PM +0000, Christoffer Dall wrote:
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...
Thanks.
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.
Sounds good to me. That might be worth running as a separate thread so as not to confuse matters.
Agreed.
Perhaps just using memory nodes is fine, but so far all of the discussions I've been in (on mailing lists and in person) regarding ACPI have had the fundamental assumption that ACPI would require UEFI, and the UEFI memory map is in use. Given that assumption seems to be broken for this case, we need to revisit those discussions.
There's also a problem in that this opens the possibility of non-Xen !UEFI + ACPI configurations, which I don't think is something we want to encourage. Xen is somewhat a special case because of the symbiotic relationship with Dom0.
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?
I believe that on x86 the fallback for !UEFI would be the e820 memory map, which provides info regarding the type of the memory mapping, as opposed to just the base + size. That said, I'm not that familiar with e820, and from a quick look the provided information doesn't seem to be that detailed.
right, the good old PC.
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.
Ah, that's not something I'd heard of.
Maybe there was a misunderstanding then, I thought you were cc'ed on those discussions.
I'm not a fan of placing fundamentally required system description on the command line. It's fine for explicit overrides but I don't think it should be the default mechanism as that causes its own set of problems (who wants to fight with their hypervisor to pass a command line to a guest kernel?).
Agreed completely, but I've been lacking strong technical arguments against passing this stuff on the cmdline. My personal preferred approach for the Xen Dom0 case is to add a property to the DT.
-Christoffer