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

Alexey Kardashevskiy aik at ozlabs.ru
Fri Sep 8 22:30:39 AEST 2017

On 08/09/17 21:39, 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?

I am not aware of any hardware capable of hotplugging PHBs :)

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

There is no path in the interrups-map, it uses phandles, this is defined in
the interrupt binding spec which the existing guests use, it is kinda late
to change that. We can change how things work between QEMU and SLOF but
once the guest kernel is up, there is no more SLOF and QEMU has to do all
these tricks to the DT blobs itself.


More information about the SLOF mailing list