From nobody Tue Sep 29 02:37:50 2026 Received: from smtpbguseast3.qq.com (smtpbguseast3.qq.com [54.243.244.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 098FB353EDF; Thu, 13 Aug 2026 09:56:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=54.243.244.52 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786615008; cv=none; b=Oh+coyQqoYtB83LSTHHvP1M1sFE4mA3VTw3ZpsQY09Twl1oPkep6FahuBYVSB3QVfkpkr0BYC3TrbY9bo+qjiIlmtqKI2Yg3CxJBqcdbXcWpkJc9DFaYaAd0AP18gfppv47ZSopPsvt7uZBXXIfeyxEDYnBieZWlFdmj5T4hsPo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786615008; c=relaxed/simple; bh=UIcKos7kRtXCUP0MPnOTjPlCFzvG2NJu8oDkvOG86vM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=n/AQKTbLNwh+5y4BaX3PmQtOqthY1BWF6FyXhT3WvqG/pnQ1x9B55br7rCQZlec+2Uy4iGBrJ4fhNRhXBZBO7NLZxmG9TmP68Zj7uMeWPf/vC9ulvzZFvzm6rxs4zrcTuqt3ph199s+xZdkSO7jp1ICWvKPiDhNDrjDiaQggYGQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=haiwei.tech; spf=pass smtp.mailfrom=haiwei.tech; arc=none smtp.client-ip=54.243.244.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=haiwei.tech Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=haiwei.tech X-QQ-mid: zesmtpgz7t1786614980t0a4c8aa1 X-QQ-Originating-IP: YI18fi8haOXgFIrcSxG0og0EAUmOcw8WGDWMzEE4JSI= Received: from rsl ( [183.242.33.186]) by bizesmtp.qq.com (ESMTP) with id ; Thu, 13 Aug 2026 17:56:17 +0800 (CST) X-QQ-SSF: 0000000000000000000000000000000 X-QQ-GoodBg: 0 X-BIZMAIL-ID: 10837892026488473328 EX-QQ-RecipientCnt: 15 From: JinRui To: anup@brainfault.org, pbonzini@redhat.com, shuah@kernel.org, paul.walmsley@sifive.com, palmer@dabbelt.com, aou@eecs.berkeley.edu Cc: atish.patra@linux.dev, alex@ghiti.fr, sashiko-bot@kernel.org, kvm@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, jinrui@haiwei.tech Subject: [PATCH v12] KVM: selftests: riscv: Add lazy V extension enablement for guests Date: Thu, 13 Aug 2026 09:56:15 +0000 Message-ID: <7C0512E558D1614D+20260813095615.3843757-1-jinrui@haiwei.tech> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-QQ-SENDSIZE: 520 Feedback-ID: zesmtpgz:haiwei.tech:qybglogicsvrgz:qybglogicsvrgz6b-0 X-QQ-XMAILINFO: MiUxkXieYO8R8L0HWg0nLFaiiMKuv3+zyMXLXWzQsu01wqF3s3/E0eGi Xly3oO9llSFooyGv+atUP86DwwOcn8vTbBULIn9oN4kjVRbbdqYSwN0VgNLZllzDByDn9/r 4YDh2kG9ToA1gIqWWUkPqEKJV1PegAp9EghorlUf1ldT2SphZZQlUQ26eOVeQf7sA8UO/N5 UJ9Qq0DvQ9MeeDZ8jB72nKNxbvREuP0PgdFU8gXLLJgzYUqJTJMiMvDpm7nOvjVy1NN+Ug1 aulwfyXyR2921FL+w2xPkEn/UhjkR+cALFi1gFJ9zRNL8cxk8pmSjl68A2i+V8SLI7sWtaY 5TTExmThqT5MAzIs/CSeqnu4tEXlaDOT5x4BMcQFA9ABzN2VhyjqcvRMaJIOAoU8/7+jY/u I33QlByi+QB91FOn6NzYF+ThDTmOr/KZ6xv0aa5jerEvTu4cQT3mFemKVR+FQyP1BpQK5+X sEALXQ1BKyBTIM+q+T5pgVmhT67q/SUIZmWoZXLhPhCYJLQ9chb3jzGikV8NGbuIivcPadP FGYFDFual+4i+CI2V60fMteYqeJFmQ4OK+XO4/MH2rX1CVStFIo0hjcScZblzvBZsCcV7Vs SlvQuiVoiu4E3LmEfmvShDDwXDOGckGRtDOMN/LEHXaTqmkuBcZ/EQKlg5HtIB//KP2iFTg oRsRBEY3f8AkA7fYeaYhC1ujtA/vNX3tyrm/3zAzleUvMxJr4FZmZUK6eykfYcn0wKdXOGC d3UxoM7hyUYn3bF5rWTMnvOY9pk8EfxeohOphVtkfus+jrRugRuHSdMRwR8x3aEGo/QQmPJ bLEb7IGg8OiamzVhTFQkkCr3LWYj/29/C1sueAoXzrjJlrdQ0i3oG+3NtuSRtfpw3AtA//q 0UUgigp3z+Pt2MJ9bNEzJEDRtpBc+VaUMKU2KXyOCl0R16VYjCXqvBlsyEDKigRoopTr+WX MvD0zWz5ElI9pO6waSp1l4pO4fv63srrH7gIE/q73cTT2GJwL4o07Wo5Q0fYkWy6c57AxUx kHxKdexLOq2kWQQSwbEFy0ivyQyggH8wdyt5B5DMpmmb2ekmz5dMYuflrbkBjcCjtHIv3Na A== X-QQ-XMRINFO: NI4Ajvh11aEjEMj13RCX7UuhPEoou2bs1g== X-QQ-RECHKSPAM: 0 Content-Type: text/plain; charset="utf-8" From: jinrui When the cross-compiler defaults to an -march that includes the V (vector) extension, -O2 auto-vectorization generates vector instructions (e.g. vsetvli, vadd.vv) in guest code. Executing such an instruction with sstatus.VS Off raises EXC_INST_ILLEGAL (scause=3D2); KVM's hedeleg forwards it to the guest, but the bare-metal selftest cannot handle it, so all guest tests fail. A real kernel handles this via riscv_v_first_use_handler(), which enables V and re-executes the instruction. Fix it in processor.c: 1. Delete the now-unused guest_unexp_trap() handler, replaced by the full exception vector table. 2. In vm_arch_vcpu_add(), advertise V to KVM via __vcpu_set_reg(V, 1) (best-effort, errors ignored on hardware without V) and install the full exception vector table instead of a raw stvec handler. 3. In route_exception(), decode the faulting instruction (stval) with insn_is_vector() and, when it is a vector instruction while sstatus.VS is Off, set VS to Initial and sret to re-execute it, before any test-registered handler. Genuinely illegal instructions still reach the unexpected-exception path. 4. Make vm_init_vector_tables() idempotent by checking vm->handlers before allocating, so tests that call it directly (ebreak_test, arch_timer, sbi_pmu_test) do not leak memory. Tested on a riscv64 host with KVM enabled. Signed-off-by: jinrui --- Changes in v12: - Read a 16-bit halfword first and only load the full 32-bit instruction when it is not compressed, avoiding an unaligned or cross-page access in the stval fallback (Sashiko review). .../selftests/kvm/include/riscv/processor.h | 13 +++ .../selftests/kvm/lib/riscv/processor.c | 100 +++++++++++++++--- 2 files changed, 100 insertions(+), 13 deletions(-) diff --git a/tools/testing/selftests/kvm/include/riscv/processor.h b/tools/= testing/selftests/kvm/include/riscv/processor.h index e3acf2ae9881..685baefebdb1 100644 --- a/tools/testing/selftests/kvm/include/riscv/processor.h +++ b/tools/testing/selftests/kvm/include/riscv/processor.h @@ -25,6 +25,19 @@ #define GET_RM(insn) (((insn) & INSN_MASK_FUNCT3) >> INSN_SHIFT= _FUNCT3) #define GET_CSR_NUM(insn) (((insn) & INSN_CSR_MASK) >> INSN_CSR_SHIF= T) =20 +/* Vector (V) instruction decoding, matching arch/riscv/include/asm/insn.h= */ +#define RV_INSN_OPCODE_MASK 0x7f +#define RVG_OPCODE_SYSTEM 0x73 +#define RVV_OPCODE_VECTOR 0x57 +#define RVV_OPCODE_VL 0x07 +#define RVV_OPCODE_VS 0x27 +#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_EXTRACT_VL_VS_WIDTH(insn) (((insn) >> 12) & 0x7) +#define RVG_EXTRACT_SYSTEM_CSR(insn) (((insn) >> 20) & 0xfff) + static inline u64 __kvm_reg_id(u64 type, u64 subtype, u64 idx, u64 size) { return KVM_REG_RISCV | type | subtype | idx | size; diff --git a/tools/testing/selftests/kvm/lib/riscv/processor.c b/tools/test= ing/selftests/kvm/lib/riscv/processor.c index ded5429f3448..e677137d5e44 100644 --- a/tools/testing/selftests/kvm/lib/riscv/processor.c +++ b/tools/testing/selftests/kvm/lib/riscv/processor.c @@ -17,6 +17,11 @@ =20 static gva_t exception_handlers; =20 +struct handlers { + exception_handler_fn exception_handlers[NR_VECTORS][NR_EXCEPTIONS]; + bool v_available; +}; + bool __vcpu_has_ext(struct kvm_vcpu *vcpu, u64 ext) { unsigned long value =3D 0; @@ -298,13 +303,6 @@ void vcpu_arch_dump(FILE *stream, struct kvm_vcpu *vcp= u, u8 indent) core.regs.t3, core.regs.t4, core.regs.t5, core.regs.t6); } =20 -static void __aligned(16) guest_unexp_trap(void) -{ - sbi_ecall(KVM_RISCV_SELFTESTS_SBI_EXT, - KVM_RISCV_SELFTESTS_SBI_UNEXP, - 0, 0, 0, 0, 0, 0); -} - void vcpu_arch_set_entry_point(struct kvm_vcpu *vcpu, void *guest_code) { vcpu_set_reg(vcpu, RISCV_CORE_REG(regs.pc), (unsigned long)guest_code); @@ -348,8 +346,26 @@ struct kvm_vcpu *vm_arch_vcpu_add(struct kvm_vm *vm, u= 32 vcpu_id) /* Setup sscratch for guest_get_vcpuid() */ vcpu_set_reg(vcpu, RISCV_GENERAL_CSR_REG(sscratch), vcpu_id); =20 - /* Setup default exception vector of guest */ - vcpu_set_reg(vcpu, RISCV_GENERAL_CSR_REG(stvec), (unsigned long)guest_une= xp_trap); + /* + * Advertise V to KVM so -O2 auto-vectorization in guest code is valid; + * ignore errors since the tests work without V too. Use the full + * exception vector table (which lazily enables V in route_exception()) + * as the default handler; vm_init_vector_tables() is idempotent. + */ + __vcpu_set_reg(vcpu, RISCV_ISA_EXT_REG(KVM_RISCV_ISA_EXT_V), 1); + vm_init_vector_tables(vm); + vcpu_init_vector_tables(vcpu); + + /* + * Record V availability for route_exception(), which runs in guest + * context. V is enabled uniformly for every vCPU, so this is a + * VM-wide property. + */ + { + struct handlers *h =3D addr_gva2hva(vm, vm->handlers); + + h->v_available =3D __vcpu_has_isa_ext(vcpu, KVM_RISCV_ISA_EXT_V); + } =20 return vcpu; } @@ -408,19 +424,43 @@ void assert_on_unhandled_exception(struct kvm_vcpu *v= cpu) struct ucall uc; =20 if (get_ucall(vcpu, &uc) =3D=3D UCALL_UNHANDLED) { + vcpu_dump(stderr, vcpu, 2); TEST_FAIL("Unexpected exception (vector:0x%lx, ec:0x%lx)", uc.args[0], uc.args[1]); } } =20 -struct handlers { - exception_handler_fn exception_handlers[NR_VECTORS][NR_EXCEPTIONS]; -}; +static bool insn_is_vector(u32 insn) +{ + u32 opcode =3D insn & RV_INSN_OPCODE_MASK; + u32 width, csr; + + /* All V-related instructions are 4-byte, i.e. not compressed. */ + if ((insn & 0x3) !=3D 0x3) + return false; + + switch (opcode) { + case RVV_OPCODE_VECTOR: + return true; + case RVV_OPCODE_VL: + case RVV_OPCODE_VS: + width =3D RVV_EXTRACT_VL_VS_WIDTH(insn); + return width =3D=3D RVV_VL_VS_WIDTH_8 || width =3D=3D RVV_VL_VS_WIDTH_16= || + width =3D=3D RVV_VL_VS_WIDTH_32 || width =3D=3D RVV_VL_VS_WIDTH_6= 4; + case RVG_OPCODE_SYSTEM: + csr =3D RVG_EXTRACT_SYSTEM_CSR(insn); + return (csr >=3D CSR_VSTART && csr <=3D CSR_VCSR) || + (csr >=3D CSR_VL && csr <=3D CSR_VLENB); + } + + return false; +} =20 void route_exception(struct pt_regs *regs) { struct handlers *handlers =3D (struct handlers *)exception_handlers; - int vector =3D 0, ec; + int vector =3D 0; + unsigned long ec; =20 ec =3D regs->cause & ~CAUSE_IRQ_FLAG; if (ec >=3D NR_EXCEPTIONS) @@ -432,6 +472,37 @@ void route_exception(struct pt_regs *regs) ec =3D 0; } =20 + /* + * Lazily enable V on the first vector instruction: if the faulting + * instruction decodes as vector while VS is off, set VS to Initial + * and re-execute it, like the kernel's riscv_v_first_use_handler(). + * Genuinely illegal instructions continue to the unexpected-exception + * path. + */ + if (!(regs->cause & CAUSE_IRQ_FLAG) && ec =3D=3D EXC_INST_ILLEGAL && + handlers && handlers->v_available && !(regs->status & SR_VS)) { + u32 insn =3D (u32)regs->badaddr; + + /* + * stval is not guaranteed to hold the faulting instruction. + * Vector instructions are always 32-bit, so read a 16-bit + * halfword first and only load the full 32-bit instruction when + * it is not compressed; this avoids an unaligned or cross-page + * access on a compressed instruction. + */ + if (!insn) { + u16 half =3D *(u16 *)regs->epc; + + if ((half & 0x3) =3D=3D 0x3) + insn =3D *(u32 *)regs->epc; + } + + if (insn_is_vector(insn)) { + regs->status |=3D SR_VS_INITIAL; + return; + } + } + if (handlers && handlers->exception_handlers[vector][ec]) return handlers->exception_handlers[vector][ec](regs); =20 @@ -448,6 +519,9 @@ void vcpu_init_vector_tables(struct kvm_vcpu *vcpu) =20 void vm_init_vector_tables(struct kvm_vm *vm) { + if (vm->handlers) + return; + vm->handlers =3D __vm_alloc(vm, sizeof(struct handlers), vm->page_size, MEM_REGION_DATA); =20 --=20 2.53.0