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: Mark Cave-Ayland
Subject: Re: [Qemu-ppc] [SLOF] [PATCH v4] board-qemu: add private hcall to inform host on "phandle" update
Date: Fri, 8 Sep 2017 15:00:36 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

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 :(


ATB,

Mark.



reply via email to

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