Linux-RISC-V Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Conor Dooley <conor.dooley@microchip.com>
To: Andy Chiu <andy.chiu@sifive.com>
Cc: linux-riscv@lists.infradead.org, palmer@dabbelt.com,
	"Anup Patel" <apatel@ventanamicro.com>,
	guoren@linux.alibaba.com,
	"Alexandre Ghiti" <alexghiti@rivosinc.com>,
	"Jisheng Zhang" <jszhang@kernel.org>,
	"Sia Jee Heng" <jeeheng.sia@starfivetech.com>,
	"Xianting Tian" <xianting.tian@linux.alibaba.com>,
	anup@brainfault.org, "Masahiro Yamada" <masahiroy@kernel.org>,
	atishp@atishpatra.org, vineetg@rivosinc.com,
	"Björn Töpel" <bjorn@rivosinc.com>,
	"Vincent Chen" <vincent.chen@sifive.com>,
	bjorn@kernel.org, "Albert Ou" <aou@eecs.berkeley.edu>,
	"Guo Ren" <guoren@kernel.org>,
	paul.walmsley@sifive.com, greentime.hu@sifive.com,
	heiko.stuebner@vrull.eu
Subject: Re: [v1, 2/6] riscv: Add support for kernel mode vector
Date: Mon, 17 Jul 2023 11:22:43 +0100	[thread overview]
Message-ID: <20230717-caution-haste-2d9c7b7478b8@wendy> (raw)
In-Reply-To: <20230715150032.6917-3-andy.chiu@sifive.com>


[-- Attachment #1.1: Type: text/plain, Size: 4090 bytes --]

On Sat, Jul 15, 2023 at 03:00:28PM +0000, Andy Chiu wrote:
> From: Greentime Hu <greentime.hu@sifive.com>
> 
> Add kernel_rvv_begin() and kernel_rvv_end() function declarations
> and corresponding definitions in kernel_mode_vector.c
> 
> These are needed to wrap uses of vector in kernel mode.
> 
> Co-developed-by: Vincent Chen <vincent.chen@sifive.com>
> Signed-off-by: Vincent Chen <vincent.chen@sifive.com>
> Signed-off-by: Greentime Hu <greentime.hu@sifive.com>
> Signed-off-by: Andy Chiu <andy.chiu@sifive.com>
> ---
>  arch/riscv/include/asm/vector.h        |   2 +
>  arch/riscv/kernel/Makefile             |   1 +
>  arch/riscv/kernel/kernel_mode_vector.c | 129 +++++++++++++++++++++++++
>  3 files changed, 132 insertions(+)
>  create mode 100644 arch/riscv/kernel/kernel_mode_vector.c
> 
> diff --git a/arch/riscv/include/asm/vector.h b/arch/riscv/include/asm/vector.h
> index a4f3705fd144..9831b19153ae 100644
> --- a/arch/riscv/include/asm/vector.h
> +++ b/arch/riscv/include/asm/vector.h
> @@ -22,6 +22,8 @@
>  extern unsigned long riscv_v_vsize;
>  int riscv_v_setup_vsize(void);
>  bool riscv_v_first_use_handler(struct pt_regs *regs);
> +int kernel_rvv_begin(void);
> +void kernel_rvv_end(void);

So, we ditched all of the "rvv" stuff in the last series, using either
"vector" - has_vector() - or "riscv_v". I'd rather not introduce a third
naming scheme for vector related things...

Given what you add below is full of other things that use "vector", how
does s/rvv/vector/ sound here?


> diff --git a/arch/riscv/kernel/kernel_mode_vector.c b/arch/riscv/kernel/kernel_mode_vector.c
> new file mode 100644
> index 000000000000..c0c152c501a5
> --- /dev/null
> +++ b/arch/riscv/kernel/kernel_mode_vector.c

> +/*
> + * kernel_rvv_begin(): obtain the CPU vector registers for use by the calling
> + * context
> + *
> + * Must not be called unless may_use_vector() returns true.
> + * Task context in the vector registers is saved back to memory as necessary.
> + *
> + * A matching call to kernel_rvv_end() must be made before returning from the
> + * calling context.
> + *
> + * The caller may freely use the vector registers until kernel_rvv_end() is
> + * called.
> + */
> +int kernel_rvv_begin(void)

How come this returns an int, but you never actually check the result? The
other kernel_*_begin()s don't seem to return anything other than void.

> +{
> +	if (!has_vector())
> +		return -EOPNOTSUPP;
> +
> +	if (!may_use_vector())
> +		return -EPERM;

I notice arm64 takes a stronger approach. There, if the has() call
fails, it has a WARN_ON(). For the !may_use() case, it BUG()s.
Since users are forced to check may_use_vector() before calling
kernel_rvv_begin().

Is there a reason that we should not take the same approach?

> +
> +	/* Save vector state, if any */
> +	riscv_v_vstate_save(current, task_pt_regs(current));
> +
> +	/* Acquire kernel mode vector */
> +	get_cpu_vector_context();
> +
> +	/* Enable vector */

These three comments are mostly a statement of the obvious, no?

> +	riscv_v_enable();
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(kernel_rvv_begin);
> +
> +/*
> + * kernel_rvv_end(): give the CPU vector registers back to the current task
> + *
> + * Must be called from a context in which kernel_rvv_begin() was previously
> + * called, with no call to kernel_rvv_end() in the meantime.
> + *
> + * The caller must not use the vector registers after this function is called,
> + * unless kernel_rvv_begin() is called again in the meantime.
> + */
> +void kernel_rvv_end(void)
> +{
> +	if (WARN_ON(!has_vector()))

But there is a WARN_ON() here...

> +		return;
> +
> +	/* Restore vector state, if any */
> +	riscv_v_vstate_set_restore(current, task_pt_regs(current));
> +
> +	/* disable vector */
> +	riscv_v_disable();
> +
> +	/* release kernel mode vector */

Again, comments kinda state the obvious, no?

Otherwise, this stuff looks generally fine to me & similar to what is
being done elsewhere.

Thanks,
Conor.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2023-07-17 10:24 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-15 15:00 [v1, 0/6] riscv: support kernel-mode Vector Andy Chiu
2023-07-15 15:00 ` [v1, 1/6] riscv: sched: defer restoring Vector context for user Andy Chiu
2023-07-17  9:46   ` Conor Dooley
2023-07-17 16:03     ` Andy Chiu
2023-07-15 15:00 ` [v1, 2/6] riscv: Add support for kernel mode vector Andy Chiu
2023-07-17 10:22   ` Conor Dooley [this message]
2023-07-20 14:54     ` Andy Chiu
2023-07-15 15:00 ` [v1, 3/6] riscv: Add vector extension XOR implementation Andy Chiu
2023-07-17 10:25   ` Conor Dooley
2023-07-20 14:56     ` Andy Chiu
2023-07-15 15:00 ` [v1, 4/6] riscv: vector: do not pass task_struct into riscv_v_vstate_{save,restore}() Andy Chiu
2023-07-17 10:32   ` Conor Dooley
2023-07-20 14:59     ` Andy Chiu
2023-07-15 15:00 ` [v1, 5/6] riscv: vector: allow kernel-mode Vector with preemption Andy Chiu
2023-07-17 11:05   ` Conor Dooley
2023-07-20 15:13     ` Andy Chiu
2023-07-15 15:00 ` [v1, 6/6] riscv: vector: enable preemptive kernel-mode Vector to be built Andy Chiu
2023-07-17 11:11   ` Conor Dooley
2023-07-16  9:26 ` [v1, 0/6] riscv: support kernel-mode Vector Heiko Stuebner

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=20230717-caution-haste-2d9c7b7478b8@wendy \
    --to=conor.dooley@microchip.com \
    --cc=alexghiti@rivosinc.com \
    --cc=andy.chiu@sifive.com \
    --cc=anup@brainfault.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=apatel@ventanamicro.com \
    --cc=atishp@atishpatra.org \
    --cc=bjorn@kernel.org \
    --cc=bjorn@rivosinc.com \
    --cc=greentime.hu@sifive.com \
    --cc=guoren@kernel.org \
    --cc=guoren@linux.alibaba.com \
    --cc=heiko.stuebner@vrull.eu \
    --cc=jeeheng.sia@starfivetech.com \
    --cc=jszhang@kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=masahiroy@kernel.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=vincent.chen@sifive.com \
    --cc=vineetg@rivosinc.com \
    --cc=xianting.tian@linux.alibaba.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox