From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/4] arm64: add abstractions for FPSIMD state manipulation
Date: Fri, 21 Feb 2014 14:25:15 +0000 [thread overview]
Message-ID: <20140221142515.GC25351@arm.com> (raw)
In-Reply-To: <1391620418-3999-2-git-send-email-ard.biesheuvel@linaro.org>
On Wed, Feb 05, 2014 at 05:13:35PM +0000, Ard Biesheuvel wrote:
> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> index 4aef42a04bdc..eeb003f54ad0 100644
> --- a/arch/arm64/kernel/fpsimd.c
> +++ b/arch/arm64/kernel/fpsimd.c
> @@ -34,6 +34,10 @@
> #define FPEXC_IXF (1 << 4)
> #define FPEXC_IDF (1 << 7)
>
> +/* defined in entry-fpsimd.S but only used in this unit */
> +void fpsimd_save_state(struct fpsimd_state *state);
> +void fpsimd_load_state(struct fpsimd_state *state);
This functions still make sense for some situations where
fpsimd_get_task_state() is confusing.
> +
> /*
> * Trapped FP/ASIMD access.
> */
> @@ -87,6 +91,33 @@ void fpsimd_flush_thread(void)
> preempt_enable();
> }
>
> +/*
> + * Sync the saved FPSIMD context with the FPSIMD register file
> + */
> +struct fpsimd_state *fpsimd_get_task_state(void)
> +{
> + fpsimd_save_state(¤t->thread.fpsimd_state);
> + return ¤t->thread.fpsimd_state;
> +}
> +
> +/*
> + * Load a new FPSIMD state into the FPSIMD register file.
> + */
> +void fpsimd_set_task_state(struct fpsimd_state *state)
> +{
> + fpsimd_load_state(state);
> +}
Maybe s/task/current/. But in general I see a "get" function as not
having side-effects while here it populates the fpsimd_state. I don't
think the code gets clearer.
> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> index 1c0a9be2ffa8..bfa8214f92d1 100644
> --- a/arch/arm64/kernel/process.c
> +++ b/arch/arm64/kernel/process.c
> @@ -199,7 +199,7 @@ void release_thread(struct task_struct *dead_task)
>
> int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src)
> {
> - fpsimd_save_state(¤t->thread.fpsimd_state);
> + fpsimd_get_task_state();
That's where get vs save looks strange to me.
> @@ -746,24 +745,29 @@ static int compat_vfp_set(struct task_struct *target,
> unsigned int pos, unsigned int count,
> const void *kbuf, const void __user *ubuf)
> {
> - struct user_fpsimd_state *uregs;
> + struct user_fpsimd_state newstate;
> compat_ulong_t fpscr;
> int ret;
>
> if (pos + count > VFP_STATE_SIZE)
> return -EIO;
>
> - uregs = &target->thread.fpsimd_state.user_fpsimd;
> + /*
> + * We will not overwrite the entire FPSIMD state, so we need to
> + * initialize 'newstate' with sane values.
> + */
> + newstate = *fpsimd_get_user_state(target);
>
> - ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, uregs, 0,
> + ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, &newstate, 0,
> VFP_STATE_SIZE - sizeof(compat_ulong_t));
>
> if (count && !ret) {
> ret = get_user(fpscr, (compat_ulong_t *)ubuf);
> - uregs->fpsr = fpscr & VFP_FPSCR_STAT_MASK;
> - uregs->fpcr = fpscr & VFP_FPSCR_CTRL_MASK;
> + newstate.fpsr = fpscr & VFP_FPSCR_STAT_MASK;
> + newstate.fpcr = fpscr & VFP_FPSCR_CTRL_MASK;
> }
>
> + fpsimd_set_user_state(target, &newstate);
> return ret;
> }
What's the reason for this change? The patch is aimed at adding
abstractions but it does some more. Now you save half KB on the stack as
user_fpsimd_state. What if at some point we grow this structure?
--
Catalin
next prev parent reply other threads:[~2014-02-21 14:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-05 17:13 [PATCH v2 0/4] kernel mode NEON optimizations Ard Biesheuvel
2014-02-05 17:13 ` [PATCH v2 1/4] arm64: add abstractions for FPSIMD state manipulation Ard Biesheuvel
2014-02-21 14:25 ` Catalin Marinas [this message]
2014-02-21 14:52 ` Ard Biesheuvel
2014-02-05 17:13 ` [PATCH v2 2/4] arm64: defer reloading a task's FPSIMD state to userland resume Ard Biesheuvel
2014-02-21 17:48 ` Catalin Marinas
2014-02-21 18:33 ` Ard Biesheuvel
2014-02-24 10:14 ` Catalin Marinas
2014-02-05 17:13 ` [PATCH v2 3/4] arm64: add support for kernel mode NEON in interrupt context Ard Biesheuvel
2014-02-05 17:13 ` [PATCH v2 4/4] arm64: add Crypto Extensions based synchronous core AES cipher Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140221142515.GC25351@arm.com \
--to=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.