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

[David Gibson]

On Fri, Sep 08, 2017 at 05:48:51PM +0100, Mark Cave-Ayland wrote:
> On 08/09/17 15:54, Greg Kurz wrote:
> 
> >>> 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 :(
> >> 
> > Just to clarify: the PAPR specification explicitly mentions that PHBs
> > are hot-pluggable, but the fact that each PHB node has an "interrupt-map"
> > property which contains a phandle referring to the platform interrupt
> > controller comes from the "Open Firmware Recommended Practice: Interrupt
> > Mapping" spec.
> 
> Right, except that it sounds like PowerVM already uses this so it may
> already be set in stone.

More or less, yes.

> The technique described whereby a temporary property is used to pass
> information into a device node is something I've used a few time in
> OpenBIOS to pass information from C into the Forth bindings.

Sure, but not relevant.  OF is no longer around at hotplug time.

> I can only re-emphasise what Segher says in that phandles/ihandles
> should be consider opaques owned by OF. For maximum flexibility you
> could extend this scheme for any node/property that requires a phandle
> reference to another node in a similar way:

Note that we don't actually violate this tenet.  The qemu generate
phandles are strictly temporary, being replaced by OF owned ones.  The
problem is that qemu then doesn't *know* the OF generated ones.

> For any property "foo" in the current package, if "foo-devices" also
> exists then "foo-devices" is an array of strings property containing the
> full OF device paths for which the phandle is to be substituted into the
> "foo" property for each placeholder value (currently 0x00001111). In a
> way it's similar to a sprintf() placeholders.
> 
> A quick example shows this could be generated by QEMU:
> 
>    device_type: phb
>    interrupt-map-devices: "/pci/path/to/xics"
>    interrupt-map: 0x1 0x2 0x1111 0x0
> 
> On boot SLOF can generate the initial device tree by noticing
> interrupt-map and interrupt-map-devices, locating each device in
> interrupt-map-devices and obtaining its phandle. Scanning interrupt-map
> SLOF then detects 0x1111 and substitutes the phandle into the property,
> and then removes the temporary interrupt-map-devices when done:

Sure, but why.

>    device_type: phb
>    interrupt-map: 0x1 0x2 ph 0x0
> 
> Guests can then do the same for hotplug events, scanning the hotplug DT
> created by QEMU looking for "foo" and "foo-devices" and then either
> generating the appropriate interrupt-map property in the same way or
> locating the interrupt-parent device directly via its OF path in order
> to set the interrupt routing.

Nope.  Because that's *not* what the guest does.  The guest side is
already implemented and works with PowerVM.  If we require the guest
to do extra work we're not doing PHB hotplug the way PAPR specifies
any more.

> Anyhow I hope I've explained how I believe this should work in a bit
> more detail - I'll leave it now for others to decide whether this is a
> suitable approach or not.
> 
> 
> ATB,
> 
> Mark.
> 

-- 
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_!
http://www.ozlabs.org/~dgibson
-------------- 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/20170909/651a18f5/attachment.sig>