[Top][All Lists]

[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: Thu, 22 Nov 2018 08:59:32 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0

On 11/22/18 7:50 AM, 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

Indeed. The H_INT_SET_SOURCE_CONFIG hcall updates the EAT.

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

Yes we could. I think I made it that way to be consistent with the 
other XIVE internal structures which are bigger : END, NVT

There might be other reasons in Pnv. One was to use generic accessors 
to the guest RAM but I didn't do it finally. Take a look at the Pnv
model and we might decide to change the prototype then. I don't 
think it's a major change.



reply via email to

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