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: Fri, 23 Nov 2018 11:28:24 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0

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. 

C.


> 
>>
>>>
>>> 2) The signatures are a bit odd here.  For the setter, a value would
>>> make sense than a (XiveEAS *), since it's just a word.  For the getter
>>> you could return the EAS value directly rather than using a pointer -
>>> there's already a valid bit in the EAS so you can construct a value
>>> with that cleared if the lisn is out of bounds.
>>
> 




reply via email to

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