qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4 35/45] linux-user/aarch64: Add SM bit to SVE signal contex


From: Peter Maydell
Subject: Re: [PATCH v4 35/45] linux-user/aarch64: Add SM bit to SVE signal context
Date: Mon, 4 Jul 2022 13:02:27 +0100

On Tue, 28 Jun 2022 at 06:04, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> Make sure to zero the currently reserved fields.
>
> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
> ---
>  linux-user/aarch64/signal.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/linux-user/aarch64/signal.c b/linux-user/aarch64/signal.c
> index 7da0e36c6d..3cef2f44cf 100644
> --- a/linux-user/aarch64/signal.c
> +++ b/linux-user/aarch64/signal.c
> @@ -78,7 +78,8 @@ struct target_extra_context {
>  struct target_sve_context {
>      struct target_aarch64_ctx head;
>      uint16_t vl;
> -    uint16_t reserved[3];
> +    uint16_t flags;
> +    uint16_t reserved[2];
>      /* The actual SVE data immediately follows.  It is laid out
>       * according to TARGET_SVE_SIG_{Z,P}REG_OFFSET, based off of
>       * the original struct pointer.
> @@ -101,6 +102,8 @@ struct target_sve_context {
>  #define TARGET_SVE_SIG_CONTEXT_SIZE(VQ) \
>      (TARGET_SVE_SIG_PREG_OFFSET(VQ, 17))
>
> +#define TARGET_SVE_SIG_FLAG_SM  1
> +
>  struct target_rt_sigframe {
>      struct target_siginfo info;
>      struct target_ucontext uc;
> @@ -177,9 +180,13 @@ static void target_setup_sve_record(struct 
> target_sve_context *sve,
>  {
>      int i, j;
>
> +    memset(sve, 0, sizeof(*sve));
>      __put_user(TARGET_SVE_MAGIC, &sve->head.magic);
>      __put_user(size, &sve->head.size);
>      __put_user(vq * TARGET_SVE_VQ_BYTES, &sve->vl);
> +    if (FIELD_EX64(env->svcr, SVCR, SM)) {
> +        __put_user(TARGET_SVE_SIG_FLAG_SM, &sve->flags);
> +    }
>

The kernel documentation says that if this is set then the SVE
record contains the streaming vector length. Does that happen
automatically (ie vq is the right thing for both streaming
and non-streaming) or do we need to do something there?

I gather that the other half of handling this bit (allowing
it to be changed on signal-return) is in a later patch.

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]