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

Mark Cave-Ayland mark.cave-ayland at ilande.co.uk
Fri Sep 8 21:39:51 AEST 2017

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?

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.

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.



More information about the SLOF mailing list