All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Stübner <heiko@sntech.de>
To: kvm-riscv@lists.infradead.org
Subject: [PATCH -next v17 10/20] riscv: Allocate user's vector context in the first-use trap
Date: Fri, 31 Mar 2023 15:08:37 +0200	[thread overview]
Message-ID: <2409883.jE0xQCEvom@diego> (raw)
In-Reply-To: <20230327164941.20491-11-andy.chiu@sifive.com>

Am Montag, 27. M?rz 2023, 18:49:30 CEST schrieb Andy Chiu:
> Vector unit is disabled by default for all user processes. Thus, a
> process will take a trap (illegal instruction) into kernel at the first
> time when it uses Vector. Only after then, the kernel allocates V
> context and starts take care of the context for that user process.
> 
> Suggested-by: Richard Henderson <richard.henderson@linaro.org>
> Link: https://lore.kernel.org/r/3923eeee-e4dc-0911-40bf-84c34aee962d at linaro.org
> Signed-off-by: Andy Chiu <andy.chiu@sifive.com>
> ---
>  arch/riscv/include/asm/insn.h   | 29 +++++++++++
>  arch/riscv/include/asm/vector.h |  2 +
>  arch/riscv/kernel/traps.c       | 26 +++++++++-
>  arch/riscv/kernel/vector.c      | 90 +++++++++++++++++++++++++++++++++
>  4 files changed, 145 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/riscv/include/asm/insn.h b/arch/riscv/include/asm/insn.h
> index 8d5c84f2d5ef..4e1505cef8aa 100644
> --- a/arch/riscv/include/asm/insn.h
> +++ b/arch/riscv/include/asm/insn.h
> @@ -137,6 +137,26 @@
>  #define RVG_OPCODE_JALR		0x67
>  #define RVG_OPCODE_JAL		0x6f
>  #define RVG_OPCODE_SYSTEM	0x73
> +#define RVG_SYSTEM_CSR_OFF	20
> +#define RVG_SYSTEM_CSR_MASK	GENMASK(12, 0)

The CSR instructions are all I-type instructions it seems, but I do
understand where this is coming from, as for CSRs this is not an IMM
but an unsigned value

> +/* parts of opcode for RVF, RVD and RVQ */
> +#define RVFDQ_FL_FS_WIDTH_OFF	12
> +#define RVFDQ_FL_FS_WIDTH_MASK	GENMASK(3, 0)
> +#define RVFDQ_FL_FS_WIDTH_W	2
> +#define RVFDQ_FL_FS_WIDTH_D	3
> +#define RVFDQ_LS_FS_WIDTH_Q	4
> +#define RVFDQ_OPCODE_FL		0x07
> +#define RVFDQ_OPCODE_FS		0x27


> +/* parts of opcode for RVV */
> +#define RVV_OPCODE_VECTOR	0x57
> +#define RVV_VL_VS_WIDTH_8	0
> +#define RVV_VL_VS_WIDTH_16	5
> +#define RVV_VL_VS_WIDTH_32	6
> +#define RVV_VL_VS_WIDTH_64	7
> +#define RVV_OPCODE_VL		RVFDQ_OPCODE_FL
> +#define RVV_OPCODE_VS		RVFDQ_OPCODE_FS

Same issue for those (FL_FS + VL_VS), but those even don't declare
being part of any *-type scheme in the spec.

So all of them mix content-definitions (RV*_OPCODE_*) with structure-
definitions and right now I don't know how to feel about that ;-) .

On the one hand I like the original separation, but on the other hand it
doesn't feel useful to put these single-use definitions somewhere above.


>  /* parts of opcode for RVC*/
>  #define RVC_OPCODE_C0		0x0
> @@ -304,6 +324,15 @@ static __always_inline bool riscv_insn_is_branch(u32 code)
>  	(RVC_X(x_, RVC_B_IMM_7_6_OPOFF, RVC_B_IMM_7_6_MASK) << RVC_B_IMM_7_6_OFF) | \
>  	(RVC_IMM_SIGN(x_) << RVC_B_IMM_SIGN_OFF); })
>  
> +#define RVG_EXTRACT_SYSTEM_CSR(x) \
> +	({typeof(x) x_ = (x); RV_X(x_, RVG_SYSTEM_CSR_OFF, RVG_SYSTEM_CSR_MASK); })
> +
> +#define RVFDQ_EXTRACT_FL_FS_WIDTH(x) \
> +	({typeof(x) x_ = (x); RV_X(x_, RVFDQ_FL_FS_WIDTH_OFF, \
> +				   RVFDQ_FL_FS_WIDTH_MASK); })
> +
> +#define RVV_EXRACT_VL_VS_WIDTH(x) RVFDQ_EXTRACT_FL_FS_WIDTH(x)
> +
>  /*
>   * Get the immediate from a J-type instruction.
>   *


> diff --git a/arch/riscv/kernel/vector.c b/arch/riscv/kernel/vector.c
> index 03582e2ade83..ea59f32adf46 100644
> --- a/arch/riscv/kernel/vector.c
> +++ b/arch/riscv/kernel/vector.c
> @@ -4,9 +4,19 @@
>   * Author: Andy Chiu <andy.chiu@sifive.com>
>   */
>  #include <linux/export.h>
> +#include <linux/sched/signal.h>
> +#include <linux/types.h>
> +#include <linux/slab.h>
> +#include <linux/sched.h>
> +#include <linux/uaccess.h>
>  
> +#include <asm/thread_info.h>
> +#include <asm/processor.h>
> +#include <asm/insn.h>
>  #include <asm/vector.h>
>  #include <asm/csr.h>
> +#include <asm/ptrace.h>
> +#include <asm/bug.h>
>  
>  unsigned long riscv_v_vsize __read_mostly;
>  EXPORT_SYMBOL_GPL(riscv_v_vsize);
> @@ -18,3 +28,83 @@ void riscv_v_setup_vsize(void)
>  	riscv_v_vsize = csr_read(CSR_VLENB) * 32;
>  	riscv_v_disable();
>  }
> +
> +static bool insn_is_vector(u32 insn_buf)
> +{
> +	u32 opcode = insn_buf & __INSN_OPCODE_MASK;
> +	bool is_vector = false;
> +	u32 width, csr;
> +
> +	/*
> +	 * All V-related instructions, including CSR operations are 4-Byte. So,
> +	 * do not handle if the instruction length is not 4-Byte.
> +	 */
> +	if (unlikely(GET_INSN_LENGTH(insn_buf) != 4))
> +		return false;
> +
> +	switch (opcode) {
> +	case RVV_OPCODE_VECTOR:
> +		is_vector = true;
> +		break;
> +	case RVV_OPCODE_VL:
> +	case RVV_OPCODE_VS:
> +		width = RVV_EXRACT_VL_VS_WIDTH(insn_buf);
> +		if (width == RVV_VL_VS_WIDTH_8 || width == RVV_VL_VS_WIDTH_16 ||
> +		    width == RVV_VL_VS_WIDTH_32 || width == RVV_VL_VS_WIDTH_64)
> +			is_vector = true;
> +		break;
> +	case RVG_OPCODE_SYSTEM:
> +		csr = RVG_EXTRACT_SYSTEM_CSR(insn_buf);
> +		if ((csr >= CSR_VSTART && csr <= CSR_VCSR) ||
> +		    (csr >= CSR_VL && csr <= CSR_VLENB))
> +			is_vector = true;
> +		break;
> +	}

blank line?

> +	return is_vector;

I guess a matter of style-preference, but the other option would be to
just return true from inside the case elements, and simply false here.


> +}
> +
> +static int riscv_v_thread_zalloc(void)
> +{
> +	void *datap;
> +
> +	datap = kzalloc(riscv_v_vsize, GFP_KERNEL);
> +	if (!datap)
> +		return -ENOMEM;

blank line?

> +	current->thread.vstate.datap = datap;
> +	memset(&current->thread.vstate, 0, offsetof(struct __riscv_v_ext_state,
> +						    datap));
> +	return 0;
> +}
> +
> +bool riscv_v_first_use_handler(struct pt_regs *regs)
> +{
> +	u32 __user *epc = (u32 __user *)regs->epc;
> +	u32 insn = (u32)regs->badaddr;
> +
> +	/* If V has been enabled then it is not the first-use trap */
> +	if (riscv_v_vstate_query(regs))
> +		return false;
> +
> +	/* Get the instruction */
> +	if (!insn) {
> +		if (__get_user(insn, epc))
> +			return false;
> +	}

blank?

> +	/* Filter out non-V instructions */
> +	if (!insn_is_vector(insn))
> +		return false;
> +
> +	/* Sanity check. datap should be null by the time of the first-use trap */
> +	WARN_ON(current->thread.vstate.datap);

blank?

> +	/*
> +	 * Now we sure that this is a V instruction. And it executes in the
> +	 * context where VS has been off. So, try to allocate the user's V
> +	 * context and resume execution.
> +	 */
> +	if (riscv_v_thread_zalloc()) {
> +		force_sig(SIGKILL);
> +		return true;
> +	}
> +	riscv_v_vstate_on(regs);
> +	return true;
> +}
> 

in any case,

Acked-by: Heiko Stuebner <heiko.stuebner@vrull.eu>
Tested-by: Heiko Stuebner <heiko.stuebner@vrull.eu>


Heiko





WARNING: multiple messages have this Message-ID (diff)
From: "Heiko Stübner" <heiko@sntech.de>
To: linux-riscv@lists.infradead.org, palmer@dabbelt.com,
	anup@brainfault.org, atishp@atishpatra.org,
	kvm-riscv@lists.infradead.org, kvm@vger.kernel.org
Cc: vineetg@rivosinc.com, greentime.hu@sifive.com,
	guoren@linux.alibaba.com, "Andy Chiu" <andy.chiu@sifive.com>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	"Andrew Jones" <ajones@ventanamicro.com>,
	"Conor Dooley" <conor.dooley@microchip.com>,
	"Lad Prabhakar" <prabhakar.mahadev-lad.rj@bp.renesas.com>,
	"Liao Chang" <liaochang1@huawei.com>,
	"Jisheng Zhang" <jszhang@kernel.org>,
	"Guo Ren" <guoren@kernel.org>,
	"Vincent Chen" <vincent.chen@sifive.com>,
	"Björn Töpel" <bjorn@rivosinc.com>,
	"Xianting Tian" <xianting.tian@linux.alibaba.com>,
	"Mattias Nissler" <mnissler@rivosinc.com>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"Andy Chiu" <andy.chiu@sifive.com>
Subject: Re: [PATCH -next v17 10/20] riscv: Allocate user's vector context in the first-use trap
Date: Fri, 31 Mar 2023 15:08:37 +0200	[thread overview]
Message-ID: <2409883.jE0xQCEvom@diego> (raw)
In-Reply-To: <20230327164941.20491-11-andy.chiu@sifive.com>

Am Montag, 27. März 2023, 18:49:30 CEST schrieb Andy Chiu:
> Vector unit is disabled by default for all user processes. Thus, a
> process will take a trap (illegal instruction) into kernel at the first
> time when it uses Vector. Only after then, the kernel allocates V
> context and starts take care of the context for that user process.
> 
> Suggested-by: Richard Henderson <richard.henderson@linaro.org>
> Link: https://lore.kernel.org/r/3923eeee-e4dc-0911-40bf-84c34aee962d@linaro.org
> Signed-off-by: Andy Chiu <andy.chiu@sifive.com>
> ---
>  arch/riscv/include/asm/insn.h   | 29 +++++++++++
>  arch/riscv/include/asm/vector.h |  2 +
>  arch/riscv/kernel/traps.c       | 26 +++++++++-
>  arch/riscv/kernel/vector.c      | 90 +++++++++++++++++++++++++++++++++
>  4 files changed, 145 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/riscv/include/asm/insn.h b/arch/riscv/include/asm/insn.h
> index 8d5c84f2d5ef..4e1505cef8aa 100644
> --- a/arch/riscv/include/asm/insn.h
> +++ b/arch/riscv/include/asm/insn.h
> @@ -137,6 +137,26 @@
>  #define RVG_OPCODE_JALR		0x67
>  #define RVG_OPCODE_JAL		0x6f
>  #define RVG_OPCODE_SYSTEM	0x73
> +#define RVG_SYSTEM_CSR_OFF	20
> +#define RVG_SYSTEM_CSR_MASK	GENMASK(12, 0)

The CSR instructions are all I-type instructions it seems, but I do
understand where this is coming from, as for CSRs this is not an IMM
but an unsigned value

> +/* parts of opcode for RVF, RVD and RVQ */
> +#define RVFDQ_FL_FS_WIDTH_OFF	12
> +#define RVFDQ_FL_FS_WIDTH_MASK	GENMASK(3, 0)
> +#define RVFDQ_FL_FS_WIDTH_W	2
> +#define RVFDQ_FL_FS_WIDTH_D	3
> +#define RVFDQ_LS_FS_WIDTH_Q	4
> +#define RVFDQ_OPCODE_FL		0x07
> +#define RVFDQ_OPCODE_FS		0x27


> +/* parts of opcode for RVV */
> +#define RVV_OPCODE_VECTOR	0x57
> +#define RVV_VL_VS_WIDTH_8	0
> +#define RVV_VL_VS_WIDTH_16	5
> +#define RVV_VL_VS_WIDTH_32	6
> +#define RVV_VL_VS_WIDTH_64	7
> +#define RVV_OPCODE_VL		RVFDQ_OPCODE_FL
> +#define RVV_OPCODE_VS		RVFDQ_OPCODE_FS

Same issue for those (FL_FS + VL_VS), but those even don't declare
being part of any *-type scheme in the spec.

So all of them mix content-definitions (RV*_OPCODE_*) with structure-
definitions and right now I don't know how to feel about that ;-) .

On the one hand I like the original separation, but on the other hand it
doesn't feel useful to put these single-use definitions somewhere above.


>  /* parts of opcode for RVC*/
>  #define RVC_OPCODE_C0		0x0
> @@ -304,6 +324,15 @@ static __always_inline bool riscv_insn_is_branch(u32 code)
>  	(RVC_X(x_, RVC_B_IMM_7_6_OPOFF, RVC_B_IMM_7_6_MASK) << RVC_B_IMM_7_6_OFF) | \
>  	(RVC_IMM_SIGN(x_) << RVC_B_IMM_SIGN_OFF); })
>  
> +#define RVG_EXTRACT_SYSTEM_CSR(x) \
> +	({typeof(x) x_ = (x); RV_X(x_, RVG_SYSTEM_CSR_OFF, RVG_SYSTEM_CSR_MASK); })
> +
> +#define RVFDQ_EXTRACT_FL_FS_WIDTH(x) \
> +	({typeof(x) x_ = (x); RV_X(x_, RVFDQ_FL_FS_WIDTH_OFF, \
> +				   RVFDQ_FL_FS_WIDTH_MASK); })
> +
> +#define RVV_EXRACT_VL_VS_WIDTH(x) RVFDQ_EXTRACT_FL_FS_WIDTH(x)
> +
>  /*
>   * Get the immediate from a J-type instruction.
>   *


> diff --git a/arch/riscv/kernel/vector.c b/arch/riscv/kernel/vector.c
> index 03582e2ade83..ea59f32adf46 100644
> --- a/arch/riscv/kernel/vector.c
> +++ b/arch/riscv/kernel/vector.c
> @@ -4,9 +4,19 @@
>   * Author: Andy Chiu <andy.chiu@sifive.com>
>   */
>  #include <linux/export.h>
> +#include <linux/sched/signal.h>
> +#include <linux/types.h>
> +#include <linux/slab.h>
> +#include <linux/sched.h>
> +#include <linux/uaccess.h>
>  
> +#include <asm/thread_info.h>
> +#include <asm/processor.h>
> +#include <asm/insn.h>
>  #include <asm/vector.h>
>  #include <asm/csr.h>
> +#include <asm/ptrace.h>
> +#include <asm/bug.h>
>  
>  unsigned long riscv_v_vsize __read_mostly;
>  EXPORT_SYMBOL_GPL(riscv_v_vsize);
> @@ -18,3 +28,83 @@ void riscv_v_setup_vsize(void)
>  	riscv_v_vsize = csr_read(CSR_VLENB) * 32;
>  	riscv_v_disable();
>  }
> +
> +static bool insn_is_vector(u32 insn_buf)
> +{
> +	u32 opcode = insn_buf & __INSN_OPCODE_MASK;
> +	bool is_vector = false;
> +	u32 width, csr;
> +
> +	/*
> +	 * All V-related instructions, including CSR operations are 4-Byte. So,
> +	 * do not handle if the instruction length is not 4-Byte.
> +	 */
> +	if (unlikely(GET_INSN_LENGTH(insn_buf) != 4))
> +		return false;
> +
> +	switch (opcode) {
> +	case RVV_OPCODE_VECTOR:
> +		is_vector = true;
> +		break;
> +	case RVV_OPCODE_VL:
> +	case RVV_OPCODE_VS:
> +		width = RVV_EXRACT_VL_VS_WIDTH(insn_buf);
> +		if (width == RVV_VL_VS_WIDTH_8 || width == RVV_VL_VS_WIDTH_16 ||
> +		    width == RVV_VL_VS_WIDTH_32 || width == RVV_VL_VS_WIDTH_64)
> +			is_vector = true;
> +		break;
> +	case RVG_OPCODE_SYSTEM:
> +		csr = RVG_EXTRACT_SYSTEM_CSR(insn_buf);
> +		if ((csr >= CSR_VSTART && csr <= CSR_VCSR) ||
> +		    (csr >= CSR_VL && csr <= CSR_VLENB))
> +			is_vector = true;
> +		break;
> +	}

blank line?

> +	return is_vector;

I guess a matter of style-preference, but the other option would be to
just return true from inside the case elements, and simply false here.


> +}
> +
> +static int riscv_v_thread_zalloc(void)
> +{
> +	void *datap;
> +
> +	datap = kzalloc(riscv_v_vsize, GFP_KERNEL);
> +	if (!datap)
> +		return -ENOMEM;

blank line?

> +	current->thread.vstate.datap = datap;
> +	memset(&current->thread.vstate, 0, offsetof(struct __riscv_v_ext_state,
> +						    datap));
> +	return 0;
> +}
> +
> +bool riscv_v_first_use_handler(struct pt_regs *regs)
> +{
> +	u32 __user *epc = (u32 __user *)regs->epc;
> +	u32 insn = (u32)regs->badaddr;
> +
> +	/* If V has been enabled then it is not the first-use trap */
> +	if (riscv_v_vstate_query(regs))
> +		return false;
> +
> +	/* Get the instruction */
> +	if (!insn) {
> +		if (__get_user(insn, epc))
> +			return false;
> +	}

blank?

> +	/* Filter out non-V instructions */
> +	if (!insn_is_vector(insn))
> +		return false;
> +
> +	/* Sanity check. datap should be null by the time of the first-use trap */
> +	WARN_ON(current->thread.vstate.datap);

blank?

> +	/*
> +	 * Now we sure that this is a V instruction. And it executes in the
> +	 * context where VS has been off. So, try to allocate the user's V
> +	 * context and resume execution.
> +	 */
> +	if (riscv_v_thread_zalloc()) {
> +		force_sig(SIGKILL);
> +		return true;
> +	}
> +	riscv_v_vstate_on(regs);
> +	return true;
> +}
> 

in any case,

Acked-by: Heiko Stuebner <heiko.stuebner@vrull.eu>
Tested-by: Heiko Stuebner <heiko.stuebner@vrull.eu>


Heiko




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

WARNING: multiple messages have this Message-ID (diff)
From: "Heiko Stübner" <heiko@sntech.de>
To: linux-riscv@lists.infradead.org, palmer@dabbelt.com,
	anup@brainfault.org, atishp@atishpatra.org,
	kvm-riscv@lists.infradead.org, kvm@vger.kernel.org
Cc: vineetg@rivosinc.com, greentime.hu@sifive.com,
	guoren@linux.alibaba.com, "Andy Chiu" <andy.chiu@sifive.com>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	"Andrew Jones" <ajones@ventanamicro.com>,
	"Conor Dooley" <conor.dooley@microchip.com>,
	"Lad Prabhakar" <prabhakar.mahadev-lad.rj@bp.renesas.com>,
	"Liao Chang" <liaochang1@huawei.com>,
	"Jisheng Zhang" <jszhang@kernel.org>,
	"Guo Ren" <guoren@kernel.org>,
	"Vincent Chen" <vincent.chen@sifive.com>,
	"Björn Töpel" <bjorn@rivosinc.com>,
	"Xianting Tian" <xianting.tian@linux.alibaba.com>,
	"Mattias Nissler" <mnissler@rivosinc.com>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"Andy Chiu" <andy.chiu@sifive.com>
Subject: Re: [PATCH -next v17 10/20] riscv: Allocate user's vector context in the first-use trap
Date: Fri, 31 Mar 2023 15:08:37 +0200	[thread overview]
Message-ID: <2409883.jE0xQCEvom@diego> (raw)
In-Reply-To: <20230327164941.20491-11-andy.chiu@sifive.com>

Am Montag, 27. März 2023, 18:49:30 CEST schrieb Andy Chiu:
> Vector unit is disabled by default for all user processes. Thus, a
> process will take a trap (illegal instruction) into kernel at the first
> time when it uses Vector. Only after then, the kernel allocates V
> context and starts take care of the context for that user process.
> 
> Suggested-by: Richard Henderson <richard.henderson@linaro.org>
> Link: https://lore.kernel.org/r/3923eeee-e4dc-0911-40bf-84c34aee962d@linaro.org
> Signed-off-by: Andy Chiu <andy.chiu@sifive.com>
> ---
>  arch/riscv/include/asm/insn.h   | 29 +++++++++++
>  arch/riscv/include/asm/vector.h |  2 +
>  arch/riscv/kernel/traps.c       | 26 +++++++++-
>  arch/riscv/kernel/vector.c      | 90 +++++++++++++++++++++++++++++++++
>  4 files changed, 145 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/riscv/include/asm/insn.h b/arch/riscv/include/asm/insn.h
> index 8d5c84f2d5ef..4e1505cef8aa 100644
> --- a/arch/riscv/include/asm/insn.h
> +++ b/arch/riscv/include/asm/insn.h
> @@ -137,6 +137,26 @@
>  #define RVG_OPCODE_JALR		0x67
>  #define RVG_OPCODE_JAL		0x6f
>  #define RVG_OPCODE_SYSTEM	0x73
> +#define RVG_SYSTEM_CSR_OFF	20
> +#define RVG_SYSTEM_CSR_MASK	GENMASK(12, 0)

The CSR instructions are all I-type instructions it seems, but I do
understand where this is coming from, as for CSRs this is not an IMM
but an unsigned value

> +/* parts of opcode for RVF, RVD and RVQ */
> +#define RVFDQ_FL_FS_WIDTH_OFF	12
> +#define RVFDQ_FL_FS_WIDTH_MASK	GENMASK(3, 0)
> +#define RVFDQ_FL_FS_WIDTH_W	2
> +#define RVFDQ_FL_FS_WIDTH_D	3
> +#define RVFDQ_LS_FS_WIDTH_Q	4
> +#define RVFDQ_OPCODE_FL		0x07
> +#define RVFDQ_OPCODE_FS		0x27


> +/* parts of opcode for RVV */
> +#define RVV_OPCODE_VECTOR	0x57
> +#define RVV_VL_VS_WIDTH_8	0
> +#define RVV_VL_VS_WIDTH_16	5
> +#define RVV_VL_VS_WIDTH_32	6
> +#define RVV_VL_VS_WIDTH_64	7
> +#define RVV_OPCODE_VL		RVFDQ_OPCODE_FL
> +#define RVV_OPCODE_VS		RVFDQ_OPCODE_FS

Same issue for those (FL_FS + VL_VS), but those even don't declare
being part of any *-type scheme in the spec.

So all of them mix content-definitions (RV*_OPCODE_*) with structure-
definitions and right now I don't know how to feel about that ;-) .

On the one hand I like the original separation, but on the other hand it
doesn't feel useful to put these single-use definitions somewhere above.


>  /* parts of opcode for RVC*/
>  #define RVC_OPCODE_C0		0x0
> @@ -304,6 +324,15 @@ static __always_inline bool riscv_insn_is_branch(u32 code)
>  	(RVC_X(x_, RVC_B_IMM_7_6_OPOFF, RVC_B_IMM_7_6_MASK) << RVC_B_IMM_7_6_OFF) | \
>  	(RVC_IMM_SIGN(x_) << RVC_B_IMM_SIGN_OFF); })
>  
> +#define RVG_EXTRACT_SYSTEM_CSR(x) \
> +	({typeof(x) x_ = (x); RV_X(x_, RVG_SYSTEM_CSR_OFF, RVG_SYSTEM_CSR_MASK); })
> +
> +#define RVFDQ_EXTRACT_FL_FS_WIDTH(x) \
> +	({typeof(x) x_ = (x); RV_X(x_, RVFDQ_FL_FS_WIDTH_OFF, \
> +				   RVFDQ_FL_FS_WIDTH_MASK); })
> +
> +#define RVV_EXRACT_VL_VS_WIDTH(x) RVFDQ_EXTRACT_FL_FS_WIDTH(x)
> +
>  /*
>   * Get the immediate from a J-type instruction.
>   *


> diff --git a/arch/riscv/kernel/vector.c b/arch/riscv/kernel/vector.c
> index 03582e2ade83..ea59f32adf46 100644
> --- a/arch/riscv/kernel/vector.c
> +++ b/arch/riscv/kernel/vector.c
> @@ -4,9 +4,19 @@
>   * Author: Andy Chiu <andy.chiu@sifive.com>
>   */
>  #include <linux/export.h>
> +#include <linux/sched/signal.h>
> +#include <linux/types.h>
> +#include <linux/slab.h>
> +#include <linux/sched.h>
> +#include <linux/uaccess.h>
>  
> +#include <asm/thread_info.h>
> +#include <asm/processor.h>
> +#include <asm/insn.h>
>  #include <asm/vector.h>
>  #include <asm/csr.h>
> +#include <asm/ptrace.h>
> +#include <asm/bug.h>
>  
>  unsigned long riscv_v_vsize __read_mostly;
>  EXPORT_SYMBOL_GPL(riscv_v_vsize);
> @@ -18,3 +28,83 @@ void riscv_v_setup_vsize(void)
>  	riscv_v_vsize = csr_read(CSR_VLENB) * 32;
>  	riscv_v_disable();
>  }
> +
> +static bool insn_is_vector(u32 insn_buf)
> +{
> +	u32 opcode = insn_buf & __INSN_OPCODE_MASK;
> +	bool is_vector = false;
> +	u32 width, csr;
> +
> +	/*
> +	 * All V-related instructions, including CSR operations are 4-Byte. So,
> +	 * do not handle if the instruction length is not 4-Byte.
> +	 */
> +	if (unlikely(GET_INSN_LENGTH(insn_buf) != 4))
> +		return false;
> +
> +	switch (opcode) {
> +	case RVV_OPCODE_VECTOR:
> +		is_vector = true;
> +		break;
> +	case RVV_OPCODE_VL:
> +	case RVV_OPCODE_VS:
> +		width = RVV_EXRACT_VL_VS_WIDTH(insn_buf);
> +		if (width == RVV_VL_VS_WIDTH_8 || width == RVV_VL_VS_WIDTH_16 ||
> +		    width == RVV_VL_VS_WIDTH_32 || width == RVV_VL_VS_WIDTH_64)
> +			is_vector = true;
> +		break;
> +	case RVG_OPCODE_SYSTEM:
> +		csr = RVG_EXTRACT_SYSTEM_CSR(insn_buf);
> +		if ((csr >= CSR_VSTART && csr <= CSR_VCSR) ||
> +		    (csr >= CSR_VL && csr <= CSR_VLENB))
> +			is_vector = true;
> +		break;
> +	}

blank line?

> +	return is_vector;

I guess a matter of style-preference, but the other option would be to
just return true from inside the case elements, and simply false here.


> +}
> +
> +static int riscv_v_thread_zalloc(void)
> +{
> +	void *datap;
> +
> +	datap = kzalloc(riscv_v_vsize, GFP_KERNEL);
> +	if (!datap)
> +		return -ENOMEM;

blank line?

> +	current->thread.vstate.datap = datap;
> +	memset(&current->thread.vstate, 0, offsetof(struct __riscv_v_ext_state,
> +						    datap));
> +	return 0;
> +}
> +
> +bool riscv_v_first_use_handler(struct pt_regs *regs)
> +{
> +	u32 __user *epc = (u32 __user *)regs->epc;
> +	u32 insn = (u32)regs->badaddr;
> +
> +	/* If V has been enabled then it is not the first-use trap */
> +	if (riscv_v_vstate_query(regs))
> +		return false;
> +
> +	/* Get the instruction */
> +	if (!insn) {
> +		if (__get_user(insn, epc))
> +			return false;
> +	}

blank?

> +	/* Filter out non-V instructions */
> +	if (!insn_is_vector(insn))
> +		return false;
> +
> +	/* Sanity check. datap should be null by the time of the first-use trap */
> +	WARN_ON(current->thread.vstate.datap);

blank?

> +	/*
> +	 * Now we sure that this is a V instruction. And it executes in the
> +	 * context where VS has been off. So, try to allocate the user's V
> +	 * context and resume execution.
> +	 */
> +	if (riscv_v_thread_zalloc()) {
> +		force_sig(SIGKILL);
> +		return true;
> +	}
> +	riscv_v_vstate_on(regs);
> +	return true;
> +}
> 

in any case,

Acked-by: Heiko Stuebner <heiko.stuebner@vrull.eu>
Tested-by: Heiko Stuebner <heiko.stuebner@vrull.eu>


Heiko




  parent reply	other threads:[~2023-03-31 13:08 UTC|newest]

Thread overview: 129+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-27 16:49 [PATCH -next v17 00/20] riscv: Add vector ISA support Andy Chiu
2023-03-27 16:49 ` Andy Chiu
2023-03-27 16:49 ` Andy Chiu
2023-03-27 16:49 ` [PATCH -next v17 01/20] riscv: Rename __switch_to_aux() -> fpu Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-27 16:49 ` [PATCH -next v17 02/20] riscv: Extending cpufeature.c to detect V-extension Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-31 10:45   ` Heiko Stübner
2023-03-31 10:45     ` Heiko Stübner
2023-03-31 10:45     ` Heiko Stübner
2023-03-27 16:49 ` [PATCH -next v17 03/20] riscv: Add new csr defines related to vector extension Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-31 16:03   ` Heiko Stübner
2023-03-31 16:03     ` Heiko Stübner
2023-03-31 16:03     ` Heiko Stübner
2023-03-27 16:49 ` [PATCH -next v17 04/20] riscv: Clear vector regfile on bootup Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-31 10:53   ` Heiko Stübner
2023-03-31 10:53     ` Heiko Stübner
2023-03-31 10:53     ` Heiko Stübner
2023-03-27 16:49 ` [PATCH -next v17 05/20] riscv: Disable Vector Instructions for kernel itself Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-31 10:56   ` Heiko Stübner
2023-03-31 10:56     ` Heiko Stübner
2023-03-31 10:56     ` Heiko Stübner
2023-03-27 16:49 ` [PATCH -next v17 06/20] riscv: Introduce Vector enable/disable helpers Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-31 10:56   ` Heiko Stübner
2023-03-31 10:56     ` Heiko Stübner
2023-03-31 10:56     ` Heiko Stübner
2023-03-27 16:49 ` [PATCH -next v17 07/20] riscv: Introduce riscv_v_vsize to record size of Vector context Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-31 11:02   ` Heiko Stübner
2023-03-31 11:02     ` Heiko Stübner
2023-03-31 11:02     ` Heiko Stübner
2023-03-27 16:49 ` [PATCH -next v17 08/20] riscv: Introduce struct/helpers to save/restore per-task Vector state Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-31 11:05   ` Heiko Stübner
2023-03-31 11:05     ` Heiko Stübner
2023-03-31 11:05     ` Heiko Stübner
2023-03-27 16:49 ` [PATCH -next v17 09/20] riscv: Add task switch support for vector Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-31 11:19   ` Heiko Stübner
2023-03-31 11:19     ` Heiko Stübner
2023-03-31 11:19     ` Heiko Stübner
2023-03-27 16:49 ` [PATCH -next v17 10/20] riscv: Allocate user's vector context in the first-use trap Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-28 17:22   ` Conor Dooley
2023-03-28 17:22     ` Conor Dooley
2023-03-28 17:22     ` Conor Dooley
2023-03-31 14:38     ` Andy Chiu
2023-03-31 14:38       ` Andy Chiu
2023-03-31 14:38       ` Andy Chiu
2023-03-31 13:08   ` Heiko Stübner [this message]
2023-03-31 13:08     ` Heiko Stübner
2023-03-31 13:08     ` Heiko Stübner
2023-03-27 16:49 ` [PATCH -next v17 11/20] riscv: Add ptrace vector support Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-28  5:53   ` Rolf Eike Beer
2023-03-28  5:53     ` Rolf Eike Beer
2023-03-28  5:53     ` Rolf Eike Beer
2023-03-28  6:46     ` Andy Chiu
2023-03-28  6:46       ` Andy Chiu
2023-03-28  6:46       ` Andy Chiu
2023-03-27 16:49 ` [PATCH -next v17 12/20] riscv: signal: check fp-reserved words unconditionally Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-04-01 22:21   ` Heiko Stübner
2023-04-01 22:21     ` Heiko Stübner
2023-04-01 22:21     ` Heiko Stübner
2023-03-27 16:49 ` [PATCH -next v17 13/20] riscv: signal: Add sigcontext save/restore for vector Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-04-01 22:20   ` Heiko Stübner
2023-04-01 22:20     ` Heiko Stübner
2023-04-01 22:20     ` Heiko Stübner
2023-03-27 16:49 ` [PATCH -next v17 14/20] riscv: signal: Report signal frame size to userspace via auxv Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-04-01 22:19   ` Heiko Stübner
2023-04-01 22:19     ` Heiko Stübner
2023-04-01 22:19     ` Heiko Stübner
2023-03-27 16:49 ` [PATCH -next v17 15/20] riscv: signal: validate altstack to reflect Vector Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-31 13:43   ` Heiko Stübner
2023-03-31 13:43     ` Heiko Stübner
2023-03-31 13:43     ` Heiko Stübner
2023-03-27 16:49 ` [PATCH -next v17 16/20] riscv: prevent stack corruption by reserving task_pt_regs(p) early Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-31 13:38   ` Heiko Stübner
2023-03-31 13:38     ` Heiko Stübner
2023-03-31 13:38     ` Heiko Stübner
2023-03-27 16:49 ` [PATCH -next v17 17/20] riscv: kvm: Add V extension to KVM ISA Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-31 13:36   ` Heiko Stübner
2023-03-31 13:36     ` Heiko Stübner
2023-03-31 13:36     ` Heiko Stübner
2023-03-27 16:49 ` [PATCH -next v17 18/20] riscv: KVM: Add vector lazy save/restore support Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-27 17:36   ` Anup Patel
2023-03-27 17:36     ` Anup Patel
2023-03-27 17:36     ` Anup Patel
2023-03-27 16:49 ` [PATCH -next v17 19/20] riscv: detect assembler support for .option arch Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-31 13:33   ` Heiko Stübner
2023-03-31 13:33     ` Heiko Stübner
2023-03-31 13:33     ` Heiko Stübner
2023-03-27 16:49 ` [PATCH -next v17 20/20] riscv: Enable Vector code to be built Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-27 16:49   ` Andy Chiu
2023-03-31 13:32   ` Heiko Stübner
2023-03-31 13:32     ` Heiko Stübner
2023-03-31 13:32     ` Heiko Stübner

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=2409883.jE0xQCEvom@diego \
    --to=heiko@sntech.de \
    --cc=kvm-riscv@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.