All of lore.kernel.org
 help / color / mirror / Atom feed
From: Deepak Gupta <debug@rivosinc.com>
To: zhouquan@iscas.ac.cn
Cc: anup@brainfault.org, ajones@ventanamicro.com,
	atishp@atishpatra.org, paul.walmsley@sifive.com,
	palmer@dabbelt.com, linux-kernel@vger.kernel.org,
	linux-riscv@lists.infradead.org, kvm@vger.kernel.org,
	kvm-riscv@lists.infradead.org
Subject: Re: [PATCH 1/4] RISC-V: KVM: Allow zicfiss/zicfilp exts for Guest/VM
Date: Wed, 3 Dec 2025 09:19:28 -0800	[thread overview]
Message-ID: <aTBxIBZ0Jwn67OcV@debug.ba.rivosinc.com> (raw)
In-Reply-To: <103e156ea1f2201db52034e370a907f46edafb83.1764509485.git.zhouquan@iscas.ac.cn>

On Mon, Dec 01, 2025 at 09:28:25AM +0800, zhouquan@iscas.ac.cn wrote:
>From: Quan Zhou <zhouquan@iscas.ac.cn>
>
>Extend the KVM ISA extension ONE_REG interface to allow KVM user
>space to detect and enable zicfiss/zicfilp exts for Guest/VM,
>the rules defined in the spec [1] are as follows:
>---
>1) Zicfiss extension introduces the SSE field (bit 3) in henvcfg.
>If the SSE field is set to 1, the Zicfiss extension is activated
>in VS-mode. When the SSE field is 0, the Zicfiss extension remains
>inactive in VS-mode.
>
>2) Zicfilp extension introduces the LPE field (bit 2) in henvcfg.
>When the LPE field is set to 1, the Zicfilp extension is enabled
>in VS-mode. When the LPE field is 0, the Zicfilp extension is not
>enabled in VS-mode.
>
>[1] - https://github.com/riscv/riscv-cfi
>
>Signed-off-by: Quan Zhou <zhouquan@iscas.ac.cn>
>---
> arch/riscv/include/uapi/asm/kvm.h | 2 ++
> arch/riscv/kvm/vcpu.c             | 6 ++++++
> arch/riscv/kvm/vcpu_onereg.c      | 2 ++
> 3 files changed, 10 insertions(+)
>
>diff --git a/arch/riscv/include/uapi/asm/kvm.h b/arch/riscv/include/uapi/asm/kvm.h
>index 759a4852c09a..7ca087848a43 100644
>--- a/arch/riscv/include/uapi/asm/kvm.h
>+++ b/arch/riscv/include/uapi/asm/kvm.h
>@@ -190,6 +190,8 @@ enum KVM_RISCV_ISA_EXT_ID {
> 	KVM_RISCV_ISA_EXT_ZFBFMIN,
> 	KVM_RISCV_ISA_EXT_ZVFBFMIN,
> 	KVM_RISCV_ISA_EXT_ZVFBFWMA,
>+	KVM_RISCV_ISA_EXT_ZICFILP,
>+	KVM_RISCV_ISA_EXT_ZICFISS,
> 	KVM_RISCV_ISA_EXT_MAX,
> };
>
>diff --git a/arch/riscv/kvm/vcpu.c b/arch/riscv/kvm/vcpu.c
>index 5ce35aba6069..098d77f9a886 100644
>--- a/arch/riscv/kvm/vcpu.c
>+++ b/arch/riscv/kvm/vcpu.c
>@@ -557,6 +557,12 @@ static void kvm_riscv_vcpu_setup_config(struct kvm_vcpu *vcpu)
> 	if (riscv_isa_extension_available(isa, ZICBOZ))
> 		cfg->henvcfg |= ENVCFG_CBZE;
>
>+	if (riscv_isa_extension_available(isa, ZICFILP))
>+		cfg->henvcfg |= ENVCFG_LPE;

Blindly enabling landing pad enforcement on guest kernel will lead to issues
(a guest kernel might not be ready and compiled with landing pad enforcement).
It must be done via a SSE interface where enable is requested by guest kernel.

>+
>+	if (riscv_isa_extension_available(isa, ZICFISS))
>+		cfg->henvcfg |= ENVCFG_SSE;

Same comment on shadow stack enable. While usually shadow stack usage is optin
where explicityl sspush/sspopchk/ssamoswap has to be part of codegen to use the
extension and not modifying existing instruction behavior (like zicfilp does on
`jalr`)
There is a situaion during early boot of kernel where shadow stack permissions
for init shadow stack might not have been configured (or satp == BARE at that
time), in those cases `sspush/sspopchk` in guest kernel will start faulting.

So enabling shadow stack should also be done via SSE interface.

That's how user cfi patchsets also do.

>+
> 	if (riscv_isa_extension_available(isa, SVADU) &&
> 	    !riscv_isa_extension_available(isa, SVADE))
> 		cfg->henvcfg |= ENVCFG_ADUE;
>diff --git a/arch/riscv/kvm/vcpu_onereg.c b/arch/riscv/kvm/vcpu_onereg.c
>index 865dae903aa0..3d05a4bafd9b 100644
>--- a/arch/riscv/kvm/vcpu_onereg.c
>+++ b/arch/riscv/kvm/vcpu_onereg.c
>@@ -72,6 +72,8 @@ static const unsigned long kvm_isa_ext_arr[] = {
> 	KVM_ISA_EXT_ARR(ZICBOP),
> 	KVM_ISA_EXT_ARR(ZICBOZ),
> 	KVM_ISA_EXT_ARR(ZICCRSE),
>+	KVM_ISA_EXT_ARR(ZICFILP),
>+	KVM_ISA_EXT_ARR(ZICFISS),
> 	KVM_ISA_EXT_ARR(ZICNTR),
> 	KVM_ISA_EXT_ARR(ZICOND),
> 	KVM_ISA_EXT_ARR(ZICSR),
>-- 
>2.34.1
>
>

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

WARNING: multiple messages have this Message-ID (diff)
From: Deepak Gupta <debug@rivosinc.com>
To: zhouquan@iscas.ac.cn
Cc: anup@brainfault.org, ajones@ventanamicro.com,
	atishp@atishpatra.org, paul.walmsley@sifive.com,
	palmer@dabbelt.com, linux-kernel@vger.kernel.org,
	linux-riscv@lists.infradead.org, kvm@vger.kernel.org,
	kvm-riscv@lists.infradead.org
Subject: Re: [PATCH 1/4] RISC-V: KVM: Allow zicfiss/zicfilp exts for Guest/VM
Date: Wed, 3 Dec 2025 09:19:28 -0800	[thread overview]
Message-ID: <aTBxIBZ0Jwn67OcV@debug.ba.rivosinc.com> (raw)
In-Reply-To: <103e156ea1f2201db52034e370a907f46edafb83.1764509485.git.zhouquan@iscas.ac.cn>

On Mon, Dec 01, 2025 at 09:28:25AM +0800, zhouquan@iscas.ac.cn wrote:
>From: Quan Zhou <zhouquan@iscas.ac.cn>
>
>Extend the KVM ISA extension ONE_REG interface to allow KVM user
>space to detect and enable zicfiss/zicfilp exts for Guest/VM,
>the rules defined in the spec [1] are as follows:
>---
>1) Zicfiss extension introduces the SSE field (bit 3) in henvcfg.
>If the SSE field is set to 1, the Zicfiss extension is activated
>in VS-mode. When the SSE field is 0, the Zicfiss extension remains
>inactive in VS-mode.
>
>2) Zicfilp extension introduces the LPE field (bit 2) in henvcfg.
>When the LPE field is set to 1, the Zicfilp extension is enabled
>in VS-mode. When the LPE field is 0, the Zicfilp extension is not
>enabled in VS-mode.
>
>[1] - https://github.com/riscv/riscv-cfi
>
>Signed-off-by: Quan Zhou <zhouquan@iscas.ac.cn>
>---
> arch/riscv/include/uapi/asm/kvm.h | 2 ++
> arch/riscv/kvm/vcpu.c             | 6 ++++++
> arch/riscv/kvm/vcpu_onereg.c      | 2 ++
> 3 files changed, 10 insertions(+)
>
>diff --git a/arch/riscv/include/uapi/asm/kvm.h b/arch/riscv/include/uapi/asm/kvm.h
>index 759a4852c09a..7ca087848a43 100644
>--- a/arch/riscv/include/uapi/asm/kvm.h
>+++ b/arch/riscv/include/uapi/asm/kvm.h
>@@ -190,6 +190,8 @@ enum KVM_RISCV_ISA_EXT_ID {
> 	KVM_RISCV_ISA_EXT_ZFBFMIN,
> 	KVM_RISCV_ISA_EXT_ZVFBFMIN,
> 	KVM_RISCV_ISA_EXT_ZVFBFWMA,
>+	KVM_RISCV_ISA_EXT_ZICFILP,
>+	KVM_RISCV_ISA_EXT_ZICFISS,
> 	KVM_RISCV_ISA_EXT_MAX,
> };
>
>diff --git a/arch/riscv/kvm/vcpu.c b/arch/riscv/kvm/vcpu.c
>index 5ce35aba6069..098d77f9a886 100644
>--- a/arch/riscv/kvm/vcpu.c
>+++ b/arch/riscv/kvm/vcpu.c
>@@ -557,6 +557,12 @@ static void kvm_riscv_vcpu_setup_config(struct kvm_vcpu *vcpu)
> 	if (riscv_isa_extension_available(isa, ZICBOZ))
> 		cfg->henvcfg |= ENVCFG_CBZE;
>
>+	if (riscv_isa_extension_available(isa, ZICFILP))
>+		cfg->henvcfg |= ENVCFG_LPE;

Blindly enabling landing pad enforcement on guest kernel will lead to issues
(a guest kernel might not be ready and compiled with landing pad enforcement).
It must be done via a SSE interface where enable is requested by guest kernel.

>+
>+	if (riscv_isa_extension_available(isa, ZICFISS))
>+		cfg->henvcfg |= ENVCFG_SSE;

Same comment on shadow stack enable. While usually shadow stack usage is optin
where explicityl sspush/sspopchk/ssamoswap has to be part of codegen to use the
extension and not modifying existing instruction behavior (like zicfilp does on
`jalr`)
There is a situaion during early boot of kernel where shadow stack permissions
for init shadow stack might not have been configured (or satp == BARE at that
time), in those cases `sspush/sspopchk` in guest kernel will start faulting.

So enabling shadow stack should also be done via SSE interface.

That's how user cfi patchsets also do.

>+
> 	if (riscv_isa_extension_available(isa, SVADU) &&
> 	    !riscv_isa_extension_available(isa, SVADE))
> 		cfg->henvcfg |= ENVCFG_ADUE;
>diff --git a/arch/riscv/kvm/vcpu_onereg.c b/arch/riscv/kvm/vcpu_onereg.c
>index 865dae903aa0..3d05a4bafd9b 100644
>--- a/arch/riscv/kvm/vcpu_onereg.c
>+++ b/arch/riscv/kvm/vcpu_onereg.c
>@@ -72,6 +72,8 @@ static const unsigned long kvm_isa_ext_arr[] = {
> 	KVM_ISA_EXT_ARR(ZICBOP),
> 	KVM_ISA_EXT_ARR(ZICBOZ),
> 	KVM_ISA_EXT_ARR(ZICCRSE),
>+	KVM_ISA_EXT_ARR(ZICFILP),
>+	KVM_ISA_EXT_ARR(ZICFISS),
> 	KVM_ISA_EXT_ARR(ZICNTR),
> 	KVM_ISA_EXT_ARR(ZICOND),
> 	KVM_ISA_EXT_ARR(ZICSR),
>-- 
>2.34.1
>
>

WARNING: multiple messages have this Message-ID (diff)
From: Deepak Gupta <debug@rivosinc.com>
To: zhouquan@iscas.ac.cn
Cc: anup@brainfault.org, ajones@ventanamicro.com,
	atishp@atishpatra.org, paul.walmsley@sifive.com,
	palmer@dabbelt.com, linux-kernel@vger.kernel.org,
	linux-riscv@lists.infradead.org, kvm@vger.kernel.org,
	kvm-riscv@lists.infradead.org
Subject: Re: [PATCH 1/4] RISC-V: KVM: Allow zicfiss/zicfilp exts for Guest/VM
Date: Wed, 3 Dec 2025 09:19:28 -0800	[thread overview]
Message-ID: <aTBxIBZ0Jwn67OcV@debug.ba.rivosinc.com> (raw)
In-Reply-To: <103e156ea1f2201db52034e370a907f46edafb83.1764509485.git.zhouquan@iscas.ac.cn>

On Mon, Dec 01, 2025 at 09:28:25AM +0800, zhouquan@iscas.ac.cn wrote:
>From: Quan Zhou <zhouquan@iscas.ac.cn>
>
>Extend the KVM ISA extension ONE_REG interface to allow KVM user
>space to detect and enable zicfiss/zicfilp exts for Guest/VM,
>the rules defined in the spec [1] are as follows:
>---
>1) Zicfiss extension introduces the SSE field (bit 3) in henvcfg.
>If the SSE field is set to 1, the Zicfiss extension is activated
>in VS-mode. When the SSE field is 0, the Zicfiss extension remains
>inactive in VS-mode.
>
>2) Zicfilp extension introduces the LPE field (bit 2) in henvcfg.
>When the LPE field is set to 1, the Zicfilp extension is enabled
>in VS-mode. When the LPE field is 0, the Zicfilp extension is not
>enabled in VS-mode.
>
>[1] - https://github.com/riscv/riscv-cfi
>
>Signed-off-by: Quan Zhou <zhouquan@iscas.ac.cn>
>---
> arch/riscv/include/uapi/asm/kvm.h | 2 ++
> arch/riscv/kvm/vcpu.c             | 6 ++++++
> arch/riscv/kvm/vcpu_onereg.c      | 2 ++
> 3 files changed, 10 insertions(+)
>
>diff --git a/arch/riscv/include/uapi/asm/kvm.h b/arch/riscv/include/uapi/asm/kvm.h
>index 759a4852c09a..7ca087848a43 100644
>--- a/arch/riscv/include/uapi/asm/kvm.h
>+++ b/arch/riscv/include/uapi/asm/kvm.h
>@@ -190,6 +190,8 @@ enum KVM_RISCV_ISA_EXT_ID {
> 	KVM_RISCV_ISA_EXT_ZFBFMIN,
> 	KVM_RISCV_ISA_EXT_ZVFBFMIN,
> 	KVM_RISCV_ISA_EXT_ZVFBFWMA,
>+	KVM_RISCV_ISA_EXT_ZICFILP,
>+	KVM_RISCV_ISA_EXT_ZICFISS,
> 	KVM_RISCV_ISA_EXT_MAX,
> };
>
>diff --git a/arch/riscv/kvm/vcpu.c b/arch/riscv/kvm/vcpu.c
>index 5ce35aba6069..098d77f9a886 100644
>--- a/arch/riscv/kvm/vcpu.c
>+++ b/arch/riscv/kvm/vcpu.c
>@@ -557,6 +557,12 @@ static void kvm_riscv_vcpu_setup_config(struct kvm_vcpu *vcpu)
> 	if (riscv_isa_extension_available(isa, ZICBOZ))
> 		cfg->henvcfg |= ENVCFG_CBZE;
>
>+	if (riscv_isa_extension_available(isa, ZICFILP))
>+		cfg->henvcfg |= ENVCFG_LPE;

Blindly enabling landing pad enforcement on guest kernel will lead to issues
(a guest kernel might not be ready and compiled with landing pad enforcement).
It must be done via a SSE interface where enable is requested by guest kernel.

>+
>+	if (riscv_isa_extension_available(isa, ZICFISS))
>+		cfg->henvcfg |= ENVCFG_SSE;

Same comment on shadow stack enable. While usually shadow stack usage is optin
where explicityl sspush/sspopchk/ssamoswap has to be part of codegen to use the
extension and not modifying existing instruction behavior (like zicfilp does on
`jalr`)
There is a situaion during early boot of kernel where shadow stack permissions
for init shadow stack might not have been configured (or satp == BARE at that
time), in those cases `sspush/sspopchk` in guest kernel will start faulting.

So enabling shadow stack should also be done via SSE interface.

That's how user cfi patchsets also do.

>+
> 	if (riscv_isa_extension_available(isa, SVADU) &&
> 	    !riscv_isa_extension_available(isa, SVADE))
> 		cfg->henvcfg |= ENVCFG_ADUE;
>diff --git a/arch/riscv/kvm/vcpu_onereg.c b/arch/riscv/kvm/vcpu_onereg.c
>index 865dae903aa0..3d05a4bafd9b 100644
>--- a/arch/riscv/kvm/vcpu_onereg.c
>+++ b/arch/riscv/kvm/vcpu_onereg.c
>@@ -72,6 +72,8 @@ static const unsigned long kvm_isa_ext_arr[] = {
> 	KVM_ISA_EXT_ARR(ZICBOP),
> 	KVM_ISA_EXT_ARR(ZICBOZ),
> 	KVM_ISA_EXT_ARR(ZICCRSE),
>+	KVM_ISA_EXT_ARR(ZICFILP),
>+	KVM_ISA_EXT_ARR(ZICFISS),
> 	KVM_ISA_EXT_ARR(ZICNTR),
> 	KVM_ISA_EXT_ARR(ZICOND),
> 	KVM_ISA_EXT_ARR(ZICSR),
>-- 
>2.34.1
>
>

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

  reply	other threads:[~2025-12-03 17:19 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-01  1:28 [PATCH 0/4] RISC-V: KVM: Add Zicfiss/Zicfilp support zhouquan
2025-12-01  1:28 ` zhouquan
2025-12-01  1:28 ` zhouquan
2025-12-01  1:28 ` [PATCH 1/4] RISC-V: KVM: Allow zicfiss/zicfilp exts for Guest/VM zhouquan
2025-12-01  1:28   ` zhouquan
2025-12-01  1:28   ` zhouquan
2025-12-03 17:19   ` Deepak Gupta [this message]
2025-12-03 17:19     ` Deepak Gupta
2025-12-03 17:19     ` Deepak Gupta
2025-12-03 17:25     ` Deepak Gupta
2025-12-03 17:25       ` Deepak Gupta
2025-12-03 17:25       ` Deepak Gupta
2025-12-08  9:53     ` Quan Zhou
2025-12-08  9:53       ` Quan Zhou
2025-12-08  9:53       ` Quan Zhou
2025-12-01  1:28 ` [PATCH 2/4] RISC-V: KVM: Add support for software check exception zhouquan
2025-12-01  1:28   ` zhouquan
2025-12-01  1:28   ` zhouquan
2025-12-01  1:28 ` [PATCH 3/4] RISC-V: KVM: Add suuport for zicfiss/zicfilp/svadu FWFT features zhouquan
2025-12-01  1:28   ` zhouquan
2025-12-01  1:28   ` zhouquan
2025-12-03 10:52   ` kernel test robot
2025-12-03 10:52     ` kernel test robot
2025-12-03 10:52     ` kernel test robot
2025-12-01  1:29 ` [PATCH 4/4] KVM: riscv: selftests: Add zicfiss/zicfilp/svadu and SBI FWFT to get-reg-list test zhouquan
2025-12-01  1:29   ` zhouquan
2025-12-01  1:29   ` zhouquan

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=aTBxIBZ0Jwn67OcV@debug.ba.rivosinc.com \
    --to=debug@rivosinc.com \
    --cc=ajones@ventanamicro.com \
    --cc=anup@brainfault.org \
    --cc=atishp@atishpatra.org \
    --cc=kvm-riscv@lists.infradead.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=zhouquan@iscas.ac.cn \
    /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.