qemu-ppc
[Top][All Lists]
Advanced

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

Re: [Qemu-ppc] [PATCH v5 04/36] ppc/xive: introduce the XiveRouter model


From: Cédric Le Goater
Subject: Re: [Qemu-ppc] [PATCH v5 04/36] ppc/xive: introduce the XiveRouter model
Date: Mon, 26 Nov 2018 10:39:44 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0

On 11/26/18 6:44 AM, David Gibson wrote:
> On Fri, Nov 23, 2018 at 11:28:24AM +0100, Cédric Le Goater wrote:
>> On 11/23/18 2:10 AM, David Gibson wrote:
>>> On Thu, Nov 22, 2018 at 05:50:07PM +1100, Benjamin Herrenschmidt wrote:
>>>> On Thu, 2018-11-22 at 15:44 +1100, David Gibson wrote:
>>>>>
>>>>> Sorry, didn't think of this in my first reply.
>>>>>
>>>>> 1) Does the hardware ever actually write back to the EAS?  I know it
>>>>> does for the END, but it's not clear why it would need to for the
>>>>> EAS.  If not, we don't need the setter.
>>>>
>>>> Nope, though the PAPR model will via hcalls
>>>
>>> Right, bit AIUI the set_eas hook is about abstracting PAPR vs bare
>>> metal details.  Since the hcall knows it's PAPR it can just update the
>>> backing information for the EAS directly, and no need for an
>>> abstracted hook.
>>
>> Indeed, the first versions of the XIVE patchset did not use such hooks, 
>> but when discussed we said we wanted abstract methods for the router 
>> to validate the overall XIVE model, which is useful for PowerNV. 
>>
>> We can change again and have the hcalls get/set directly in the EAT
>> and ENDT. It would certainly simplify the sPAPR model.
> 
> I think that's the better approach.

ok. let's keep that in mind for  : 

 [PATCH v5 11/36] spapr/xive: use the VCPU id as a NVT identifier
 [PATCH v5 16/36] spapr: add hcalls support for the XIVE exploitation

which are using the XiveRouter methods to access the controller EAT 
and ENDT. I thought that was good practice to validate the model but 
we can use direct sPAPR table accessors or none at all.


I think these prereq patches could be merged now :

 [PATCH v5 12/36] spapr: initialize VSMT before initializing the IRQ
 [PATCH v5 13/36] spapr: introduce a spapr_irq_init() routine
 [PATCH v5 14/36] spapr: modify the irq backend 'init' method

This one also :

 [PATCH v5 21/36] spapr: extend the sPAPR IRQ backend for XICS

Thanks,

C. 



reply via email to

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