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

[Greg Kurz]

On Fri, 8 Sep 2017 13:51:24 +0100
Mark Cave-Ayland <address@hidden> wrote:

> On 08/09/17 12:59, David Gibson wrote:
> 
> >> 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.  
> > 
> > Nope.  At the time of hotplug, SLOF no longer exists - it's handed
> > over to the guest.  
> 
> Yes, I understand that. This would be the process for getting the
> initial DT information to SLOF to generate interrupt-map upon boot.
> 
> >> 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.  
> > 
> > That requires a non-PAPR-compliant guest change.  Existing guests
> > already support this when running under PowerVM.  
> 
> My understanding from the thread was that hotplugging PHBs is a new
> feature? In that case the transition is simple: if the

The feature is mentioned in the PAPR spec but not yet implemented in QEMU.

> interrupt-parent-path property is present, use it to locate the
> interrupt-parent. If it's not present then use the existing behaviour
> which works but won't support hotplugging PHBs.
> 
> However you also mention this is supported under PowerVM. Does that mean
> these patches are already in use somewhere?
> 

PowerVM is IBM's proprietary (ie, closed-source) environment to run
para-virtualized machines.

> Both these approaches require changes, however the benefit of this
> approach would be that it should easily extend this moving forwards for
> hotplugging other devices requiring interrupt-maps in future.
> 
> 
> ATB,
> 
> Mark.

pgpqHPP2k6vkC.pgp
Description: OpenPGP digital signature