[PATCH v2 0/7] RISC-V: KVM: Add Svadu/Zicfiss/Zicfilp FWFT support

[PATCH v2 0/7] RISC-V: KVM: Add Svadu/Zicfiss/Zicfilp FWFT support

[Inochi Amaoto]

This patchset based on the patchset "RISC-V: KVM: Add Zicfiss/Zicfilp
support".

The patch includes all the function of original patchset from Quan:
adding the Svadu/Zicfiss/Zicfilp FWFT for the RISC-V KVM. And this
patchset already passes the KVM unit test.

Changed from Quan's v1:
- https://lore.kernel.org/kvm/cover.1764509485.git.zhouquan@iscas.ac.cn/
1. rebase to the latest master.
2. Split Svadu change as separate patch
3. Fix all build error from the original series
4. Remove the Svadu check in kvm_riscv_vcpu_config_ran_once() and in
   favor of the FWFT.
5. Remove the LPE/SSE setting bit in kvm_riscv_vcpu_config_ran_once()
   (kvm_riscv_vcpu_setup_config() in original patchset)

Inochi Amaoto (7):
  RISC-V: KVM: Add support for Svadu FWFT features
  KVM: riscv: selftests: add Svadu FWFT extension to get-reg-list test
  RISC-V: KVM: Only enable Svadu extension when Guest/VM requests
  RISC-V: KVM: Allow Zicfiss/Zicfilp extensions for Guest/VM
  RISC-V: KVM: Handle software-check exits for VCPU
  RISC-V: KVM: Add support for control-flow integrity FWFT features
  KVM: riscv: selftests: add Zicfiss/Zicfilp extension to get-reg-list
    test

 arch/riscv/include/asm/csr.h                  |   1 +
 arch/riscv/include/uapi/asm/kvm.h             |   5 +
 arch/riscv/kvm/isa.c                          |   2 +
 arch/riscv/kvm/vcpu_config.c                  |   8 +-
 arch/riscv/kvm/vcpu_exit.c                    |   3 +
 arch/riscv/kvm/vcpu_sbi_fwft.c                | 142 ++++++++++++++++++
 .../selftests/kvm/riscv/get-reg-list.c        |  22 +++
 7 files changed, 179 insertions(+), 4 deletions(-)

--
2.54.0

[PATCH v2 1/7] RISC-V: KVM: Add support for Svadu FWFT features

[Inochi Amaoto]

Hardware updating of PTE A/D bits is controlled through ADUE bit in
henvcfg Expose the feature only if the Svadu is supported for VS-mode.
Allow the VMM to block access to the feature by disabling the ISA
extension in the guest.

Assisted-by: YuanSheng:claude-4.7-opus
Co-developed-by: Quan Zhou <zhouquan@iscas.ac.cn>
Signed-off-by: Quan Zhou <zhouquan@iscas.ac.cn>
Signed-off-by: Inochi Amaoto <inochiama@gmail.com>
---
 arch/riscv/include/uapi/asm/kvm.h |  3 ++
 arch/riscv/kvm/vcpu_sbi_fwft.c    | 72 +++++++++++++++++++++++++++++++
 2 files changed, 75 insertions(+)

diff --git a/arch/riscv/include/uapi/asm/kvm.h b/arch/riscv/include/uapi/asm/kvm.h
index 504e73305343..501e4fc60dd2 100644
--- a/arch/riscv/include/uapi/asm/kvm.h
+++ b/arch/riscv/include/uapi/asm/kvm.h
@@ -240,6 +240,9 @@ struct kvm_riscv_sbi_fwft_feature {
 struct kvm_riscv_sbi_fwft {
 	struct kvm_riscv_sbi_fwft_feature misaligned_deleg;
 	struct kvm_riscv_sbi_fwft_feature pointer_masking;
+	struct kvm_riscv_sbi_fwft_feature pte_ad_hw_updating;
+	struct kvm_riscv_sbi_fwft_feature landing_pad;
+	struct kvm_riscv_sbi_fwft_feature shadow_stack;
 };
 
 /* If you need to interpret the index values, here is the key: */
diff --git a/arch/riscv/kvm/vcpu_sbi_fwft.c b/arch/riscv/kvm/vcpu_sbi_fwft.c
index 2eab15339694..375269e43c13 100644
--- a/arch/riscv/kvm/vcpu_sbi_fwft.c
+++ b/arch/riscv/kvm/vcpu_sbi_fwft.c
@@ -84,6 +84,42 @@ static bool kvm_fwft_is_defined_feature(enum sbi_fwft_feature_t feature)
 	return false;
 }
 
+static void kvm_sbi_fwft_env_flag_reset_helper(struct kvm_vcpu *vcpu,
+					       unsigned long flag)
+{
+	vcpu->arch.cfg.henvcfg &= ~flag;
+}
+
+static long kvm_sbi_fwft_env_flag_set_helper(struct kvm_vcpu *vcpu,
+					     struct kvm_sbi_fwft_config *conf,
+					     bool one_reg_access,
+					     unsigned long value, unsigned long flag)
+{
+	struct kvm_vcpu_config *cfg = &vcpu->arch.cfg;
+
+	if (value == 0)
+		cfg->henvcfg &= ~flag;
+	else if (value == 1)
+		cfg->henvcfg |= flag;
+	else
+		return SBI_ERR_INVALID_PARAM;
+
+	if (!one_reg_access)
+		csr_write(CSR_HENVCFG, vcpu->arch.cfg.henvcfg);
+
+	return SBI_SUCCESS;
+}
+
+static long kvm_sbi_fwft_env_flag_get_helper(struct kvm_vcpu *vcpu,
+					     struct kvm_sbi_fwft_config *conf,
+					     bool one_reg_access,
+					     unsigned long *value, unsigned long flag)
+{
+	*value = (vcpu->arch.cfg.henvcfg & flag) == flag;
+
+	return SBI_SUCCESS;
+}
+
 static bool kvm_sbi_fwft_misaligned_delegation_supported(struct kvm_vcpu *vcpu)
 {
 	return misaligned_traps_can_delegate();
@@ -127,6 +163,33 @@ static long kvm_sbi_fwft_get_misaligned_delegation(struct kvm_vcpu *vcpu,
 	return SBI_SUCCESS;
 }
 
+static bool kvm_sbi_fwft_pte_ad_hw_updating_supported(struct kvm_vcpu *vcpu)
+{
+	return riscv_isa_extension_available(vcpu->arch.isa, SVADU) &&
+		!riscv_isa_extension_available(vcpu->arch.isa, SVADE);
+}
+
+static void kvm_sbi_fwft_reset_pte_ad_hw_updating(struct kvm_vcpu *vcpu)
+{
+	kvm_sbi_fwft_env_flag_reset_helper(vcpu, ENVCFG_ADUE);
+}
+
+static long kvm_sbi_fwft_set_pte_ad_hw_updating(struct kvm_vcpu *vcpu,
+						struct kvm_sbi_fwft_config *conf,
+						bool one_reg_access, unsigned long value)
+{
+	return kvm_sbi_fwft_env_flag_set_helper(vcpu, conf, one_reg_access,
+						value, ENVCFG_ADUE);
+}
+
+static long kvm_sbi_fwft_get_pte_ad_hw_updating(struct kvm_vcpu *vcpu,
+						struct kvm_sbi_fwft_config *conf,
+						bool one_reg_access, unsigned long *value)
+{
+	return kvm_sbi_fwft_env_flag_get_helper(vcpu, conf, one_reg_access,
+						value, ENVCFG_ADUE);
+}
+
 #ifndef CONFIG_32BIT
 
 static bool try_to_set_pmm(unsigned long value)
@@ -225,6 +288,15 @@ static const struct kvm_sbi_fwft_feature features[] = {
 		.set = kvm_sbi_fwft_set_misaligned_delegation,
 		.get = kvm_sbi_fwft_get_misaligned_delegation,
 	},
+	{
+		.id = SBI_FWFT_PTE_AD_HW_UPDATING,
+		.first_reg_num = offsetof(struct kvm_riscv_sbi_fwft, pte_ad_hw_updating.enable) /
+				 sizeof(unsigned long),
+		.supported = kvm_sbi_fwft_pte_ad_hw_updating_supported,
+		.reset = kvm_sbi_fwft_reset_pte_ad_hw_updating,
+		.set = kvm_sbi_fwft_set_pte_ad_hw_updating,
+		.get = kvm_sbi_fwft_get_pte_ad_hw_updating,
+	},
 #ifndef CONFIG_32BIT
 	{
 		.id = SBI_FWFT_POINTER_MASKING_PMLEN,
-- 
2.54.0

Re: [PATCH v2 1/7] RISC-V: KVM: Add support for Svadu FWFT features

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [High] KVM_SET_ONE_REG for FWFT state registers modifies VCPU configuration in memory but fails to set `vcpu->arch.csr_dirty = true`, leading to stale hardware CSRs.
- [High] The FWFT support check `kvm_sbi_fwft_pte_ad_hw_updating_supported()` incorrectly disables the toggle when both SVADU and SVADE are present, and dangerously enables it when only SVADU is present.
- [High] The 'flag' parameter in henvcfg helper functions is 'unsigned long', causing truncation of 64-bit flags like ENVCFG_ADUE on 32-bit systems and permanently corrupting guest `henvcfg` state during vCPU reset.
- [High] Dynamically setting the Svadu FWFT feature on RV32 fails to update the physical CPU's `CSR_HENVCFGH` register, leaving the hardware state stale.
- [High] Direct modification of `CSR_HENVCFG` bypasses Nested Acceleration (NACL) shared memory, leading to state desynchronization in nested virtualization.
--

commit df2a6571e0257cf7e8c4ca0758aefd4d6f6c3a32
Author: Inochi Amaoto <inochiama@gmail.com>

RISC-V: KVM: Add support for Svadu FWFT features

This patch adds support for exposing the Svadu extension to guests via the
SBI FWFT interface. It introduces helpers to get, set, and reset henvcfg
flags, specifically for the ADUE bit which controls hardware updating of
PTE A/D bits.

> diff --git a/arch/riscv/kvm/vcpu_sbi_fwft.c b/arch/riscv/kvm/vcpu_sbi_fwft.c
> index 2eab15339694f..375269e43c13b 100644
> --- a/arch/riscv/kvm/vcpu_sbi_fwft.c
> +++ b/arch/riscv/kvm/vcpu_sbi_fwft.c

[ ... ]

> @@ -84,6 +84,42 @@ static bool kvm_fwft_is_defined_feature(enum sbi_fwft_feature_t feature)
>  	return false;
>  }
>  
> +static void kvm_sbi_fwft_env_flag_reset_helper(struct kvm_vcpu *vcpu,
> +					       unsigned long flag)
> +{
> +	vcpu->arch.cfg.henvcfg &= ~flag;
> +}

[Severity: High]
Does using unsigned long for the flag parameter truncate 64-bit flags
like ENVCFG_ADUE on 32-bit systems?

Since ENVCFG_ADUE is in the upper 32 bits, passing it as unsigned long on
CONFIG_32BIT systems would silently truncate it to 0. 

When vcpu->arch.cfg.henvcfg &= ~flag evaluates with flag as 0, it results
in henvcfg &= ~0UL. Because ~0UL is 0xFFFFFFFF, it zero-extends to u64,
resulting in henvcfg &= 0x00000000FFFFFFFFULL.

Will this unconditionally wipe out all upper 32-bit extensions like
ENVCFG_STCE and ENVCFG_PBMTE for the guest during vCPU reset?

> +
> +static long kvm_sbi_fwft_env_flag_set_helper(struct kvm_vcpu *vcpu,
> +					     struct kvm_sbi_fwft_config *conf,
> +					     bool one_reg_access,
> +					     unsigned long value, unsigned long flag)
> +{

[Severity: High]
Is this helper also affected by the same unsigned long truncation issue
for the flag parameter?

> +	struct kvm_vcpu_config *cfg = &vcpu->arch.cfg;
> +
> +	if (value == 0)
> +		cfg->henvcfg &= ~flag;
> +	else if (value == 1)
> +		cfg->henvcfg |= flag;
> +	else
> +		return SBI_ERR_INVALID_PARAM;
> +

[Severity: High]
When one_reg_access is true, does this omit setting vcpu->arch.csr_dirty
to true?

If the VCPU is later scheduled on the same physical CPU, vcpu_load() might
skip calling kvm_riscv_vcpu_config_load() due to the fast-path condition
checking the csr_dirty flag.

Could this cause the guest to run with a stale hardware configuration since
the updated henvcfg is never flushed to the hardware CSR_HENVCFG?

> +	if (!one_reg_access)
> +		csr_write(CSR_HENVCFG, vcpu->arch.cfg.henvcfg);

[Severity: High]
On 32-bit RISC-V systems, does csr_write(CSR_HENVCFG, ...) only write the
lower 32 bits?

Since ENVCFG_ADUE resides in the upper 32 bits, shouldn't there be an
explicit write to CSR_HENVCFGH as well? Without it, the physical CPU's
configuration might not be properly synchronized for upper 32-bit flags.

[Severity: High]
Does directly modifying CSR_HENVCFG bypass Nested Acceleration (NACL)?

When KVM runs as an L1 hypervisor with NACL enabled, it must synchronize
hypervisor CSRs via the shared memory region (nsh) rather than directly
writing to the physical CSRs.

If ncsr_write() is not used here, could the L0 hypervisor miss the update
and overwrite the CSR with a stale value from nsh on subsequent VM entries?

> +
> +	return SBI_SUCCESS;
> +}

[ ... ]

> +static bool kvm_sbi_fwft_pte_ad_hw_updating_supported(struct kvm_vcpu *vcpu)
> +{
> +	return riscv_isa_extension_available(vcpu->arch.isa, SVADU) &&
> +		!riscv_isa_extension_available(vcpu->arch.isa, SVADE);
> +}

[Severity: High]
Does this condition behave backward with respect to the SBI FWFT specification?

The specification requires that if a VM supports only Svadu, ADUE must be
hardwired to 1. If it supports both Svadu and Svade, the guest can toggle
the feature.

By returning true only when Svadu is present and Svade is absent, does this
disable the toggle for fully capable VMs, and incorrectly allow Svadu-only VMs
to set ADUE=0? 

If a Svadu-only VM sets ADUE=0, could it silently corrupt its memory since the
Svade software fallback is unavailable?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260601084336.2601675-1-inochiama@gmail.com?part=1

[PATCH v2 2/7] KVM: riscv: selftests: add Svadu FWFT extension to get-reg-list test

[Inochi Amaoto]

The KVM RISC-V allows Svadu FWFT for Guest/VM so add this extension
to get-reg-list test.

Assisted-by: YuanSheng:claude-4.7-opus
Co-developed-by: Quan Zhou <zhouquan@iscas.ac.cn>
Signed-off-by: Quan Zhou <zhouquan@iscas.ac.cn>
Signed-off-by: Inochi Amaoto <inochiama@gmail.com>
---
 tools/testing/selftests/kvm/riscv/get-reg-list.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/tools/testing/selftests/kvm/riscv/get-reg-list.c b/tools/testing/selftests/kvm/riscv/get-reg-list.c
index 8d6fdb5d38b8..d88edef77ccf 100644
--- a/tools/testing/selftests/kvm/riscv/get-reg-list.c
+++ b/tools/testing/selftests/kvm/riscv/get-reg-list.c
@@ -712,6 +712,9 @@ static const char *sbi_fwft_id_to_str(__u64 reg_off)
 	case 3: return "KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(pointer_masking.enable)";
 	case 4: return "KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(pointer_masking.flags)";
 	case 5: return "KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(pointer_masking.value)";
+	case 6: return "KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(pte_ad_hw_updating.enable)";
+	case 7: return "KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(pte_ad_hw_updating.flags)";
+	case 8: return "KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(pte_ad_hw_updating.value)";
 	}
 	return strdup_printf("KVM_REG_RISCV_SBI_FWFT | %lld /* UNKNOWN */", reg_off);
 }
@@ -905,6 +908,9 @@ static __u64 sbi_fwft_regs[] = {
 	KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_SBI_STATE | KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(pointer_masking.enable),
 	KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_SBI_STATE | KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(pointer_masking.flags),
 	KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_SBI_STATE | KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(pointer_masking.value),
+	KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_SBI_STATE | KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(pte_ad_hw_updating.enable),
+	KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_SBI_STATE | KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(pte_ad_hw_updating.flags),
+	KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_SBI_STATE | KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(pte_ad_hw_updating.value),
 };
 
 static __u64 zicbom_regs[] = {
-- 
2.54.0

Re: [PATCH v2 2/7] KVM: riscv: selftests: add Svadu FWFT extension to get-reg-list test

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Unconditional selftest failure in get-reg-list due to dynamically-omitted registers in the blessed list.
--

commit 6df4c1234104e4c676015802e2b610d953076f46
Author: Inochi Amaoto <inochiama@gmail.com>

KVM: riscv: selftests: add Svadu FWFT extension to get-reg-list test
    
This commit adds the Svadu FWFT extension registers to the get-reg-list
selftest's expected register list.

> diff --git a/tools/testing/selftests/kvm/riscv/get-reg-list.c b/tools/testing/selftests/kvm/riscv/get-reg-list.c
> index 8d6fdb5d38b89..d88edef77ccfd 100644
> --- a/tools/testing/selftests/kvm/riscv/get-reg-list.c
> +++ b/tools/testing/selftests/kvm/riscv/get-reg-list.c
[ ... ]
> @@ -905,6 +908,9 @@ static __u64 sbi_fwft_regs[] = {
>  	KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_SBI_STATE | KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(pointer_masking.enable),
>  	KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_SBI_STATE | KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(pointer_masking.flags),
>  	KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_SBI_STATE | KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(pointer_masking.value),
> +	KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_SBI_STATE | KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(pte_ad_hw_updating.enable),
> +	KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_SBI_STATE | KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(pte_ad_hw_updating.flags),
> +	KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_SBI_STATE | KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(pte_ad_hw_updating.value),
>  };

[Severity: Medium]
Will this cause an unconditional selftest failure when the SVADU extension
is disabled?

The RISC-V get-reg-list selftest disables all ISA extensions (including SVADU)
by default to ensure a clean baseline. The KVM implementation conditionally
exposes these pte_ad_hw_updating registers only if the SVADU ISA extension is
enabled on the vCPU.

Because the registers are added unconditionally to the expected list here,
and RISC-V does not override check_supported_reg() to conditionally filter
them out, KVM omitting these registers from KVM_GET_REG_LIST will cause the
test framework to fail with a missing registers assertion.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260601084336.2601675-1-inochiama@gmail.com?part=2

[PATCH v2 3/7] RISC-V: KVM: Only enable Svadu extension when Guest/VM requests

[Inochi Amaoto]

Since the Svadu extension can be controlled by the FWFT, there is
no need to enable Svadu at startup. Only enable it when it is
requested.

Signed-off-by: Inochi Amaoto <inochiama@gmail.com>
---
 arch/riscv/kvm/vcpu_config.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/arch/riscv/kvm/vcpu_config.c b/arch/riscv/kvm/vcpu_config.c
index 238418fed2b9..b2a1028106d5 100644
--- a/arch/riscv/kvm/vcpu_config.c
+++ b/arch/riscv/kvm/vcpu_config.c
@@ -53,10 +53,6 @@ void kvm_riscv_vcpu_config_ran_once(struct kvm_vcpu *vcpu)
 	if (riscv_isa_extension_available(isa, ZICBOZ))
 		cfg->henvcfg |= ENVCFG_CBZE;
 
-	if (riscv_isa_extension_available(isa, SVADU) &&
-	    !riscv_isa_extension_available(isa, SVADE))
-		cfg->henvcfg |= ENVCFG_ADUE;
-
 	if (riscv_has_extension_unlikely(RISCV_ISA_EXT_SMSTATEEN)) {
 		cfg->hstateen0 |= SMSTATEEN0_HSENVCFG;
 		if (riscv_isa_extension_available(isa, SSAIA))
-- 
2.54.0

Re: [PATCH v2 3/7] RISC-V: KVM: Only enable Svadu extension when Guest/VM requests

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:

Pre-existing issues:
- [Critical] The FWFT reset callback unconditionally clears ENVCFG_ADUE, breaking the required default state.
- [High] The FWFT supported callback for PTE_AD_HW_UPDATING uses inverted logic, disabling the feature when both extensions are present.
- [High] Modifying FWFT features via KVM_SET_ONE_REG updates vCPU software config but fails to set `vcpu->arch.csr_dirty = true`, leading to stale hardware CSR state.
- [High] Probing host hardware support for pointer masking modifies a physical host CSR (CSR_HENVCFG) with preemption enabled, risking hardware state corruption.
- [High] kvm_sbi_fwft_env_flag_set_helper fails to update the upper 32 bits of HENVCFG on 32-bit systems when handling SBI_EXT_FWFT_SET.
- [High] Direct CSR writes in FWFT handlers bypass Nested Architecture for Confidential Linux (NaCl) shared memory synchronization.
--

commit 9785e1b9e42d11cc65b0f2a69b673df176c4c687
Author: Inochi Amaoto <inochiama@gmail.com>

RISC-V: KVM: Only enable Svadu extension when Guest/VM requests

This commit removes the default startup initialization of the Svadu
extension in KVM, relying instead on the guest or VM requesting it
through the FWFT interface.

> diff --git a/arch/riscv/kvm/vcpu_config.c b/arch/riscv/kvm/vcpu_config.c
> index 238418fed2b9a..b2a1028106d5d 100644
> --- a/arch/riscv/kvm/vcpu_config.c
> +++ b/arch/riscv/kvm/vcpu_config.c

[ ... ]

> @@ -53,10 +53,6 @@ void kvm_riscv_vcpu_config_ran_once(struct kvm_vcpu *vcpu)
>  	if (riscv_isa_extension_available(isa, ZICBOZ))
>  		cfg->henvcfg |= ENVCFG_CBZE;
>  
> -	if (riscv_isa_extension_available(isa, SVADU) &&
> -	    !riscv_isa_extension_available(isa, SVADE))
> -		cfg->henvcfg |= ENVCFG_ADUE;
> -

[Severity: High]
This isn't a bug introduced by this patch, but by removing this default
initialization, does this leave guests without an A/D updating mechanism
at boot?

If a platform has SVADU but no SVADE, hardware A/D updating is the only
mechanism available. The FWFT reset handler unconditionally clears ENVCFG_ADUE:

arch/riscv/kvm/vcpu_sbi_fwft.c:kvm_sbi_fwft_reset_pte_ad_hw_updating() {
...
	kvm_sbi_fwft_env_flag_reset_helper(vcpu, ENVCFG_ADUE);
...
}

[Severity: High]
This is a pre-existing issue, but does the FWFT supported callback use
inverted logic?

arch/riscv/kvm/vcpu_sbi_fwft.c:kvm_sbi_fwft_pte_ad_hw_updating_supported() {
...
	return riscv_isa_extension_available(vcpu->arch.isa, SVADU) &&
		!riscv_isa_extension_available(vcpu->arch.isa, SVADE);
...
}

If a platform supports both SVADU and SVADE, it can safely toggle between
hardware updating and page faults. 

However, this logic returns true only when SVADU is present and SVADE is absent.
Since this patch relies on FWFT as the sole way to enable SVADU, does this
logic prevent it from working on platforms that can actually toggle it?

[Severity: High]
This is a pre-existing issue, but how does the code interact with the FWFT
handlers updating the vCPU software config without setting the dirty flag?

When KVM_SET_ONE_REG modifies an FWFT feature:

arch/riscv/kvm/vcpu_sbi_fwft.c:kvm_sbi_fwft_env_flag_set_helper() {
...
	else if (value == 1)
		cfg->henvcfg |= flag;
...
	if (!one_reg_access)
		csr_write(CSR_HENVCFG, vcpu->arch.cfg.henvcfg);
...
}

It updates cfg->henvcfg but doesn't set vcpu->arch.csr_dirty = true.
If the vCPU is scheduled on the same physical CPU, the load fast-path skips
hardware state restoration:

arch/riscv/kvm/vcpu.c:kvm_arch_vcpu_load() {
...
	else if (vcpu->arch.last_exit_cpu == cpu && !vcpu->arch.csr_dirty)
		goto csr_restore_done;
...
}

Does this result in the hardware running with a stale CSR_HENVCFG value until
the vCPU migrates?

[Severity: High]
This is a pre-existing issue, but looking at the FWFT initialization, does
testing host pointer masking support risk hardware state corruption?

arch/riscv/kvm/vcpu_sbi_fwft.c:try_to_set_pmm() {
...
	csr_set(CSR_HENVCFG, value);
	return (csr_read_clear(CSR_HENVCFG, ENVCFG_PMM) & ENVCFG_PMM) == value;
...
}

If the thread is preempted and migrated to a different physical CPU between
csr_set and csr_read_clear, is the first CPU permanently left with the test
bits set in its physical CSR_HENVCFG?

[Severity: High]
This isn't a bug introduced by this patch, but does the FWFT set helper fail
to update the upper 32 bits of HENVCFG on 32-bit systems?

arch/riscv/kvm/vcpu_sbi_fwft.c:kvm_sbi_fwft_env_flag_set_helper() {
...
	if (!one_reg_access)
		csr_write(CSR_HENVCFG, vcpu->arch.cfg.henvcfg);
...
}

Since ENVCFG_ADUE is located at bit 61, wouldn't the hardware state remain
out-of-sync with vcpu->arch.cfg.henvcfg when a 32-bit guest executes an
SBI FWFT SET call?

[Severity: High]
This is a pre-existing issue, but do direct CSR writes in the FWFT handlers
bypass Nested Architecture for Confidential Linux (NaCl) shared memory?

arch/riscv/kvm/vcpu_sbi_fwft.c:kvm_sbi_fwft_env_flag_set_helper() {
...
		csr_write(CSR_HENVCFG, vcpu->arch.cfg.henvcfg);
...
}

and in kvm_sbi_fwft_set_misaligned_delegation():

arch/riscv/kvm/vcpu_sbi_fwft.c:kvm_sbi_fwft_set_misaligned_delegation() {
...
			csr_set(CSR_HEDELEG, MIS_DELEG);
...
}

Should these be using the ncsr_write() wrapper or nacl_csr_write() to ensure
the nested hypervisor's view remains synchronized?

>  	if (riscv_has_extension_unlikely(RISCV_ISA_EXT_SMSTATEEN)) {
>  		cfg->hstateen0 |= SMSTATEEN0_HSENVCFG;
>  		if (riscv_isa_extension_available(isa, SSAIA))

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260601084336.2601675-1-inochiama@gmail.com?part=3

[PATCH v2 4/7] RISC-V: KVM: Allow Zicfiss/Zicfilp extensions for Guest/VM

[Inochi Amaoto]

Extend the KVM ISA extension array to allow KVM userspace to
detect and enable Zicfiss/Zicfilp extensions for Guest/VM.

Assisted-by: YuanSheng:claude-4.7-opus
Co-developed-by: Quan Zhou <zhouquan@iscas.ac.cn>
Signed-off-by: Quan Zhou <zhouquan@iscas.ac.cn>
Signed-off-by: Inochi Amaoto <inochiama@gmail.com>
---
 arch/riscv/include/uapi/asm/kvm.h | 2 ++
 arch/riscv/kvm/isa.c              | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/arch/riscv/include/uapi/asm/kvm.h b/arch/riscv/include/uapi/asm/kvm.h
index 501e4fc60dd2..9f9c5ababd1e 100644
--- a/arch/riscv/include/uapi/asm/kvm.h
+++ b/arch/riscv/include/uapi/asm/kvm.h
@@ -199,6 +199,8 @@ enum KVM_RISCV_ISA_EXT_ID {
 	KVM_RISCV_ISA_EXT_ZCLSD,
 	KVM_RISCV_ISA_EXT_ZILSD,
 	KVM_RISCV_ISA_EXT_ZALASR,
+	KVM_RISCV_ISA_EXT_ZICFILP,
+	KVM_RISCV_ISA_EXT_ZICFISS,
 	KVM_RISCV_ISA_EXT_MAX,
 };
 
diff --git a/arch/riscv/kvm/isa.c b/arch/riscv/kvm/isa.c
index 1132d909cc25..9852a91fdecc 100644
--- a/arch/riscv/kvm/isa.c
+++ b/arch/riscv/kvm/isa.c
@@ -65,6 +65,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.54.0

Re: [PATCH v2 4/7] RISC-V: KVM: Allow Zicfiss/Zicfilp extensions for Guest/VM

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] Missing context switch and API support for the Zicfiss shadow stack pointer (`CSR_SSP`).
- [High] Zicfilp and Zicfiss extensions are enabled by default, violating KVM subsystem guidelines.
--

commit a0c518ab3b8be233eb4530a1f65b1f7970a43692
Author: Inochi Amaoto <inochiama@gmail.com>

RISC-V: KVM: Allow Zicfiss/Zicfilp extensions for Guest/VM

Extend the KVM ISA extension array to allow KVM userspace to
detect and enable Zicfiss/Zicfilp extensions for Guest/VM.

> diff --git a/arch/riscv/include/uapi/asm/kvm.h b/arch/riscv/include/uapi/asm/kvm.h
> index 501e4fc60dd24..9f9c5ababd1e3 100644
> --- a/arch/riscv/include/uapi/asm/kvm.h
> +++ b/arch/riscv/include/uapi/asm/kvm.h
> @@ -199,6 +199,8 @@ enum KVM_RISCV_ISA_EXT_ID {
>  	KVM_RISCV_ISA_EXT_ZCLSD,
>  	KVM_RISCV_ISA_EXT_ZILSD,
>  	KVM_RISCV_ISA_EXT_ZALASR,
> +	KVM_RISCV_ISA_EXT_ZICFILP,
> +	KVM_RISCV_ISA_EXT_ZICFISS,

[Severity: Critical]
Does this patch miss the context switch and API support for the Zicfiss
shadow stack pointer (CSR_SSP)?

Since the Zicfiss extension is exposed to the guest here, shouldn't the
unbanked ssp CSR (0x011) be saved for the host and restored for the guest
in arch/riscv/kvm/vcpu_switch.S:__kvm_riscv_switch_to()?

Without this, if the host userspace uses shadow stacks, returning from the
guest might leave the guest's ssp active, potentially pointing into guest
memory.

Additionally, ssp appears to be missing from struct kvm_riscv_csr in
arch/riscv/include/uapi/asm/kvm.h and struct kvm_vcpu_csr in
arch/riscv/include/asm/kvm_host.h. Does this prevent saving or restoring
the register during live migration?

>  	KVM_RISCV_ISA_EXT_MAX,
>  };
>  
> diff --git a/arch/riscv/kvm/isa.c b/arch/riscv/kvm/isa.c
> index 1132d909cc25c..9852a91fdecc9 100644
> --- a/arch/riscv/kvm/isa.c
> +++ b/arch/riscv/kvm/isa.c
> @@ -65,6 +65,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),

[Severity: High]
Are these extensions being enabled by default?

Adding KVM_RISCV_ISA_EXT_ZICFILP and KVM_RISCV_ISA_EXT_ZICFISS here
advertises them to the KVM capabilities, but they don't appear to be added
to the exclusion list in kvm_riscv_isa_enable_allowed() in the same file.

Would this cause them to fall through to the default return true, and
subsequently be enabled automatically for all new VMs if the host supports
them?

If so, this might silently alter guest hardware discovery and affect
backwards compatibility for live migration to older hosts.

>  	KVM_ISA_EXT_ARR(ZICNTR),
>  	KVM_ISA_EXT_ARR(ZICOND),
>  	KVM_ISA_EXT_ARR(ZICSR),

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260601084336.2601675-1-inochiama@gmail.com?part=4

Re: [PATCH v2 4/7] RISC-V: KVM: Allow Zicfiss/Zicfilp extensions for Guest/VM

[Inochi Amaoto]

On Mon, Jun 01, 2026 at 04:43:32PM +0800, Inochi Amaoto wrote:
> Extend the KVM ISA extension array to allow KVM userspace to
> detect and enable Zicfiss/Zicfilp extensions for Guest/VM.
> 
> Assisted-by: YuanSheng:claude-4.7-opus
> Co-developed-by: Quan Zhou <zhouquan@iscas.ac.cn>
> Signed-off-by: Quan Zhou <zhouquan@iscas.ac.cn>
> Signed-off-by: Inochi Amaoto <inochiama@gmail.com>
> ---
>  arch/riscv/include/uapi/asm/kvm.h | 2 ++
>  arch/riscv/kvm/isa.c              | 2 ++
>  2 files changed, 4 insertions(+)
> 

I have forgot to add CSR_SSP to the context, will add in the next
version. But I have a small question for it: could I reuse the 
generic subtype or use a new CSR subtype?

Regards,
Inochi

> diff --git a/arch/riscv/include/uapi/asm/kvm.h b/arch/riscv/include/uapi/asm/kvm.h
> index 501e4fc60dd2..9f9c5ababd1e 100644
> --- a/arch/riscv/include/uapi/asm/kvm.h
> +++ b/arch/riscv/include/uapi/asm/kvm.h
> @@ -199,6 +199,8 @@ enum KVM_RISCV_ISA_EXT_ID {
>  	KVM_RISCV_ISA_EXT_ZCLSD,
>  	KVM_RISCV_ISA_EXT_ZILSD,
>  	KVM_RISCV_ISA_EXT_ZALASR,
> +	KVM_RISCV_ISA_EXT_ZICFILP,
> +	KVM_RISCV_ISA_EXT_ZICFISS,
>  	KVM_RISCV_ISA_EXT_MAX,
>  };
>  
> diff --git a/arch/riscv/kvm/isa.c b/arch/riscv/kvm/isa.c
> index 1132d909cc25..9852a91fdecc 100644
> --- a/arch/riscv/kvm/isa.c
> +++ b/arch/riscv/kvm/isa.c
> @@ -65,6 +65,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.54.0
> 
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v2 4/7] RISC-V: KVM: Allow Zicfiss/Zicfilp extensions for Guest/VM

[Anup Patel]

On Mon, Jun 1, 2026 at 4:46 PM Inochi Amaoto <inochiama@gmail.com> wrote:
>
> On Mon, Jun 01, 2026 at 04:43:32PM +0800, Inochi Amaoto wrote:
> > Extend the KVM ISA extension array to allow KVM userspace to
> > detect and enable Zicfiss/Zicfilp extensions for Guest/VM.
> >
> > Assisted-by: YuanSheng:claude-4.7-opus
> > Co-developed-by: Quan Zhou <zhouquan@iscas.ac.cn>
> > Signed-off-by: Quan Zhou <zhouquan@iscas.ac.cn>
> > Signed-off-by: Inochi Amaoto <inochiama@gmail.com>
> > ---
> >  arch/riscv/include/uapi/asm/kvm.h | 2 ++
> >  arch/riscv/kvm/isa.c              | 2 ++
> >  2 files changed, 4 insertions(+)
> >
>
> I have forgot to add CSR_SSP to the context, will add in the next
> version. But I have a small question for it: could I reuse the
> generic subtype or use a new CSR subtype?
>

Add another CSR subtype for Zicfiss.

Regards,
Anup

Re: [PATCH v2 4/7] RISC-V: KVM: Allow Zicfiss/Zicfilp extensions for Guest/VM

[Inochi Amaoto]

On Wed, Jun 03, 2026 at 01:16:14PM +0530, Anup Patel wrote:
> On Mon, Jun 1, 2026 at 4:46 PM Inochi Amaoto <inochiama@gmail.com> wrote:
> >
> > On Mon, Jun 01, 2026 at 04:43:32PM +0800, Inochi Amaoto wrote:
> > > Extend the KVM ISA extension array to allow KVM userspace to
> > > detect and enable Zicfiss/Zicfilp extensions for Guest/VM.
> > >
> > > Assisted-by: YuanSheng:claude-4.7-opus
> > > Co-developed-by: Quan Zhou <zhouquan@iscas.ac.cn>
> > > Signed-off-by: Quan Zhou <zhouquan@iscas.ac.cn>
> > > Signed-off-by: Inochi Amaoto <inochiama@gmail.com>
> > > ---
> > >  arch/riscv/include/uapi/asm/kvm.h | 2 ++
> > >  arch/riscv/kvm/isa.c              | 2 ++
> > >  2 files changed, 4 insertions(+)
> > >
> >
> > I have forgot to add CSR_SSP to the context, will add in the next
> > version. But I have a small question for it: could I reuse the
> > generic subtype or use a new CSR subtype?
> >
> 
> Add another CSR subtype for Zicfiss.
> 
> Regards,
> Anup

Thanks, I will do it.

Regards,
Inochi

[PATCH v2 5/7] RISC-V: KVM: Handle software-check exits for VCPU

[Inochi Amaoto]

The extension Zicfiss/Zicfilp introduces a software-check exception
to the privilege architecture. Delegate this exception to VS mode so
the CFI violations in VU/VS could be reported.

Assisted-by: YuanSheng:claude-4.7-opus
Co-developed-by: Quan Zhou <zhouquan@iscas.ac.cn>
Signed-off-by: Quan Zhou <zhouquan@iscas.ac.cn>
Signed-off-by: Inochi Amaoto <inochiama@gmail.com>
---
 arch/riscv/include/asm/csr.h | 1 +
 arch/riscv/kvm/vcpu_config.c | 4 ++++
 arch/riscv/kvm/vcpu_exit.c   | 3 +++
 3 files changed, 8 insertions(+)

diff --git a/arch/riscv/include/asm/csr.h b/arch/riscv/include/asm/csr.h
index 31b8988f4488..224af9facf1f 100644
--- a/arch/riscv/include/asm/csr.h
+++ b/arch/riscv/include/asm/csr.h
@@ -117,6 +117,7 @@
 #define EXC_INST_PAGE_FAULT	12
 #define EXC_LOAD_PAGE_FAULT	13
 #define EXC_STORE_PAGE_FAULT	15
+#define EXC_SOFTWARE_CHECK		18
 #define EXC_INST_GUEST_PAGE_FAULT	20
 #define EXC_LOAD_GUEST_PAGE_FAULT	21
 #define EXC_VIRTUAL_INST_FAULT		22
diff --git a/arch/riscv/kvm/vcpu_config.c b/arch/riscv/kvm/vcpu_config.c
index b2a1028106d5..dbe4167ac4f1 100644
--- a/arch/riscv/kvm/vcpu_config.c
+++ b/arch/riscv/kvm/vcpu_config.c
@@ -65,6 +65,10 @@ void kvm_riscv_vcpu_config_ran_once(struct kvm_vcpu *vcpu)
 
 	if (vcpu->guest_debug)
 		cfg->hedeleg &= ~BIT(EXC_BREAKPOINT);
+
+	if (riscv_isa_extension_available(isa, ZICFILP) ||
+	    riscv_isa_extension_available(isa, ZICFISS))
+		cfg->hedeleg |= BIT(EXC_SOFTWARE_CHECK);
 }
 
 void kvm_riscv_vcpu_config_load(struct kvm_vcpu *vcpu)
diff --git a/arch/riscv/kvm/vcpu_exit.c b/arch/riscv/kvm/vcpu_exit.c
index 0bb0c51e3c89..5ab8e87ed248 100644
--- a/arch/riscv/kvm/vcpu_exit.c
+++ b/arch/riscv/kvm/vcpu_exit.c
@@ -243,6 +243,9 @@ int kvm_riscv_vcpu_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
 		run->exit_reason = KVM_EXIT_DEBUG;
 		ret = 0;
 		break;
+	case EXC_SOFTWARE_CHECK:
+		ret = vcpu_redirect(vcpu, trap);
+		break;
 	default:
 		break;
 	}
-- 
2.54.0

Re: [PATCH v2 5/7] RISC-V: KVM: Handle software-check exits for VCPU

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] KVM fails to context-switch the Shadow Stack Pointer (CSR_SSP), leading to cross-VCPU leaks and guest shadow stack corruption.
- [High] KVM fails to propagate the SPELP (Supervisor Previous Expected Landing Pad) bit when redirecting traps to the guest, breaking guest CFI tracking.
- [Medium] KVM unconditionally redirects EXC_SOFTWARE_CHECK to the guest upon VM exit, which will inject an un-enumerated exception into guests that have not negotiated the Zicfilp/Zicfiss extensions.
--

commit bea0e82f22f5523f333dc995d01ccbe77f69b200
Author: Inochi Amaoto <inochiama@gmail.com>

RISC-V: KVM: Handle software-check exits for VCPU

This commit enables the software-check exception for RISC-V KVM, delegating
it to VS mode so CFI violations (Zicfiss/Zicfilp) can be reported to the
guest.

> diff --git a/arch/riscv/kvm/vcpu_config.c b/arch/riscv/kvm/vcpu_config.c
> index b2a1028106d5d..dbe4167ac4f16 100644
> --- a/arch/riscv/kvm/vcpu_config.c
> +++ b/arch/riscv/kvm/vcpu_config.c

[ ... ]

> @@ -65,6 +65,10 @@ void kvm_riscv_vcpu_config_ran_once(struct kvm_vcpu *vcpu)
>  
>  	if (vcpu->guest_debug)
>  		cfg->hedeleg &= ~BIT(EXC_BREAKPOINT);
> +
> +	if (riscv_isa_extension_available(isa, ZICFILP) ||
> +	    riscv_isa_extension_available(isa, ZICFISS))
> +		cfg->hedeleg |= BIT(EXC_SOFTWARE_CHECK);

[Severity: High]
The Zicfiss extension introduces the CSR_SSP (Shadow Stack Pointer) register,
which is a user-mode CSR and isn't automatically saved or restored by the
hardware on VM exits.

If KVM does not manually context-switch this register in 
arch/riscv/kvm/vcpu.c:kvm_riscv_vcpu_context_switch() or during VCPU load/put
paths, could a new VCPU inherit the previous VCPU's CSR_SSP and leak state
across VMs?

Additionally, when returning to host userspace, won't the host kernel's
exception return code overwrite CSR_SSP with the host process's shadow stack
pointer, leading to an immediate crash upon re-entry to the guest?

>  }

> diff --git a/arch/riscv/kvm/vcpu_exit.c b/arch/riscv/kvm/vcpu_exit.c
> index 0bb0c51e3c890..5ab8e87ed248b 100644
> --- a/arch/riscv/kvm/vcpu_exit.c
> +++ b/arch/riscv/kvm/vcpu_exit.c

[ ... ]

> @@ -243,6 +243,9 @@ int kvm_riscv_vcpu_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
>  		run->exit_reason = KVM_EXIT_DEBUG;
>  		ret = 0;
>  		break;
> +	case EXC_SOFTWARE_CHECK:
> +		ret = vcpu_redirect(vcpu, trap);

[Severity: Medium]
This unconditionally redirects EXC_SOFTWARE_CHECK back to the guest.

If a guest has not negotiated the Zicfilp/Zicfiss extensions, KVM won't
delegate EXC_SOFTWARE_CHECK via hedeleg.

If an unexpected CPU state or hardware issue triggers this exception in
VS-mode and traps to HS-mode, this redirect will inject an un-enumerated
exception into the guest.

Does this code need to verify riscv_isa_extension_available() before
redirecting the trap?

[Severity: High]
When a trap occurs in VS/VU-mode and is taken to HS-mode, the hardware
records the previous Zicfilp ELP state in the host sstatus.SPELP bit, which
KVM subsequently saves into vcpu->arch.guest_context.sstatus.

When vcpu_redirect() is called here, it eventually invokes
kvm_riscv_vcpu_trap_redirect(), which updates the guest's VSSTATUS register:

arch/riscv/kvm/vcpu_exit.c:kvm_riscv_vcpu_trap_redirect() {
    ...
    unsigned long vsstatus = ncsr_read(CSR_VSSTATUS);

    vsstatus &= ~SR_SPP;
    if (vcpu->arch.guest_context.sstatus & SR_SPP)
        vsstatus |= SR_SPP;
    
    ncsr_write(CSR_VSSTATUS, vsstatus);
    ...
}

Since kvm_riscv_vcpu_trap_redirect() explicitly copies SPP, SPIE, and SIE
but does not copy the SPELP bit (SR_SPELP), does this cause the guest OS to
lose its Zicfilp CFI tracking state across KVM-injected traps?

> +		break;
>  	default:
>  		break;
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260601084336.2601675-1-inochiama@gmail.com?part=5

[PATCH v2 6/7] RISC-V: KVM: Add support for control-flow integrity FWFT features

[Inochi Amaoto]

Control-flow integrity is controlled through a WARL field in henvcfg.
Expose the feature only if the Zicfilp/Zicfiss is supported for VS-mode.
Allow the VMM to block access to the feature by disabling the ISA
extension in the guest.

Assisted-by: YuanSheng:claude-4.7-opus
Co-developed-by: Quan Zhou <zhouquan@iscas.ac.cn>
Signed-off-by: Quan Zhou <zhouquan@iscas.ac.cn>
Signed-off-by: Inochi Amaoto <inochiama@gmail.com>
---
 arch/riscv/kvm/vcpu_sbi_fwft.c | 70 ++++++++++++++++++++++++++++++++++
 1 file changed, 70 insertions(+)

diff --git a/arch/riscv/kvm/vcpu_sbi_fwft.c b/arch/riscv/kvm/vcpu_sbi_fwft.c
index 375269e43c13..278eb95b97de 100644
--- a/arch/riscv/kvm/vcpu_sbi_fwft.c
+++ b/arch/riscv/kvm/vcpu_sbi_fwft.c
@@ -163,6 +163,58 @@ static long kvm_sbi_fwft_get_misaligned_delegation(struct kvm_vcpu *vcpu,
 	return SBI_SUCCESS;
 }
 
+static bool kvm_sbi_fwft_landing_pad_supported(struct kvm_vcpu *vcpu)
+{
+	return riscv_isa_extension_available(vcpu->arch.isa, ZICFILP);
+}
+
+static void kvm_sbi_fwft_reset_landing_pad(struct kvm_vcpu *vcpu)
+{
+	kvm_sbi_fwft_env_flag_reset_helper(vcpu, ENVCFG_LPE);
+}
+
+static long kvm_sbi_fwft_set_landing_pad(struct kvm_vcpu *vcpu,
+					 struct kvm_sbi_fwft_config *conf,
+					 bool one_reg_access, unsigned long value)
+{
+	return kvm_sbi_fwft_env_flag_set_helper(vcpu, conf, one_reg_access,
+						value, ENVCFG_LPE);
+}
+
+static long kvm_sbi_fwft_get_landing_pad(struct kvm_vcpu *vcpu,
+					 struct kvm_sbi_fwft_config *conf,
+					 bool one_reg_access, unsigned long *value)
+{
+	return kvm_sbi_fwft_env_flag_get_helper(vcpu, conf, one_reg_access,
+						value, ENVCFG_LPE);
+}
+
+static bool kvm_sbi_fwft_shadow_stack_supported(struct kvm_vcpu *vcpu)
+{
+	return riscv_isa_extension_available(vcpu->arch.isa, ZICFISS);
+}
+
+static void kvm_sbi_fwft_reset_shadow_stack(struct kvm_vcpu *vcpu)
+{
+	kvm_sbi_fwft_env_flag_reset_helper(vcpu, ENVCFG_SSE);
+}
+
+static long kvm_sbi_fwft_set_shadow_stack(struct kvm_vcpu *vcpu,
+					  struct kvm_sbi_fwft_config *conf,
+					  bool one_reg_access, unsigned long value)
+{
+	return kvm_sbi_fwft_env_flag_set_helper(vcpu, conf, one_reg_access,
+						value, ENVCFG_SSE);
+}
+
+static long kvm_sbi_fwft_get_shadow_stack(struct kvm_vcpu *vcpu,
+					  struct kvm_sbi_fwft_config *conf,
+					  bool one_reg_access, unsigned long *value)
+{
+	return kvm_sbi_fwft_env_flag_get_helper(vcpu, conf, one_reg_access,
+						value, ENVCFG_SSE);
+}
+
 static bool kvm_sbi_fwft_pte_ad_hw_updating_supported(struct kvm_vcpu *vcpu)
 {
 	return riscv_isa_extension_available(vcpu->arch.isa, SVADU) &&
@@ -288,6 +340,24 @@ static const struct kvm_sbi_fwft_feature features[] = {
 		.set = kvm_sbi_fwft_set_misaligned_delegation,
 		.get = kvm_sbi_fwft_get_misaligned_delegation,
 	},
+	{
+		.id = SBI_FWFT_LANDING_PAD,
+		.first_reg_num = offsetof(struct kvm_riscv_sbi_fwft, landing_pad.enable) /
+				 sizeof(unsigned long),
+		.supported = kvm_sbi_fwft_landing_pad_supported,
+		.reset = kvm_sbi_fwft_reset_landing_pad,
+		.set = kvm_sbi_fwft_set_landing_pad,
+		.get = kvm_sbi_fwft_get_landing_pad,
+	},
+	{
+		.id = SBI_FWFT_SHADOW_STACK,
+		.first_reg_num = offsetof(struct kvm_riscv_sbi_fwft, shadow_stack.enable) /
+				 sizeof(unsigned long),
+		.supported = kvm_sbi_fwft_shadow_stack_supported,
+		.reset = kvm_sbi_fwft_reset_shadow_stack,
+		.set = kvm_sbi_fwft_set_shadow_stack,
+		.get = kvm_sbi_fwft_get_shadow_stack,
+	},
 	{
 		.id = SBI_FWFT_PTE_AD_HW_UPDATING,
 		.first_reg_num = offsetof(struct kvm_riscv_sbi_fwft, pte_ad_hw_updating.enable) /
-- 
2.54.0

Re: [PATCH v2 6/7] RISC-V: KVM: Add support for control-flow integrity FWFT features

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
- [High] KVM fails to context-switch the shadow stack pointer (CSR_SSP) when exposing ZICFISS to the guest.
- [High] Direct write to `CSR_HENVCFG` bypasses nested acceleration (NaCl) shared memory synchronization.
- [High] The `unsigned long flag` argument in `henvcfg` helpers zero-extends and corrupts the upper 32 bits on RV32, and silently truncates 64-bit flags.
- [High] Guest can bypass VMM ISA restrictions to enable FWFT features due to caching at vCPU creation.
- [High] Modifying FWFT features via KVM_SET_ONE_REG updates `vcpu->arch.cfg.henvcfg` but fails to mark the CSR as dirty, leading to stale hardware state execution.
- [Medium] SBI FWFT flags are committed even if the feature value set operation fails.
--

commit c2d9c5584a3fada7da09588693c511ec3fdbbcf1
Author: Inochi Amaoto <inochiama@gmail.com>
Subject: RISC-V: KVM: Add support for control-flow integrity FWFT features

This commit exposes the Zicfilp and Zicfiss control-flow integrity features
to guests through the SBI FWFT interface. It also allows the VMM to block
access to these features by disabling the corresponding ISA extensions.

> diff --git a/arch/riscv/kvm/vcpu_sbi_fwft.c b/arch/riscv/kvm/vcpu_sbi_fwft.c
> index 375269e43c13b..278eb95b97de4 100644
> --- a/arch/riscv/kvm/vcpu_sbi_fwft.c
> +++ b/arch/riscv/kvm/vcpu_sbi_fwft.c
> @@ -163,6 +163,58 @@ static long kvm_sbi_fwft_get_misaligned_delegation(struct kvm_vcpu *vcpu,
[ ... ]
> +static bool kvm_sbi_fwft_landing_pad_supported(struct kvm_vcpu *vcpu)
> +{
> +	return riscv_isa_extension_available(vcpu->arch.isa, ZICFILP);
> +}

[Severity: High]
Does checking the ISA extension at vCPU creation allow the guest to bypass VMM
restrictions?

The FWFT framework caches feature availability during kvm_sbi_ext_fwft_init()
which executes at vCPU creation. At that time, vcpu->arch.isa typically
contains all default host-supported extensions.

If the VMM later configures the VM by disabling unsupported extensions via
KVM_SET_ONE_REG, the guest can still successfully enable the hardware features
because the FWFT layer permanently cached conf->supported as true.

[ ... ]
> +static long kvm_sbi_fwft_set_landing_pad(struct kvm_vcpu *vcpu,
> +					 struct kvm_sbi_fwft_config *conf,
> +					 bool one_reg_access, unsigned long value)
> +{
> +	return kvm_sbi_fwft_env_flag_set_helper(vcpu, conf, one_reg_access,
> +						value, ENVCFG_LPE);
> +}

[Severity: High]
Can passing ENVCFG_LPE to this helper cause truncation or zero-extension
issues?

Looking at kvm_sbi_fwft_env_flag_set_helper(), the flag parameter is typed as
unsigned long. On RV32, unsigned long is 32 bits, which would truncate 64-bit
flags.

Furthermore, when clearing a flag via cfg->henvcfg &= ~flag, if flag is 0,
~flag evaluates to the 32-bit 0xFFFFFFFF. Because cfg->henvcfg is a u64,
the 32-bit mask is zero-extended to 0x00000000FFFFFFFFULL.

This zero-extension permanently wipes the entire upper 32 bits of henvcfg and
corrupts hardware states like Svpbmt and Zicbom on 32-bit KVM hosts.

[Severity: High]
Does modifying FWFT features via KVM_SET_ONE_REG lead to stale hardware state?

When userspace modifies an FWFT feature via KVM_SET_ONE_REG, one_reg_access is
true. In kvm_sbi_fwft_env_flag_set_helper():

    if (!one_reg_access)
        csr_write(CSR_HENVCFG, vcpu->arch.cfg.henvcfg);

This updates the in-memory vcpu->arch.cfg.henvcfg but skips the immediate CSR
write. However, it fails to set vcpu->arch.csr_dirty = true.

When vcpu_load() later executes, it evaluates !vcpu->arch.csr_dirty and skips
kvm_riscv_vcpu_config_load(), causing the guest to run with stale hardware
configurations.

[Severity: High]
Does writing directly to CSR_HENVCFG bypass nested acceleration?

When one_reg_access is false, kvm_sbi_fwft_env_flag_set_helper() directly
writes the hardware CSR using csr_write(CSR_HENVCFG, ...).

When KVM runs as an L1 nested hypervisor with RISC-V nested acceleration
enabled, hardware CSRs must be synchronized with the L0 hypervisor via a
shared memory region.

Bypassing the ncsr_write() wrapper fails to set the dirty bit in the shared
memory bitmap, meaning the L0 hypervisor remains unaware of the change and
will overwrite the hardware CSR with a stale value on the next nested VM entry.

[ ... ]
> +static bool kvm_sbi_fwft_shadow_stack_supported(struct kvm_vcpu *vcpu)
> +{
> +	return riscv_isa_extension_available(vcpu->arch.isa, ZICFISS);
> +}

[Severity: High]
Does exposing ZICFISS without context-switching CSR_SSP leak guest state into
the host?

When a guest enables and uses the shadow stack, it writes to the shadow stack
pointer CSR_SSP. KVM does not currently save or restore CSR_SSP during VCPU
context switches.

Since U-mode CSRs are not automatically banked by the RISC-V hardware between
host and guest execution modes, the guest's shadow stack pointer remains active
when returning to the host.

When the host's userspace resumes execution, it does so with a corrupted shadow
stack pointer, leading to shadow stack violations and a denial-of-service
crash.

[ ... ]
> @@ -288,6 +340,24 @@ static const struct kvm_sbi_fwft_feature features[] = {
>  		.set = kvm_sbi_fwft_set_misaligned_delegation,
>  		.get = kvm_sbi_fwft_get_misaligned_delegation,
>  	},
> +	{
> +		.id = SBI_FWFT_LANDING_PAD,
> +		.first_reg_num = offsetof(struct kvm_riscv_sbi_fwft, landing_pad.enable) /
> +				 sizeof(unsigned long),
> +		.supported = kvm_sbi_fwft_landing_pad_supported,
> +		.reset = kvm_sbi_fwft_reset_landing_pad,
> +		.set = kvm_sbi_fwft_set_landing_pad,
> +		.get = kvm_sbi_fwft_get_landing_pad,
> +	},

[Severity: Medium]
Are SBI FWFT flags committed even if the set operation fails?

Looking at kvm_sbi_fwft_set(), the flags are assigned before the
feature-specific set callback is executed:

    conf->flags = flags;
    return conf->feature->set(vcpu, conf, false, value);

If the set callback fails and returns an error like SBI_ERR_INVALID_PARAM,
the flags are not rolled back.

If the guest request included SBI_FWFT_SET_FLAG_LOCK, the feature becomes
permanently locked into a stale state, preventing subsequent corrections.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260601084336.2601675-1-inochiama@gmail.com?part=6

[PATCH v2 7/7] KVM: riscv: selftests: add Zicfiss/Zicfilp extension to get-reg-list test

[Inochi Amaoto]

The KVM RISC-V allows Zicfiss/Zicfilp extensions for Guest/VM so
add these extensions to get-reg-list test.

Assisted-by: YuanSheng:claude-4.7-opus
Co-developed-by: Quan Zhou <zhouquan@iscas.ac.cn>
Signed-off-by: Quan Zhou <zhouquan@iscas.ac.cn>
Signed-off-by: Inochi Amaoto <inochiama@gmail.com>
---
 tools/testing/selftests/kvm/riscv/get-reg-list.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/tools/testing/selftests/kvm/riscv/get-reg-list.c b/tools/testing/selftests/kvm/riscv/get-reg-list.c
index d88edef77ccf..4fab3d2d0b43 100644
--- a/tools/testing/selftests/kvm/riscv/get-reg-list.c
+++ b/tools/testing/selftests/kvm/riscv/get-reg-list.c
@@ -89,6 +89,8 @@ bool filter_reg(__u64 reg)
 	case KVM_REG_RISCV_ISA_EXT | KVM_REG_RISCV_ISA_SINGLE | KVM_RISCV_ISA_EXT_ZICBOP:
 	case KVM_REG_RISCV_ISA_EXT | KVM_REG_RISCV_ISA_SINGLE | KVM_RISCV_ISA_EXT_ZICBOZ:
 	case KVM_REG_RISCV_ISA_EXT | KVM_REG_RISCV_ISA_SINGLE | KVM_RISCV_ISA_EXT_ZICCRSE:
+	case KVM_REG_RISCV_ISA_EXT | KVM_REG_RISCV_ISA_SINGLE | KVM_RISCV_ISA_EXT_ZICFILP:
+	case KVM_REG_RISCV_ISA_EXT | KVM_REG_RISCV_ISA_SINGLE | KVM_RISCV_ISA_EXT_ZICFISS:
 	case KVM_REG_RISCV_ISA_EXT | KVM_REG_RISCV_ISA_SINGLE | KVM_RISCV_ISA_EXT_ZICNTR:
 	case KVM_REG_RISCV_ISA_EXT | KVM_REG_RISCV_ISA_SINGLE | KVM_RISCV_ISA_EXT_ZICOND:
 	case KVM_REG_RISCV_ISA_EXT | KVM_REG_RISCV_ISA_SINGLE | KVM_RISCV_ISA_EXT_ZICSR:
@@ -552,6 +554,8 @@ static const char *isa_ext_single_id_to_str(__u64 reg_off)
 		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),
@@ -715,6 +719,12 @@ static const char *sbi_fwft_id_to_str(__u64 reg_off)
 	case 6: return "KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(pte_ad_hw_updating.enable)";
 	case 7: return "KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(pte_ad_hw_updating.flags)";
 	case 8: return "KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(pte_ad_hw_updating.value)";
+	case 9: return "KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(landing_pad.enable)";
+	case 10: return "KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(landing_pad.flags)";
+	case 11: return "KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(landing_pad.value)";
+	case 12: return "KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(shadow_stack.enable)";
+	case 13: return "KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(shadow_stack.flags)";
+	case 14: return "KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(shadow_stack.value)";
 	}
 	return strdup_printf("KVM_REG_RISCV_SBI_FWFT | %lld /* UNKNOWN */", reg_off);
 }
@@ -911,6 +921,12 @@ static __u64 sbi_fwft_regs[] = {
 	KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_SBI_STATE | KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(pte_ad_hw_updating.enable),
 	KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_SBI_STATE | KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(pte_ad_hw_updating.flags),
 	KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_SBI_STATE | KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(pte_ad_hw_updating.value),
+	KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_SBI_STATE | KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(landing_pad.enable),
+	KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_SBI_STATE | KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(landing_pad.flags),
+	KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_SBI_STATE | KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(landing_pad.value),
+	KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_SBI_STATE | KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(shadow_stack.enable),
+	KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_SBI_STATE | KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(shadow_stack.flags),
+	KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_SBI_STATE | KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(shadow_stack.value),
 };
 
 static __u64 zicbom_regs[] = {
-- 
2.54.0

Re: [PATCH v2 7/7] KVM: riscv: selftests: add Zicfiss/Zicfilp extension to get-reg-list test

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Medium] The commit adds Zicfiss and Zicfilp extensions to the get-reg-list selftest but completely omits defining their vCPU test configurations, meaning the standalone tests for these extensions are never run.

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but KVM statically caches the supported state of FWFT features at vCPU initialization, allowing a guest to use Zicfiss/Zicfilp (and other) FWFT features even after the VMM explicitly disables these ISA extensions.
--

commit c2918e7cd002c4f98c92703739dfdfd8015014a7
Author: Inochi Amaoto <inochiama@gmail.com>

KVM: riscv: selftests: add Zicfiss/Zicfilp extension to get-reg-list test

The KVM RISC-V allows Zicfiss/Zicfilp extensions for Guest/VM so
add these extensions to get-reg-list test.

> diff --git a/tools/testing/selftests/kvm/riscv/get-reg-list.c b/tools/testing/selftests/kvm/riscv/get-reg-list.c
> index d88edef77ccfd..4fab3d2d0b433 100644
> --- a/tools/testing/selftests/kvm/riscv/get-reg-list.c
> +++ b/tools/testing/selftests/kvm/riscv/get-reg-list.c
[ ... ]
> @@ -911,6 +921,12 @@ static __u64 sbi_fwft_regs[] = {
>  	KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_SBI_STATE | KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(pte_ad_hw_updating.enable),
>  	KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_SBI_STATE | KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(pte_ad_hw_updating.flags),
>  	KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_SBI_STATE | KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(pte_ad_hw_updating.value),
> +	KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_SBI_STATE | KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(landing_pad.enable),
> +	KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_SBI_STATE | KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(landing_pad.flags),
> +	KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_SBI_STATE | KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(landing_pad.value),
> +	KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_SBI_STATE | KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(shadow_stack.enable),
> +	KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_SBI_STATE | KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(shadow_stack.flags),
> +	KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_SBI_STATE | KVM_REG_RISCV_SBI_FWFT | KVM_REG_RISCV_SBI_FWFT_REG(shadow_stack.value),
>  };

[Severity: High]
This isn't a bug introduced by this patch, but KVM statically caches the
supported state of FWFT features at vCPU initialization, allowing a guest
to use Zicfiss/Zicfilp (and other) FWFT features even after the VMM
explicitly disables these ISA extensions.

During kvm_arch_vcpu_create(), kvm_sbi_ext_fwft_init() statically caches whether
an FWFT feature is supported by calling its supported() callback (e.g.
riscv_isa_extension_available(vcpu->arch.isa, ZICFILP)):

arch/riscv/kvm/vcpu_sbi_fwft.c:kvm_sbi_ext_fwft_init() {
    ...
	if (feature->supported)
		conf->supported = feature->supported(vcpu);
    ...
}

The VMM may subsequently disable the underlying ISA extension using
KVM_SET_ONE_REG, which clears the bit in vcpu->arch.isa.

However, the cached conf->supported state is never re-evaluated. When the guest
later attempts to enable the feature via SBI_EXT_FWFT_SET,
kvm_fwft_get_feature() reads the stale true value:

arch/riscv/kvm/vcpu_sbi_fwft.c:kvm_fwft_get_feature() {
    ...
	if (!tconf->supported || !tconf->enabled)
		return SBI_ERR_NOT_SUPPORTED;
    ...
}

Could this allow the guest to bypass the VMM's configuration and trigger
hardware states that were explicitly disabled, violating the virtualization
boundary?

[Severity: Medium]
Are we missing the vcpu test configurations for the Zicfilp and Zicfiss
extensions?

The get-reg-list test suite relies on the vcpu_configs[] array and explicitly
declared configurations to determine which subtests to run:

tools/testing/selftests/kvm/riscv/get-reg-list.c:
struct vcpu_reg_list *vcpu_configs[] = {
	&config_sbi_base,
	...
};

While the commit updates filter_reg() and adds the registers to sbi_fwft_regs,
it omits the required KVM_ISA_EXT_SIMPLE_CONFIG() macro definitions for these
extensions and fails to append &config_zicfilp and &config_zicfiss to the
vcpu_configs[] array.

Will this cause the standalone validation for getting/setting these new ISA
extension registers to be silently skipped, leaving a gap in test coverage?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260601084336.2601675-1-inochiama@gmail.com?part=7