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 13:51:24 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

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
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?

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.



reply via email to

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