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

[David Gibson]

On Fri, Sep 08, 2017 at 01:54:45PM +0100, Mark Cave-Ayland wrote:
> On 08/09/17 13:30, Alexey Kardashevskiy wrote:
> 
> >> 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 :)
> 
> Ha okay :)

There might be some, actually.  I suspect some of those Xilinx chips
with a core and big FPGA could do it by programming in a host bridge.

> >> 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.
> 
> My understanding from this thread though was that the FDT can't be
> inserted directly into the kernel DT as-is because it still needs to
> translate between qhandles and phandles. So there must already be a hook
> somewhere on hotplug to allow the FDT blob to be altered before it is
> handed over to the kernel, so the interrupt-map property can be fixed up
> based upon interrupt-parent-path at the same time.

Nope.  There is no hook, the DT goes straight from qemu to the guest
OS.  Everything we've hotplugged so far hasn't need to reference any
phandles, so it hasn't mattered.

[Aside: strictly, it's not an FDT piece that goes to the guest OS;
the guest performs a sequence of calls to traverse the DT fragment.
qemu uses an fdt fragment as an internal detail, but that's not part
of the protocol]

-- 
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/571ad193/attachment.sig>