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