[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI
From: |
Christoffer Dall |
Subject: |
Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation |
Date: |
Wed, 12 Nov 2014 11:44:41 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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 <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?
> > > >
> > > > 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/heads/explore-rsdp
>
> 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
- Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation, Claudio Fontana, 2014/11/05
- Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation, Peter Maydell, 2014/11/06
- Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation, Igor Mammedov, 2014/11/06
- Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation, Alexander Spyridakis, 2014/11/06
- Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation, Peter Maydell, 2014/11/06
- Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation, Mark Rutland, 2014/11/11
- Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation, Christoffer Dall, 2014/11/11
- Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation, Mark Rutland, 2014/11/11
- Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation, Christoffer Dall, 2014/11/11
- Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation, Mark Rutland, 2014/11/12
- Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation,
Christoffer Dall <=
- Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation, Mark Rutland, 2014/11/12
- Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation, Graeme Gregory, 2014/11/12
- Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation, Julien Grall, 2014/11/12
- Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation, Paolo Bonzini, 2014/11/12
- Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation, Mark Rutland, 2014/11/12
- Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation, Paolo Bonzini, 2014/11/12
- Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation, Peter Maydell, 2014/11/12
- Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation, Paolo Bonzini, 2014/11/12
- Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation, Claudio Fontana, 2014/11/12
- Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation, Arnd Bergmann, 2014/11/12