[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
Sat Sep 9 00:00:36 AEST 2017


On 08/09/17 14:20, Greg Kurz wrote:
> On Fri, 8 Sep 2017 13:51:24 +0100
> Mark Cave-Ayland <mark.cave-ayland at ilande.co.uk> 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 :(


ATB,

Mark.


More information about the SLOF mailing list