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.
> >>> 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.
> >>
> >
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
