[PATCH v4 0/3] RISC-V: KVM: fix vcpu vector context handling

[PATCH v4 0/3] RISC-V: KVM: fix vcpu vector context handling

[Andy Chiu]

This series fixes a vtype corruption encountered when running perf +
vector workload on KVM.

The root cause of the bug is that the kernel-mode vector (KMV)
misattributes the guest's vcpu context as the user's context. To solve
this, we need to correctly save the vcpu context when the kernel-mode
vector is serving a guest.

However, calling directly into KVM from RISC-V generic architecture code
creates a reverse dependency, which is problematic when KVM is built as
a module. To address this, we introduce an RCU-protected callback for
context flushing, which KVM registers during module init.

Patch 1 is a preparatory cleanup that refactors
riscv_v_start_kernel_context().
Patch 2 prepares get/put_cpu_vector_context() for gaurding the use of
vector in kvm_arch_vcpu_load/put()
Patch 3 implements the callback mechanism and fixes the context handling.

Patch summary:
 - unchanged patch: 1, 3
 - new patch: none
 - modified patch: 2

Changelog v4:
 - Include a header to solve a mid-series build fail (patchwork ci)
 - Drop preempt_v_started test in may_use_simd (Sashiko)
 - Link to v3: https://lore.kernel.org/all/20260724165001.2317788-1-tchiu@tenstorrent.com/

Changelog v3:
 - Limit the export scope for {get,put}_cpu_vector_context()
 - clears RISCV_V_VCPU_NEED_RESTORE flag in host restore to prevent
   leaking
 - consolidates guest vector restore at returning to guest to prevent
   unnecessary save/restore between the preemptible window from
   vcpu_load to vcpu_enter_exit
 - Document flags added to riscv_v_flags
 - Link to v2: https://lore.kernel.org/all/20260715051629.1169645-1-tchiu@tenstorrent.com/

Changelog v2:
 - Address issues pointed out by sashiko (2, 3)
 - Link to v1: https://lore.kernel.org/all/20260711015835.767259-1-tchiu@tenstorrent.com/

Andy Chiu (3):
  riscv: vector: refactor riscv_v_start_kernel_context
  riscv: vector: allow non-preemptible kernel-mode vector with IRQs off
  RISC-V: KVM: fix vcpu vector context handling for kernel-mode vector

 arch/riscv/include/asm/kvm_vcpu_vector.h | 24 +++++++
 arch/riscv/include/asm/processor.h       |  8 +++
 arch/riscv/include/asm/simd.h            | 16 +----
 arch/riscv/include/asm/vector.h          |  5 ++
 arch/riscv/kernel/kernel_mode_vector.c   | 80 ++++++++++++++++--------
 arch/riscv/kvm/main.c                    |  4 ++
 arch/riscv/kvm/vcpu.c                    | 12 ++++
 arch/riscv/kvm/vcpu_vector.c             | 22 ++++++-
 8 files changed, 131 insertions(+), 40 deletions(-)

-- 
2.43.0

Re: [PATCH v4 2/3] riscv: vector: allow non-preemptible kernel-mode vector with IRQs off

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Removing the `!irqs_disabled()` check from `may_use_simd()` exposes KVM guest vector state to corruption and leakage by hardirqs.
--

--- Patch [2]: [PATCH v4 2/3] riscv: vector: allow non-preemptible kernel-mode vector with IRQs off ---
commit db1e5a6ad1a80d124f168f9dae7f399f6eec4f67
Author: Andy Chiu <tchiu@tenstorrent.com>

riscv: vector: allow non-preemptible kernel-mode vector with IRQs off

This commit upgrades get/put_cpu_vector_context to allow safe execution under
both IRQ off and regular process context, similar to arm64/fpsimd. It also
exports these symbols for the KVM module to call.

> diff --git a/arch/riscv/include/asm/simd.h b/arch/riscv/include/asm/simd.h
> index adb50f3ec2057..f176a8072c625 100644
> --- a/arch/riscv/include/asm/simd.h
> +++ b/arch/riscv/include/asm/simd.h
[ ... ]
> @@ -36,20 +36,10 @@ static __must_check inline bool may_use_simd(void)
>  	/*
>  	 * Nesting is achieved in preempt_v by spreading the control for
>  	 * preemptible and non-preemptible kernel-mode Vector into two fields.
> -	 * Always try to match with preempt_v if kernel V-context exists. Then,
> -	 * fallback to check non preempt_v if nesting happens, or if the config
> -	 * is not set.
> +	 * Only non-preempt_v can nest on top of preempt_v, if non-preempt_v is
> +	 * unavailable, then preempt_v is not allowed.
>  	 */
> -	if (IS_ENABLED(CONFIG_RISCV_ISA_V_PREEMPTIVE) && current->thread.kernel_vstate.datap) {
> -		if (!riscv_preempt_v_started(current))
> -			return true;
> -	}
> -	/*
> -	 * Non-preemptible kernel-mode Vector temporarily disables bh. So we
> -	 * must not return true on irq_disabled(). Otherwise we would fail the
> -	 * lockdep check calling local_bh_enable()
> -	 */
> -	return !irqs_disabled() && !(riscv_v_flags() & RISCV_KERNEL_MODE_V);
> +	return !(riscv_v_flags() & RISCV_KERNEL_MODE_V);

[Severity: High]
Does removing the !irqs_disabled() check here expose KVM guest vector state
to corruption and leakage by hardirqs?

If KVM loads guest vector state into CPU registers during kvm_arch_vcpu_load(),
and a hardirq using vector instructions fires while running KVM code,
may_use_simd() will now return true.

Would kernel_vector_begin() then save the CPU hardware registers (which contain
KVM guest data) into the host task's current->thread.vstate, followed by the
hardirq clobbering the CPU registers with its own vector operations?

If this happens, when the hardirq returns KVM would resume with corrupted
vector state, and the host task (e.g., QEMU) could receive the leaked guest
state.

While this series exports KVM symbols to potentially let KVM set
RISCV_KERNEL_MODE_V to protect the state, are the actual KVM patches to set
this flag missing from this series, leaving the tree vulnerable in the interim?

>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260725001749.2579274-1-tchiu@tenstorrent.com?part=2