[SLOF] [Qemu-ppc] [PATCH v4] board-qemu: add private hcall to inform host on "phandle" update

David Gibson david at gibson.dropbear.id.au
Fri Sep 8 21:59:03 AEST 2017

On Fri, Sep 08, 2017 at 12:39:51PM +0100, Mark Cave-Ayland wrote:
> On 07/09/17 03:21, Alexey Kardashevskiy wrote:
> >> I think I missed the first part of this thread, however can someone
> >> explain why hotplug devices need to update the SLOF DT? 
> > 
> > They do not.
> > 
> > When hotplug happens, QEMU provides a DT blob to the guest for a new PHB
> > which includes "interrupt-map" which tells how PHB interrupts are mapped to
> > a global interrupt controller (XICS) which is identified by that phandle.
> > So this blob has to have a valid XICS phandle - QEMU could get it somehow
> > from SLOF but this hypercall is new. QEMU makes it up instead as we needed
> > to construct the interrupt-map of the default PHB and it requires the XICS
> > phandle which is not known at the time as SLOF has not started yet and has
> > not generated phandles.
> > 
> > We could move that interrupt-map creating code ([1]) to SLOF, get rid of
> > the phandle fixing hack ([2]) but this won't help with hotplugged PHBs - we
> > will still have to have the interrupt-map code in QEMU's PHB hotplug path +
> > hcall from SLOF to update the XICS phandle in QEMU, propably this is the
> > way to go.
> > 
> > [1]
> > https://git.qemu.org/?p=qemu.git;a=blob;f=hw/ppc/spapr_pci.c;h=d84abf1070a0ae58ef13162d00c0d80e147f1b19;hb=HEAD#l2166
> > [2]
> > https://git.qemu.org/?p=SLOF.git;a=blob;f=board-qemu/slof/fdt.fs;h=a24e3449e7c1fc61d1894d600afc95cfc6fe6518;hb=HEAD#l353
> Thanks for the explanation. For comparison how does this work in real
> hardware - presumably there must some existing mechanism for notifying
> XICS that an extra PHB has been inserted?

Not really.  The bare metal platform is a different beast from the
PAPR platform.  I think hardware level PHB hotplug isn't even
possible, it only works here because they're vPHBs.

> 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.

> 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.

David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/slof/attachments/20170908/765c62bd/attachment.sig>

More information about the SLOF mailing list