linux-kernel - [PATCH] KVM: riscv: Power on secondary vCPUs from migration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250915122334.1351865-1-tjytimi@163.com>
Date: Mon, 15 Sep 2025 20:23:34 +0800
From: Jinyu Tang <tjytimi@....com>
To: Anup Patel <anup@...infault.org>,
	Atish Patra <atish.patra@...ux.dev>,
	Andrew Jones <ajones@...tanamicro.com>,
	Conor Dooley <conor.dooley@...rochip.com>,
	Yong-Xuan Wang <yongxuan.wang@...ive.com>,
	Paul Walmsley <paul.walmsley@...ive.com>,
	Nutty Liu <nutty.liu@...mail.com>,
	Tianshun Sun <stsmail163@....com>
Cc: kvm@...r.kernel.org,
	kvm-riscv@...ts.infradead.org,
	linux-riscv@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	Jinyu Tang <tjytimi@....com>
Subject: [PATCH] KVM: riscv: Power on secondary vCPUs from migration

The current logic keeps all secondary VCPUs powered off on their
first run in kvm_arch_vcpu_postcreate(), relying on the boot VCPU 
to wake them up by sbi call. This is correct for a fresh VM start,
where VCPUs begin execution at the bootaddress (0x80000000).

However, this behavior is not suitable for VCPUs that are being
restored from a state (e.g., during migration resume or snapshot
load). These VCPUs have a saved program counter (sepc). Forcing
them to wait for a wake-up from the boot VCPU, which may not
happen or may happen incorrectly, leaves them in a stuck state
when using Qemu to migration if smp is larger than one.

So check a cold start and a warm resumption by the value of the 
guest's sepc register. If the VCPU is running for the first time 
*and* its sepc is not the hardware boot address, it indicates a 
resumed vCPU that must be powered on immediately to continue 
execution from its saved context.

Signed-off-by: Jinyu Tang <tjytimi@....com>
Tested-by: Tianshun Sun <stsmail163@....com>
---
 arch/riscv/kvm/vcpu.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/kvm/vcpu.c b/arch/riscv/kvm/vcpu.c
index 3ebcfffaa..86aeba886 100644
--- a/arch/riscv/kvm/vcpu.c
+++ b/arch/riscv/kvm/vcpu.c
@@ -867,8 +867,16 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
 	struct kvm_cpu_trap trap;
 	struct kvm_run *run = vcpu->run;

-	if (!vcpu->arch.ran_atleast_once)
+	if (!vcpu->arch.ran_atleast_once) {
 		kvm_riscv_vcpu_setup_config(vcpu);
+		/*
+		 * For VCPUs that are resuming (e.g., from migration)
+		 * and not starting from the boot address, explicitly
+		 * power them on.
+		 */
+		if (vcpu->arch.guest_context.sepc != 0x80000000)
+			kvm_riscv_vcpu_power_on(vcpu);
+	}

 	/* Mark this VCPU ran at least once */
 	vcpu->arch.ran_atleast_once = true;
-- 
2.43.0