On Mon, Jun 03, 2024 at 02:51:46PM +0530, Amit Daniel Kachhap wrote:

On 5/31/24 22:09, Mark Brown wrote:

quoted

On Tue, May 28, 2024 at 12:26:54PM +0530, Amit Daniel Kachhap wrote:

quoted

On 5/3/24 18:31, Joey Gouly wrote:

quoted

quoted

+#define POE_MAGIC	0x504f4530
+struct poe_context {
+	struct _aarch64_ctx head;
+	__u64 por_el0;
+};

quoted

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