On Fri, Oct 13, 2017 at 06:17:59PM +0100, Dave P Martin wrote:

On Fri, Oct 13, 2017 at 03:24:21PM +0100, Catalin Marinas wrote:

quoted

On Tue, Oct 10, 2017 at 07:38:43PM +0100, Dave P Martin wrote:

quoted

+* If the SVE context is too big to fit in sigcontext.__reserved[], then extra
+  space is allocated on the stack, an extra_context record is written in
+  __reserved[] referencing this space.  sve_context is then written in the
+  extra space.  Refer to [1] for further details about this mechanism.

Does this document require that the user stack is sufficiently large or
should we cap the vector length (prior to the last two RFC patches)?

We don't know how much free stack space there actually is until the
signal is delivered.

[...]

Possibly sigaltstack() should fail with ENOMEM if ss_size is too small
for the maximum VL supported by the system, but strictly speaking that
violates POSIX if ss_size >= MINSIGSTKSZ.

We also don't know whether the application is going to use SVE or not,
so MINSIGSTKSZ could be just fine. I don't have a better idea here
without the last two RFC patches. So just ignore my comment.

quoted

quoted

+5.  Signal return
+-----------------
+
+When returning from a signal handler:
+
+* If there is no sve_context record in the signal frame, or if the record is
+  present but contains no register data as desribed in the previous section,
+  then the SVE registers/bits become non-live and take unspecified values.
+
+* If sve_context is present in the signal frame and contains full register
+  data, the SVE registers become live and are populated with the specified
+  data.  However, for backward compatibility reasons, bits [127:0] of Z0..Z31
+  are always restored from the corresponding members of fpsimd_context.vregs[]
+  and not from sve_context.  The remaining bits are restored from sve_context.
+
+* Inclusion of fpsimd_context in the signal frame remains mandatory,
+  irrespective of whether sve_context is present or not.

Could we relax this? I'm not sure it's worth it.

It would be cleaner, but I think it's an ABI break.  Consider a non-SVE
program that gets linked (perhaps dynamically) against a library variant
that happens to use SVE:

I agree that in general the kernel always needs to provide user space
with FPSIMD_MAGIC. I was wondering whether on sigreturn the kernel may
choose not to enforce this. But I'm not sure we have a scenario where it
actually matters (IIUC set/getcontext is done in user space anyway).

-- 
Catalin