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

[Mark Cave-Ayland]

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.

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.

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:

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:

   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.

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.