Re: [PATCH v2] KVM: selftests: riscv: Add lazy V extension enablement for guests

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `v_available` global variable is modified by the host but never synchronized to the guest, causing the lazy V extension enablement to fail.
--

--- Patch [1]: [PATCH v2] KVM: selftests: riscv: Add lazy V extension enablement for guests ---
commit cbe1d2bca6a87eaa2ec0da02cdab16afeceb5c77
Author: jinrui <jinrui@haiwei.tech>

KVM: selftests: riscv: Add lazy V extension enablement for guests

This commit introduces lazy V extension enablement in RISC-V KVM selftests.
It adds a global variable to track V extension availability and updates the
guest exception handler to re-execute vector instructions when trapped.

> diff --git a/tools/testing/selftests/kvm/lib/riscv/processor.c b/tools/testing/selftests/kvm/lib/riscv/processor.c
> --- a/tools/testing/selftests/kvm/lib/riscv/processor.c
> +++ b/tools/testing/selftests/kvm/lib/riscv/processor.c

[ ... ]

> @@ -348,8 +343,23 @@ struct kvm_vcpu *vm_arch_vcpu_add(struct kvm_vm *vm, u32 vcpu_id)
>  	/* Setup sscratch for guest_get_vcpuid() */
>  	vcpu_set_reg(vcpu, RISCV_GENERAL_CSR_REG(sscratch), vcpu_id);
>  
> -	/* Setup default exception vector of guest */
> -	vcpu_set_reg(vcpu, RISCV_GENERAL_CSR_REG(stvec), (unsigned long)guest_unexp_trap);
> +	/*
> +	 * Enable the V (vector) extension in KVM so that the compiler can
> +	 * safely generate vector instructions (e.g. via -O2 auto-
> +	 * vectorization). Silently ignore errors; the test will still work
> +	 * without V.
> +	 */
> +	__vcpu_set_reg(vcpu, RISCV_ISA_EXT_REG(KVM_RISCV_ISA_EXT_V), 1);
> +	v_available = __vcpu_has_isa_ext(vcpu, KVM_RISCV_ISA_EXT_V);

[Severity: Medium]
Does v_available need to be synchronized to the guest here using
sync_global_to_guest(vm, v_available)?

Because vm_arch_vcpu_add() updates this from the host context, the guest
will only see its own unsynchronized copy (which defaults to false).

> +
> +	/*
> +	 * Use the full exception vector table (which provides lazy V
> +	 * extension enablement for EXC_INST_ILLEGAL in route_exception)
> +	 * as the default exception handler. vm_init_vector_tables() is
> +	 * idempotent; tests that call it again will get a no-op.
> +	 */
> +	vm_init_vector_tables(vm);
> +	vcpu_init_vector_tables(vcpu);
>  
>  	return vcpu;
>  }

[ ... ]

> @@ -432,6 +442,33 @@ void route_exception(struct pt_regs *regs)
>  		ec = 0;
>  	}
>  
> +	/*
> +	 * Handle V (vector) extension lazy enablement before any
> +	 * registered handler. The compiler's default march may include
> +	 * V, and auto-vectorization generates vector instructions that
> +	 * trigger EXC_INST_ILLEGAL when VS (Vector Status) in sstatus
> +	 * is Off. Enable VS to Initial and re-execute the faulting
> +	 * instruction, mimicking what a real OS kernel does.
> +	 *
> +	 * This check runs before any test-registered handler, so tests
> +	 * that install their own EXC_INST_ILLEGAL handler (e.g.
> +	 * sbi_pmu_test) are not affected.
> +	 */
> +	if (!(regs->cause & CAUSE_IRQ_FLAG) && ec == EXC_INST_ILLEGAL) {
> +		/*
> +		 * If KVM supports the V extension for this Guest and VS
> +		 * (Vector Status) is Off in the saved sstatus, set it to
> +		 * Initial and sret to re-execute the faulting instruction.
> +		 * Use regs->status (saved at exception entry) rather than
> +		 * reading the live CSR to avoid a TOCTOU race with nested
> +		 * exceptions.
> +		 */
> +		if (v_available && !(regs->status & SR_VS)) {

[Severity: Medium]
Since route_exception() runs in the guest, won't v_available always evaluate
to false without a prior sync_global_to_guest() call?

Could this cause a regression where the lazy enablement check is bypassed,
leading the guest to fail when it encounters an auto-vectorized instruction?

> +			regs->status |= SR_VS_INITIAL;
> +			return;
> +		}
> +	}
> +
>  	if (handlers && handlers->exception_handlers[vector][ec])
>  		return handlers->exception_handlers[vector][ec](regs);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/C286E18DD19A86E7+20260721105736.320687-1-jinrui@haiwei.tech?part=1