On Fri, Sep 03, 2021 at 05:14:28PM +1000, Benjamin Herrenschmidt wrote:

Well, the problem as far as I can tell is that the glibc implementation
of these today. They support "FPSIMD" but that's about it (so no SVE or
anything else) along with a comment:

	/* Check for FP SIMD context.  We don't support restoring
	   contexts created by the kernel, so this context must have
	   been created by getcontext.  Hence we can rely on the
	   first extension block being the FP SIMD context.  */

The kernel does generate a FPSIMD context in addition to any SVE context
for compatibility, though that doesn't mean you can actually fully
restore them successfully with glibc.  For contexts generated by glibc
note that unless a function signature involves a SVE type the SVE
register contents are caller saved:

   https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#id48

so glibc will be fine just ignoring SVE when it generates contexts given
that it'll be doing that inside a non-SVE function call.

Like Szabolcs says BTI is going to cause issues restoring kernel
generated contexts even without extensions like SVE adding extra
register state.

quoted

You can figure out the maximum possible size for a context so it would
be possible to define a mechanism for pointing to extra data I guess but
yeah, it's going to be a problem when we start seeing systems with large
enough register state.

Extra data for userspace generated ucontext's isn't going to fly much,
there's really no "place" to put it (those things can be part of
structures etc...) and no "hook" to allocate/free sub structures.

So you need whatever struct ucontext is used in userspace to be big
enough.

Indeed, it'd have to be joined up with an increase of the userspace
ucontext.

That said, I think the current one might be enough for sve512 (I need
to check) and we could have glibc define something much bigger (16KB ?)
without much damage I suspect.

Yes, the current context should be big enough for 512 bit SVE - that's
why the kernel clamps the default SVE vector length to 512 bits, so we
sidestep these issues by default even if the user happens to have a
system that can do larger vector lengths.  Not an immediate issue with
actual hardware in any case, though that code currently kicks in on
qemu's cpu=max.