Re: [PATCH v12 20/40] arm64/sme: Implement streaming SVE signal handling

2022-03-17 Thread Thiago Jung Bauermann


Hello,

Mark Brown  writes:

> @@ -186,9 +189,16 @@ struct sve_context {
>   * sve_context.vl must equal the thread's current vector length when
>   * doing a sigreturn.
>   *
> + * On systems with support for SME the SVE register state may reflect either
> + * streaming or non-streaming mode.  In streaming mode the streaming mode
> + * vector length will be used and the flag SVE_SIG_FLAG_SM will be set in
> + * the flags field. It is permitted to enter or leave streaming mode in
> + * a signal return, applications should take care to ensure that any 
> difference
> + * in vector length between the two modes is handled, including any resixing
> + * and movement of context blocks.

s/resixing/resizing/

-- 
Thiago
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm


Re: [PATCH v12 20/40] arm64/sme: Implement streaming SVE signal handling

2022-03-02 Thread Catalin Marinas
On Fri, Feb 25, 2022 at 04:59:03PM +, Mark Brown wrote:
> When in streaming mode we have the same set of SVE registers as we do in
> regular SVE mode with the exception of FFR and the use of the SME vector
> length. Provide signal handling for these registers by taking one of the
> reserved words in the SVE signal context as a flags field and defining a
> flag which is set for streaming mode. When the flag is set the vector
> length is set to the streaming mode vector length and we save and
> restore streaming mode data. We support entering or leaving streaming
> mode based on the value of the flag but do not support changing the
> vector length, this is not currently supported SVE signal handling.
> 
> We could instead allocate a separate record in the signal frame for the
> streaming mode SVE context but this inflates the size of the maximal signal
> frame required and adds complication when validating signal frames from
> userspace, especially given the current structure of the code.
> 
> Any implementation of support for streaming mode vectors in signals will
> have some potential for causing issues for applications that attempt to
> handle SVE vectors in signals, use streaming mode but do not understand
> streaming mode in their signal handling code, it is hard to identify a
> case that is clearly better than any other - they all have cases where
> they could cause unexpected register corruption or faults.
> 
> Signed-off-by: Mark Brown 

Reviewed-by: Catalin Marinas 
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm


[PATCH v12 20/40] arm64/sme: Implement streaming SVE signal handling

2022-02-25 Thread Mark Brown
When in streaming mode we have the same set of SVE registers as we do in
regular SVE mode with the exception of FFR and the use of the SME vector
length. Provide signal handling for these registers by taking one of the
reserved words in the SVE signal context as a flags field and defining a
flag which is set for streaming mode. When the flag is set the vector
length is set to the streaming mode vector length and we save and
restore streaming mode data. We support entering or leaving streaming
mode based on the value of the flag but do not support changing the
vector length, this is not currently supported SVE signal handling.

We could instead allocate a separate record in the signal frame for the
streaming mode SVE context but this inflates the size of the maximal signal
frame required and adds complication when validating signal frames from
userspace, especially given the current structure of the code.

Any implementation of support for streaming mode vectors in signals will
have some potential for causing issues for applications that attempt to
handle SVE vectors in signals, use streaming mode but do not understand
streaming mode in their signal handling code, it is hard to identify a
case that is clearly better than any other - they all have cases where
they could cause unexpected register corruption or faults.

Signed-off-by: Mark Brown 
---
 arch/arm64/include/asm/processor.h   |  8 +
 arch/arm64/include/uapi/asm/sigcontext.h | 16 +++--
 arch/arm64/kernel/signal.c   | 42 ++--
 3 files changed, 53 insertions(+), 13 deletions(-)

diff --git a/arch/arm64/include/asm/processor.h 
b/arch/arm64/include/asm/processor.h
index 5a5c5edd76df..29e0f87b5dd5 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -189,6 +189,14 @@ static inline unsigned int thread_get_sme_vl(struct 
thread_struct *thread)
return thread_get_vl(thread, ARM64_VEC_SME);
 }
 
+static inline unsigned int thread_get_cur_vl(struct thread_struct *thread)
+{
+   if (system_supports_sme() && (thread->svcr & SYS_SVCR_EL0_SM_MASK))
+   return thread_get_sme_vl(thread);
+   else
+   return thread_get_sve_vl(thread);
+}
+
 unsigned int task_get_vl(const struct task_struct *task, enum vec_type type);
 void task_set_vl(struct task_struct *task, enum vec_type type,
 unsigned long vl);
diff --git a/arch/arm64/include/uapi/asm/sigcontext.h 
b/arch/arm64/include/uapi/asm/sigcontext.h
index 0c796c795dbe..3a3366d4fbc2 100644
--- a/arch/arm64/include/uapi/asm/sigcontext.h
+++ b/arch/arm64/include/uapi/asm/sigcontext.h
@@ -134,9 +134,12 @@ struct extra_context {
 struct sve_context {
struct _aarch64_ctx head;
__u16 vl;
-   __u16 __reserved[3];
+   __u16 flags;
+   __u16 __reserved[2];
 };
 
+#define SVE_SIG_FLAG_SM0x1 /* Context describes streaming mode */
+
 #endif /* !__ASSEMBLY__ */
 
 #include 
@@ -186,9 +189,16 @@ struct sve_context {
  * sve_context.vl must equal the thread's current vector length when
  * doing a sigreturn.
  *
+ * On systems with support for SME the SVE register state may reflect either
+ * streaming or non-streaming mode.  In streaming mode the streaming mode
+ * vector length will be used and the flag SVE_SIG_FLAG_SM will be set in
+ * the flags field. It is permitted to enter or leave streaming mode in
+ * a signal return, applications should take care to ensure that any difference
+ * in vector length between the two modes is handled, including any resixing
+ * and movement of context blocks.
  *
- * Note: for all these macros, the "vq" argument denotes the SVE
- * vector length in quadwords (i.e., units of 128 bits).
+ * Note: for all these macros, the "vq" argument denotes the vector length
+ * in quadwords (i.e., units of 128 bits).
  *
  * The correct way to obtain vq is to use sve_vq_from_vl(vl).  The
  * result is valid if and only if sve_vl_valid(vl) is true.  This is
diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index cda04fd7..8931954e7b39 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -227,11 +227,17 @@ static int preserve_sve_context(struct sve_context __user 
*ctx)
 {
int err = 0;
u16 reserved[ARRAY_SIZE(ctx->__reserved)];
+   u16 flags = 0;
unsigned int vl = task_get_sve_vl(current);
unsigned int vq = 0;
 
-   if (test_thread_flag(TIF_SVE))
+   if (thread_sm_enabled(>thread)) {
+   vl = task_get_sme_vl(current);
vq = sve_vq_from_vl(vl);
+   flags |= SVE_SIG_FLAG_SM;
+   } else if (test_thread_flag(TIF_SVE)) {
+   vq = sve_vq_from_vl(vl);
+   }
 
memset(reserved, 0, sizeof(reserved));
 
@@ -239,6 +245,7 @@ static int preserve_sve_context(struct sve_context __user 
*ctx)
__put_user_error(round_up(SVE_SIG_CONTEXT_SIZE(vq), 16),
 >head.size, err);