[SLOF] [Qemu-ppc] [PATCH v4] board-qemu: add private hcall to inform host on "phandle" update
groug at kaod.org
Sun Sep 10 04:57:48 AEST 2017
On Sat, 9 Sep 2017 16:48:33 +1000
David Gibson <david at gibson.dropbear.id.au> wrote:
> On Fri, Sep 08, 2017 at 03:00:36PM +0100, Mark Cave-Ayland wrote:
> > On 08/09/17 14:20, Greg Kurz wrote:
> > > On Fri, 8 Sep 2017 13:51:24 +0100
> > > Mark Cave-Ayland <mark.cave-ayland at ilande.co.uk> wrote:
> > >
> > >> On 08/09/17 12:59, David Gibson wrote:
> > >>
> > >>>> If you're looking for a way to reference a node outside of OF then the
> > >>>> only way to consistently do this is via an OF path. What if when the DT
> > >>>> blob for PHB was created in QEMU you create a fake interrupt-parent-path
> > >>>> string property containing the OF path to the interrupt controller, and
> > >>>> move the generation of interrupt-map to SLOF?
> > >>>
> > >>>> In SLOF you could then do something like below to get the phandle from
> > >>>> the OF path:
> > >>>> "interrupt-parent-path" get-package-property dev ihandle>phandle
> > >>>> and from there, substituting the phandle into interrupt-map is trivial.
> > >>>
> > >>> Nope. At the time of hotplug, SLOF no longer exists - it's handed
> > >>> over to the guest.
> > >>
> > >> Yes, I understand that. This would be the process for getting the
> > >> initial DT information to SLOF to generate interrupt-map upon boot.
> > >>
> > >>>> Similarly for the guest, it should be easy to iterate over the kernel DT
> > >>>> to locate the interrupt controller device based upon OF path, and then
> > >>>> use the interrupt-map information to update its routing information for
> > >>>> the hotplugged PHB accordingly.
> > >>>
> > >>> That requires a non-PAPR-compliant guest change. Existing guests
> > >>> already support this when running under PowerVM.
> > >>
> > >> My understanding from the thread was that hotplugging PHBs is a new
> > >> feature? In that case the transition is simple: if the
> > >
> > > The feature is mentioned in the PAPR spec but not yet implemented in QEMU.
> > Meh. So in that case if this hacking of phandles is already part of the
> > PAPR specification, I guess we are too late :(
> Well, yes and no. In PAPR the hotplug handling is framed in terms of
> RTAS requests - the runtime portion of the guest firmware.
> PowerVM has its own (proprietary) guest OF implementation. Its
> version of RTAS is a reasonably substantial piece of software that has
> access to the device tree built by the boot-time portion of OF. That
> way its able to generate suitable DT fragments for plugged PHBs,
> including phandle referencees.
> Now hotplug clearly requires communication with the hypervisor, not
> just guest firmware; and in fact that's true of nearly everything RTAS
> does. How the RTAS <-> hypervisor communication happens is not
> specified by PAPR, and I don't know how the PowerVM implementation
> does so.
> For qemu/KVM, we decided - and I'm confident we were right to do so -
> that having separate hypervisor <-> RTAS and RTAS <-> guest OS
> protocols was silly. So, our RTAS is a miniscule (literally 20 bytes
> long) shim which simply forwards all RTAS requests to the hypervisor
> (i.e. qemu).
> This makes life much easier: it means we don't need to invent an
> RTAS<->hypervisor protocol (for this and many other situations. It
> means we don't need to worry about updating such a protocol in sync
> between the components. It means we don't need a complicated piece of
> RTAS code to be compiled with a guest-targetting toolchain. It means
> we don't need to jump through toolchain hoops to make code that's
> relocatable and callable using the somewhat weird conventions that
> RTAS uses.
> But, it means the RTAS calls implemented in qemu don't have access to
> the ouput-from-SLOF version of the device tree.
> So, how do we address that?
> One option is the one proposed earlier in the thread: a special
> hypercall lets OF update qemu with the phandles of nodes as it
> allocates them. For now - and very likely, forever - the changed
> phandles between the qemu generated "seed" tree and the OF-output tree
> are the only changes that matter to us.
> Another approach would be to snapshot the OF tree at the point we
> instantiate RTAS. We could either do that by having another special
> hcall which lets OF report the whole revised tree to qemu. Or we
> could just have it dump it as FDT at a known location within the RTAS
> blob (expanding it as necessary, obviously).
So in all cases, this would be a SLOF->QEMU communication... My 2 cent
is that we currently have only one qhandle to fix and the initial proposal
is simple (and already merged in SLOF FWIW).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 195 bytes
Desc: OpenPGP digital signature
More information about the SLOF