qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [SLOF] [PATCH v4] board-qemu: add private hcall to inform


From: Greg Kurz
Subject: Re: [Qemu-ppc] [SLOF] [PATCH v4] board-qemu: add private hcall to inform host on "phandle" update
Date: Fri, 8 Sep 2017 16:54:27 +0200

On Fri, 8 Sep 2017 15:00:36 +0100
Mark Cave-Ayland <address@hidden> wrote:

> On 08/09/17 14:20, Greg Kurz wrote:
> > 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.  
> 
> 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.

Cheers,

--
Greg

> 
> ATB,
> 
> Mark.

Attachment: pgp8lQliYyWbp.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]