On Mon, Jun 03, 2024 at 02:51:46PM +0530, Amit Daniel Kachhap wrote:
>
>
> On 5/31/24 22:09, Mark Brown wrote:
> > On Tue, May 28, 2024 at 12:26:54PM +0530, Amit Daniel Kachhap wrote:
> > > On 5/3/24 18:31, Joey Gouly wrote:
> >
> > > > +#define POE_MAGIC 0x504f4530
> > > > +struct poe_context {
> > > > + struct _aarch64_ctx head;
> > > > + __u64 por_el0;
> > > > +};
> >
> > > There is a comment section in the beginning which mentions the size
> > > of the context frame structure and subsequent reduction in the
> > > reserved range. So this new context description can be added there.
> > > Although looks like it is broken for za, zt and fpmr context.
> >
> > Could you be more specific about how you think these existing contexts
> > are broken? The above looks perfectly good and standard and the
> > existing contexts do a reasonable simulation of working. Note that the
> > ZA and ZT contexts don't generate data payload unless userspace has set
> > PSTATE.ZA.
>
> Sorry for not being clear on this as I was only referring to the
> comments in file arch/arm64/include/uapi/asm/sigcontext.h and no code
> as such is broken.
>
> * Allocation of __reserved[]:
> * (Note: records do not necessarily occur in the order shown here.)
> *
> * size description
> *
> * 0x210 fpsimd_context
> * 0x10 esr_context
> * 0x8a0 sve_context (vl <= 64) (optional)
> * 0x20 extra_context (optional)
> * 0x10 terminator (null _aarch64_ctx)
> *
> * 0x510 (reserved for future allocation)
>
> Here I think that optional context like za, zt, fpmr and poe should have
> size mentioned here to make the description consistent.As you said ZA
> and ZT context are enabled by userspace so some extra details can be
> added for them too.
Regarding this, __reserved[] is looking very full now.
I'll post a draft patch separately, since I think the update could
benefit from separate discussion, but my back-of-the-envelope
calculation suggests that (before this patch) we are down to 0x90
bytes of free space (i.e., over 96% full).
I wonder whether it is time to start pushing back on adding a new
_foo_context for every individual register, though?
Maybe we could add some kind of _misc_context for miscellaneous 64-bit
regs.
[...]
Cheers
---Dave
