From nobody Tue Sep 29 06:59:45 2026 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 E69383126D7; Tue, 11 Aug 2026 09:49:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786441762; cv=none; b=oeTCxhb5tLY/CwHvjchFSqaPDQWLlcXhLNWhg/NAm6Tjc5dRGokoz/NfqoAuNH9pccE7mOq/OH0wzjjcWCboyj3k0bg6mX0hYaX2419xqNnevzcUtsFjthcHsIb5CZH6JfKX8rQjucIUtdOulwvaDnxtNRqhIy9nbUlbB3PJCFo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786441762; c=relaxed/simple; bh=YQjZRqd9me+k049knZXJzmBtE9xWMwP42jyAsPl5tR4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=J1sQAskUDwmxjWOZusGJTAOh72aWtnASC8BiDyJ4N8a4cizHDk0KLmdF/+Z13vietyBEON3CB7INfSZ7EavRgRwq6ShJIllr+hteFh2yDqK4ei3gWyLCnb3HFvRS5Re2N6KUVplOx+Ggy6GmQovh+laTvXSaXPVo13ahp9q5okc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=desiato.srs.infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=VtdqW0r3; arc=none smtp.client-ip=90.155.92.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=desiato.srs.infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="VtdqW0r3" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: Reply-To:Content-Type:Content-ID:Content-Description; bh=kpe59k50IQP+BIttRK24gQPQ2oNpO8XFaqOyaurDCoo=; b=VtdqW0r3D7WPZ3Hxc4qGBdKklz oo2cIiHzQRxI1f1wbSHPicSq3g9UT/asElnwcwMuKXywit0NA9D0WaicJ60GWYRTmlIhXlOmFTqhz m5wHTPkZyXxFFqaap5H/9kfdUsK1QNSnRlPfpCfgkL0M/L/oI1KEw+7MP4oQCeczBpjkO5i7fHxNA Zv7bRJyi730AUe6EwHeFDa6x3+FLDOnRZ5CGVfVLgqTJuD/QYTB8AIqGJScTAQWT+sAIjitlMjakr 7dNaei7NgwCl+QE05vFhhJJ4w/5YslFgGrtpkuO+rHtpweHx5jfhm0aglpXWSmKI7oAtkfw5XPu/d YhyXAKGw==; Received: from [2001:8b0:10b:1::425] (helo=i7.infradead.org) by desiato.infradead.org with esmtpsa (Exim 4.99.2 #2 (Red Hat Linux)) id 1wtj62-0000000EU1Q-46LC; Tue, 11 Aug 2026 09:48:39 +0000 Received: from dwoodhou by i7.infradead.org with local (Exim 4.99.4 #2 (Red Hat Linux)) id 1wtj5z-00000000PjA-2UWe; Tue, 11 Aug 2026 10:48:31 +0100 From: David Woodhouse To: seanjc@google.com, pbonzini@redhat.com Cc: dwmw@amazon.co.uk, paul@xen.org, joao.m.martins@oracle.com, boris.ostrovsky@oracle.com, ankur.a.arora@oracle.com, tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, x86@kernel.org, syzbot+208f7f3e5f59c11aeb90@syzkaller.appspotmail.com, syzkaller-bugs@googlegroups.com, suryasaimadhu369@gmail.com, lkp@intel.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 01/11] KVM: x86/xen: Rename 'longmode' to 'is_64bit' in hypercall handling Date: Tue, 11 Aug 2026 10:37:03 +0100 Message-ID: <20260811094829.98794-2-dwmw2@infradead.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260811094829.98794-1-dwmw2@infradead.org> References: <20260811094829.98794-1-dwmw2@infradead.org> 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 Sender: David Woodhouse X-SRS-Rewrite: SMTP reverse-path rewritten from by desiato.infradead.org. See http://www.infradead.org/rpr.html Content-Type: text/plain; charset="utf-8" From: David Woodhouse Rename the local 'longmode' variable and function parameter to 'is_64bit' throughout the Xen hypercall handling code. This distinguishes it from the VM-wide kvm->arch.xen.long_mode which represents the Xen shared_info layout mode. The 'is_64bit' parameter indicates whether the vCPU was in 64-bit mode when it made the hypercall, which determines how to parse the hypercall arguments. The UAPI field name (vcpu->run->xen.u.hcall.longmode) is unchanged. Assisted-by: Kiro:claude-opus-4.6-1m Signed-off-by: David Woodhouse --- arch/x86/kvm/xen.c | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c index f2c6757fc1fa..09f4e154e6b8 100644 --- a/arch/x86/kvm/xen.c +++ b/arch/x86/kvm/xen.c @@ -1469,7 +1469,7 @@ static bool wait_pending_event(struct kvm_vcpu *vcpu,= int nr_ports, return ret; } =20 -static bool kvm_xen_schedop_poll(struct kvm_vcpu *vcpu, bool longmode, +static bool kvm_xen_schedop_poll(struct kvm_vcpu *vcpu, bool is_64bit, u64 param, u64 *r) { struct sched_poll sched_poll; @@ -1481,7 +1481,7 @@ static bool kvm_xen_schedop_poll(struct kvm_vcpu *vcp= u, bool longmode, !(vcpu->kvm->arch.xen.hvm_config.flags & KVM_XEN_HVM_CONFIG_EVTCHN_SE= ND)) return false; =20 - if (IS_ENABLED(CONFIG_64BIT) && !longmode) { + if (IS_ENABLED(CONFIG_64BIT) && !is_64bit) { struct compat_sched_poll sp32; =20 /* Sanity check that the compat struct definition is correct */ @@ -1578,12 +1578,12 @@ static void cancel_evtchn_poll(struct timer_list *t) kvm_vcpu_kick(vcpu); } =20 -static bool kvm_xen_hcall_sched_op(struct kvm_vcpu *vcpu, bool longmode, +static bool kvm_xen_hcall_sched_op(struct kvm_vcpu *vcpu, bool is_64bit, int cmd, u64 param, u64 *r) { switch (cmd) { case SCHEDOP_poll: - if (kvm_xen_schedop_poll(vcpu, longmode, param, r)) + if (kvm_xen_schedop_poll(vcpu, is_64bit, param, r)) return true; fallthrough; case SCHEDOP_yield: @@ -1602,7 +1602,7 @@ struct compat_vcpu_set_singleshot_timer { uint32_t flags; } __attribute__((packed)); =20 -static bool kvm_xen_hcall_vcpu_op(struct kvm_vcpu *vcpu, bool longmode, in= t cmd, +static bool kvm_xen_hcall_vcpu_op(struct kvm_vcpu *vcpu, bool is_64bit, in= t cmd, int vcpu_id, u64 param, u64 *r) { struct vcpu_set_singleshot_timer oneshot; @@ -1646,7 +1646,7 @@ static bool kvm_xen_hcall_vcpu_op(struct kvm_vcpu *vc= pu, bool longmode, int cmd, BUILD_BUG_ON(sizeof_field(struct compat_vcpu_set_singleshot_timer, flags= ) !=3D sizeof_field(struct vcpu_set_singleshot_timer, flags)); =20 - if (kvm_read_guest_virt(vcpu, param, &oneshot, longmode ? sizeof(oneshot= ) : + if (kvm_read_guest_virt(vcpu, param, &oneshot, is_64bit ? sizeof(oneshot= ) : sizeof(struct compat_vcpu_set_singleshot_timer), &e)) { *r =3D -EFAULT; return true; @@ -1678,7 +1678,7 @@ static bool kvm_xen_hcall_set_timer_op(struct kvm_vcp= u *vcpu, uint64_t timeout, =20 int kvm_xen_hypercall(struct kvm_vcpu *vcpu) { - bool longmode; + bool is_64bit; u64 input, params[6], r =3D -ENOSYS; bool handled =3D false; u8 cpl; @@ -1688,8 +1688,8 @@ int kvm_xen_hypercall(struct kvm_vcpu *vcpu) kvm_hv_hypercall_enabled(vcpu)) return kvm_hv_hypercall(vcpu); =20 - longmode =3D is_64_bit_hypercall(vcpu); - if (!longmode) { + is_64bit =3D is_64_bit_hypercall(vcpu); + if (!is_64bit) { input =3D kvm_eax_read(vcpu); params[0] =3D kvm_ebx_read(vcpu); params[1] =3D kvm_ecx_read(vcpu); @@ -1735,17 +1735,17 @@ int kvm_xen_hypercall(struct kvm_vcpu *vcpu) handled =3D kvm_xen_hcall_evtchn_send(vcpu, params[1], &r); break; case __HYPERVISOR_sched_op: - handled =3D kvm_xen_hcall_sched_op(vcpu, longmode, params[0], + handled =3D kvm_xen_hcall_sched_op(vcpu, is_64bit, params[0], params[1], &r); break; case __HYPERVISOR_vcpu_op: - handled =3D kvm_xen_hcall_vcpu_op(vcpu, longmode, params[0], params[1], + handled =3D kvm_xen_hcall_vcpu_op(vcpu, is_64bit, params[0], params[1], params[2], &r); break; case __HYPERVISOR_set_timer_op: { u64 timeout =3D params[0]; /* In 32-bit mode, the 64-bit timeout is in two 32-bit params. */ - if (!longmode) + if (!is_64bit) timeout |=3D params[1] << 32; handled =3D kvm_xen_hcall_set_timer_op(vcpu, timeout, &r); break; @@ -1760,7 +1760,7 @@ int kvm_xen_hypercall(struct kvm_vcpu *vcpu) handle_in_userspace: vcpu->run->exit_reason =3D KVM_EXIT_XEN; vcpu->run->xen.type =3D KVM_EXIT_XEN_HCALL; - vcpu->run->xen.u.hcall.longmode =3D longmode; + vcpu->run->xen.u.hcall.longmode =3D is_64bit; vcpu->run->xen.u.hcall.cpl =3D cpl; vcpu->run->xen.u.hcall.input =3D input; vcpu->run->xen.u.hcall.params[0] =3D params[0]; base-commit: 51ba04112e93ac6e04c627eddcea5caf9cbc0134 --=20 2.55.0 From nobody Tue Sep 29 06:59:45 2026 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 807A53064B5; Tue, 11 Aug 2026 09:49:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786441761; cv=none; b=QQbveUIFEAbz2doIYtFcHEu77KKE1OmAvuNBVrXXLoD0tHr+9wfhANLaotwb5Dvhx3ysPIAG205/KmUneprH8FwlsmBpSHdubDjU6gNr3fYy/iOXdVOIVrg7EgBQjcfrKO3WyDu0aHonblzuULnXLPlSyO2RnWY187T6r9BR0NY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786441761; c=relaxed/simple; bh=7VUAnb14iBTIF+Ysqyj2BqRSlcTsWENHclJ6EItfta8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rSDchcAEhAVp/nNK+2JqimEu5nLoZB4Qy3zbmERv+3n3djcInGF/M3qX1VmmcI9l3vN+e949Y5Jjg7xhbSQJMJ60zfdVaPkfvKjZaa3GJG+j0fjoZc0nQWbSr/+Hi+GL63zHO6JAmCwS11PGQ2eWyvslnSzHSsdFO6qG/fJCi34= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=desiato.srs.infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=TKWm25jn; arc=none smtp.client-ip=90.155.92.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=desiato.srs.infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="TKWm25jn" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: Reply-To:Content-Type:Content-ID:Content-Description; bh=VvAeVDCkhqErRM/44UAbgnJyGOOnbRgF9/Dk2YgsOFo=; b=TKWm25jnTU/cjp5wuuC+okHEwP fxyApPVyKpRs1iAJwtgfiRY/IQwQCXg9V6Eta7hIy9DxK/qRl1FH6MqtsydXwe2krGVdl5pkrr1Pd fwSswBp40OOaxSM5nYeB1JMvUNLT89RzRTH+8jtYKWZ1bOcFMmGLPhGAmd40ykS0OwRiw1+gQ11Wr ujVqq3CJu/tnxAgUFWUu9ytJSy23Wagfve6vPpV9sOG6Jn+5MEZDeb9lv/cO/vOjXDn8TkgFzXxPi RRoUne2qlYHfznZQlz35AB4t34TDCfqLxalyAQHCDW3tb4OS3P9QNSpyOPcZIcEEwVO7X4CBm43MN oiGdWQJQ==; Received: from [2001:8b0:10b:1::425] (helo=i7.infradead.org) by desiato.infradead.org with esmtpsa (Exim 4.99.2 #2 (Red Hat Linux)) id 1wtj62-0000000EU1R-472A; Tue, 11 Aug 2026 09:48:35 +0000 Received: from dwoodhou by i7.infradead.org with local (Exim 4.99.4 #2 (Red Hat Linux)) id 1wtj5z-00000000PjD-2kvL; Tue, 11 Aug 2026 10:48:31 +0100 From: David Woodhouse To: seanjc@google.com, pbonzini@redhat.com Cc: dwmw@amazon.co.uk, paul@xen.org, joao.m.martins@oracle.com, boris.ostrovsky@oracle.com, ankur.a.arora@oracle.com, tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, x86@kernel.org, syzbot+208f7f3e5f59c11aeb90@syzkaller.appspotmail.com, syzkaller-bugs@googlegroups.com, suryasaimadhu369@gmail.com, lkp@intel.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 02/11] KVM: x86/xen: Introduce kvm_xen_has_64bit_shinfo() macro Date: Tue, 11 Aug 2026 10:37:04 +0100 Message-ID: <20260811094829.98794-3-dwmw2@infradead.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260811094829.98794-1-dwmw2@infradead.org> References: <20260811094829.98794-1-dwmw2@infradead.org> 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 Sender: David Woodhouse X-SRS-Rewrite: SMTP reverse-path rewritten from by desiato.infradead.org. See http://www.infradead.org/rpr.html Content-Type: text/plain; charset="utf-8" From: David Woodhouse Add a kvm_xen_has_64bit_shinfo() helper macro to replace the repeated pattern of 'IS_ENABLED(CONFIG_64BIT) && kvm->arch.xen.long_mode' throughout the Xen emulation code. The macro uses READ_ONCE() to ensure a consistent snapshot of the flag, which can be changed by another vCPU at any time. This is the KVM equivalent of Xen's !has_32bit_shinfo(). Assisted-by: Kiro:claude-opus-4.6-1m Signed-off-by: David Woodhouse --- arch/x86/kvm/xen.c | 16 ++++++++-------- arch/x86/kvm/xen.h | 5 +++++ 2 files changed, 13 insertions(+), 8 deletions(-) diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c index 09f4e154e6b8..e234c2a192c3 100644 --- a/arch/x86/kvm/xen.c +++ b/arch/x86/kvm/xen.c @@ -73,7 +73,7 @@ static int kvm_xen_shared_info_init(struct kvm *kvm) BUILD_BUG_ON(offsetof(struct shared_info, wc) !=3D 0xc00); BUILD_BUG_ON(offsetof(struct shared_info, wc_sec_hi) !=3D 0xc0c); =20 - if (IS_ENABLED(CONFIG_64BIT) && kvm->arch.xen.long_mode) { + if (kvm_xen_has_64bit_shinfo(kvm)) { struct shared_info *shinfo =3D gpc->khva; =20 wc_sec_hi =3D &shinfo->wc_sec_hi; @@ -389,7 +389,7 @@ static void kvm_xen_update_runstate_guest(struct kvm_vc= pu *v, bool atomic) BUILD_BUG_ON(sizeof_field(struct vcpu_runstate_info, time) !=3D sizeof(vx->runstate_times)); =20 - if (IS_ENABLED(CONFIG_64BIT) && v->kvm->arch.xen.long_mode) { + if (kvm_xen_has_64bit_shinfo(v->kvm)) { user_len =3D sizeof(struct vcpu_runstate_info); times_ofs =3D offsetof(struct vcpu_runstate_info, state_entry_time); @@ -660,7 +660,7 @@ void kvm_xen_inject_pending_events(struct kvm_vcpu *v) } =20 /* Now gpc->khva is a valid kernel address for the vcpu_info */ - if (IS_ENABLED(CONFIG_64BIT) && v->kvm->arch.xen.long_mode) { + if (kvm_xen_has_64bit_shinfo(v->kvm)) { struct vcpu_info *vi =3D gpc->khva; =20 asm volatile(LOCK_PREFIX "orq %0, %1\n" @@ -977,7 +977,7 @@ int kvm_xen_vcpu_set_attr(struct kvm_vcpu *vcpu, struct= kvm_xen_vcpu_attr *data) * address, that's actually OK. kvm_xen_update_runstate_guest() * will cope. */ - if (IS_ENABLED(CONFIG_64BIT) && vcpu->kvm->arch.xen.long_mode) + if (kvm_xen_has_64bit_shinfo(vcpu->kvm)) sz =3D sizeof(struct vcpu_runstate_info); else sz =3D sizeof(struct compat_vcpu_runstate_info); @@ -1425,7 +1425,7 @@ static int kvm_xen_hypercall_complete_userspace(struc= t kvm_vcpu *vcpu) =20 static inline int max_evtchn_port(struct kvm *kvm) { - if (IS_ENABLED(CONFIG_64BIT) && kvm->arch.xen.long_mode) + if (kvm_xen_has_64bit_shinfo(kvm)) return EVTCHN_2L_NR_CHANNELS; else return COMPAT_EVTCHN_2L_NR_CHANNELS; @@ -1447,7 +1447,7 @@ static bool wait_pending_event(struct kvm_vcpu *vcpu,= int nr_ports, goto out_rcu; =20 ret =3D false; - if (IS_ENABLED(CONFIG_64BIT) && kvm->arch.xen.long_mode) { + if (kvm_xen_has_64bit_shinfo(kvm)) { struct shared_info *shinfo =3D gpc->khva; pending_bits =3D (unsigned long *)&shinfo->evtchn_pending; } else { @@ -1828,7 +1828,7 @@ int kvm_xen_set_evtchn_fast(struct kvm_xen_evtchn *xe= , struct kvm *kvm) if (!kvm_gpc_check(gpc, PAGE_SIZE)) goto out_rcu; =20 - if (IS_ENABLED(CONFIG_64BIT) && kvm->arch.xen.long_mode) { + if (kvm_xen_has_64bit_shinfo(kvm)) { struct shared_info *shinfo =3D gpc->khva; pending_bits =3D (unsigned long *)&shinfo->evtchn_pending; mask_bits =3D (unsigned long *)&shinfo->evtchn_mask; @@ -1869,7 +1869,7 @@ int kvm_xen_set_evtchn_fast(struct kvm_xen_evtchn *xe= , struct kvm *kvm) goto out_rcu; } =20 - if (IS_ENABLED(CONFIG_64BIT) && kvm->arch.xen.long_mode) { + if (kvm_xen_has_64bit_shinfo(kvm)) { struct vcpu_info *vcpu_info =3D gpc->khva; if (!test_and_set_bit(port_word_bit, &vcpu_info->evtchn_pending_sel)) { WRITE_ONCE(vcpu_info->evtchn_upcall_pending, 1); diff --git a/arch/x86/kvm/xen.h b/arch/x86/kvm/xen.h index 59e6128a7bd3..3e8c9306eb89 100644 --- a/arch/x86/kvm/xen.h +++ b/arch/x86/kvm/xen.h @@ -248,6 +248,11 @@ struct compat_shared_info { #define COMPAT_EVTCHN_2L_NR_CHANNELS (8 * \ sizeof_field(struct compat_shared_info, \ evtchn_pending)) + +/* Latched VM-wide mode; the KVM equivalent of Xen's !has_32bit_shinfo(). = */ +#define kvm_xen_has_64bit_shinfo(kvm) \ + (IS_ENABLED(CONFIG_64BIT) && READ_ONCE((kvm)->arch.xen.long_mode)) + struct compat_vcpu_runstate_info { int state; uint64_t state_entry_time; --=20 2.55.0 From nobody Tue Sep 29 06:59:45 2026 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 213EC431491; Tue, 11 Aug 2026 10:49:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786445389; cv=none; b=dbsUyynqx3rPLMpW/1XwlTjINYPJRDd0OD+t+tC2q+8P3SfAE87FDoO6nTHLKrqUEqnKLPM0SI1wwKdSveud98k7cnhmSwHWogJDH/b0B6k7D4+Z0xpnbjf/CyuyhQASBVXYxJ4JLvCCQ11CQInBknc+9S2xjCTPIu1tcMfkCGk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786445389; c=relaxed/simple; bh=kP2CpCyZAD5m6ki/fI5CnOZOP/OLjaGAXSZDUDrZ6a0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tTf7M2mCYjKCsGtzbxk9pymzsE2l8FyefA6E3tS/bjaXqVfy5au11+AI8j1ZcDGSYafPt1VbxHcKDlD/rE8dsufnGhXhW+4jpm0hHQEmjxImgtdUUrbg7FSCSPSqPxtvJxEoaGRdenvexRQOKwFUjTt2j5tEr+Rd3iflqDVK1bA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=casper.srs.infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=s3CYTy/o; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=casper.srs.infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="s3CYTy/o" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Sender:Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: Reply-To:Content-Type:Content-ID:Content-Description; bh=VHPpfZEKhNqpn7dNeV3sq+WTizDuMZH0KaIuUqd3lDE=; b=s3CYTy/oMUAAZB5vH6Qe3q9BNG YyevCv2r63kd8VxWZTYDpzj5OqnwuMGggxxr3jqJfQTOYkT6Gerr4DGfkXZDrzZzrpPxX8Q9eWY2n QZAr1cErAPE3SoLa6DzbVTpzU9b0iZ3IifXyz+6YyCoHwvXEii28VvU4Z4XvTUlq4RIGz7DLPJ3sL TO09Z5UhewmiM+VZ8PncmB+LWDTV1wS5rMwD2lB68+ONQgR32DvJKgDxRTfazLXsZBhEI8+hlmEPq I1+3FhzBL11Gj7Y6lvD0uaF8/v7YdL53rF62S0waItUwx4F1Xsp2NQ1dENX+N0DTD9KD97RzaRgPX 1MmAb57g==; Received: from [2001:8b0:10b:1::425] (helo=i7.infradead.org) by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1wtj60-0000000GFnT-1LYS; Tue, 11 Aug 2026 09:48:42 +0000 Received: from dwoodhou by i7.infradead.org with local (Exim 4.99.4 #2 (Red Hat Linux)) id 1wtj5z-00000000PjG-2vhE; Tue, 11 Aug 2026 10:48:31 +0100 From: David Woodhouse To: seanjc@google.com, pbonzini@redhat.com Cc: dwmw@amazon.co.uk, paul@xen.org, joao.m.martins@oracle.com, boris.ostrovsky@oracle.com, ankur.a.arora@oracle.com, tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, x86@kernel.org, syzbot+208f7f3e5f59c11aeb90@syzkaller.appspotmail.com, syzkaller-bugs@googlegroups.com, suryasaimadhu369@gmail.com, lkp@intel.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 03/11] KVM: x86/xen: Rename max_evtchn_port() to kvm_max_evtchn_port() Date: Tue, 11 Aug 2026 10:37:05 +0100 Message-ID: <20260811094829.98794-4-dwmw2@infradead.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260811094829.98794-1-dwmw2@infradead.org> References: <20260811094829.98794-1-dwmw2@infradead.org> 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 Sender: David Woodhouse X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org. See http://www.infradead.org/rpr.html Content-Type: text/plain; charset="utf-8" From: David Woodhouse Rename in preparation for adding a variant that takes a latched bool argument for use in paths that need a consistent snapshot of the shinfo mode. No functional change. Assisted-by: Kiro:claude-opus-4.6-1m Signed-off-by: David Woodhouse --- arch/x86/kvm/xen.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c index e234c2a192c3..00894afea9be 100644 --- a/arch/x86/kvm/xen.c +++ b/arch/x86/kvm/xen.c @@ -1423,7 +1423,7 @@ static int kvm_xen_hypercall_complete_userspace(struc= t kvm_vcpu *vcpu) return kvm_xen_hypercall_set_result(vcpu, run->xen.u.hcall.result); } =20 -static inline int max_evtchn_port(struct kvm *kvm) +static inline int kvm_max_evtchn_port(struct kvm *kvm) { if (kvm_xen_has_64bit_shinfo(kvm)) return EVTCHN_2L_NR_CHANNELS; @@ -1530,7 +1530,7 @@ static bool kvm_xen_schedop_poll(struct kvm_vcpu *vcp= u, bool is_64bit, } =20 for (i =3D 0; i < sched_poll.nr_ports; i++) { - if (ports[i] >=3D max_evtchn_port(vcpu->kvm)) { + if (ports[i] >=3D kvm_max_evtchn_port(vcpu->kvm)) { *r =3D -EINVAL; goto out; } @@ -1817,7 +1817,7 @@ int kvm_xen_set_evtchn_fast(struct kvm_xen_evtchn *xe= , struct kvm *kvm) WRITE_ONCE(xe->vcpu_idx, vcpu->vcpu_idx); } =20 - if (xe->port >=3D max_evtchn_port(kvm)) + if (xe->port >=3D kvm_max_evtchn_port(kvm)) return -EINVAL; =20 rc =3D -EWOULDBLOCK; @@ -1979,7 +1979,7 @@ int kvm_xen_setup_evtchn(struct kvm *kvm, struct kvm_vcpu *vcpu; =20 /* - * Don't check for the port being within range of max_evtchn_port(). + * Don't check for the port being within range of kvm_max_evtchn_port(). * Userspace can configure what ever targets it likes; events just won't * be delivered if/while the target is invalid, just like userspace can * configure MSIs which target non-existent APICs. @@ -1988,8 +1988,8 @@ int kvm_xen_setup_evtchn(struct kvm *kvm, * can be restored *independently* of other things like creating vCPUs, * without imposing an ordering dependency on userspace. In this * particular case, the problematic ordering would be with setting the - * Xen 'long mode' flag, which changes max_evtchn_port() to allow 4096 - * instead of 1024 event channels. + * Xen 'long mode' flag, which changes kvm_max_evtchn_port() to allow + * 4096 instead of 1024 event channels. */ =20 /* We only support 2 level event channels for now */ @@ -2026,7 +2026,7 @@ int kvm_xen_hvm_evtchn_send(struct kvm *kvm, struct k= vm_irq_routing_xen_evtchn * struct kvm_xen_evtchn e; int ret; =20 - if (!uxe->port || uxe->port >=3D max_evtchn_port(kvm)) + if (!uxe->port || uxe->port >=3D kvm_max_evtchn_port(kvm)) return -EINVAL; =20 /* We only support 2 level event channels for now */ @@ -2136,7 +2136,7 @@ static int kvm_xen_eventfd_assign(struct kvm *kvm, =20 case EVTCHNSTAT_interdomain: if (data->u.evtchn.deliver.port.port) { - if (data->u.evtchn.deliver.port.port >=3D max_evtchn_port(kvm)) + if (data->u.evtchn.deliver.port.port >=3D kvm_max_evtchn_port(kvm)) goto out_noeventfd; /* -EINVAL */ } else { eventfd =3D eventfd_ctx_fdget(data->u.evtchn.deliver.eventfd.fd); @@ -2254,7 +2254,7 @@ static int kvm_xen_setattr_evtchn(struct kvm *kvm, st= ruct kvm_xen_hvm_attr *data if (data->u.evtchn.flags =3D=3D KVM_XEN_EVTCHN_RESET) return kvm_xen_eventfd_reset(kvm); =20 - if (!port || port >=3D max_evtchn_port(kvm)) + if (!port || port >=3D kvm_max_evtchn_port(kvm)) return -EINVAL; =20 if (data->u.evtchn.flags =3D=3D KVM_XEN_EVTCHN_DEASSIGN) --=20 2.55.0 From nobody Tue Sep 29 06:59:45 2026 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 86B3D438FF3; Tue, 11 Aug 2026 10:15:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786443355; cv=none; b=pdAcUQnGbj4m5XS5dAPFOiIbyN5vJ7Nd7XEe3PDVMe6qJAPCtjSl1wror4RwDwMWBWG05afFW4kRtUo9DvwoeKGYvidgrHryHLQU+h1ExBLbWaImjH5CMheM/ob/nrjOsmpR1I4aE034KiWh42VqaUBp2CTLfMBl7u742WB3iiY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786443355; c=relaxed/simple; bh=DGWjPLJhKAHD+YP8/zJi5RapzCJoPLj8jy1KcsBwfEw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=YL00dM8byAfQZjchSJT/GE/pQPaynvSfxFHVOQuPAmcD6IOLObqp1/ZNePdt3gOaZTo2RMh45Qb/xwYQ1vVLN1lNRWioSPikgUkUbTD1YD006tYuI1J2vHO6JQFXPi8n4Q8O3QALrQtf3b7WFJ9atb0S83uagY2i+oCt8E5H/0U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=casper.srs.infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=C+aahvhe; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=casper.srs.infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="C+aahvhe" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc: To:From:Reply-To:Content-ID:Content-Description; bh=wAdCPHnQoZ+4/m9bjBDY7pqq+MSFVECL1AbZ2EiP2MU=; b=C+aahvheYFVHjTu7GEj16sv1ge MSESyGTe4gl30BuNbk14UbHv0jba6BfBLiBzP745iKsaE9j9vhNY6oEh4OUyI4IiVM77/P8ktHkXb RsNdPb2oiHU46hNpqPaX8ZXt6zPeMBvPZwqoryTQGlEuvciH85XJES/e6DTHru4+Cr4kj9QEQ19eE a1DoLyFkiaSuQ9ElpytMHY5pIfOREi4y+9C0sn0Xtb0DsZC3SXFK04FMoknh8NF5FOCq9W5ryRu2h FMcjWjs0nZjgrC3BPrLyLFwftIgiW/c2ribW1BT6C+AdwozFmVZxj/GNjyY6+pg24LAD306htQkdz CpOUeHqg==; Received: from [2001:8b0:10b:1::425] (helo=i7.infradead.org) by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1wtj60-0000000GFnS-1Tir; Tue, 11 Aug 2026 09:48:42 +0000 Received: from dwoodhou by i7.infradead.org with local (Exim 4.99.4 #2 (Red Hat Linux)) id 1wtj5z-00000000PjJ-36AO; Tue, 11 Aug 2026 10:48:31 +0100 From: David Woodhouse To: seanjc@google.com, pbonzini@redhat.com Cc: dwmw@amazon.co.uk, paul@xen.org, joao.m.martins@oracle.com, boris.ostrovsky@oracle.com, ankur.a.arora@oracle.com, tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, x86@kernel.org, syzbot+208f7f3e5f59c11aeb90@syzkaller.appspotmail.com, syzkaller-bugs@googlegroups.com, suryasaimadhu369@gmail.com, lkp@intel.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 04/11] KVM: x86/xen: Latch shinfo mode in kvm_xen_set_evtchn_fast() Date: Tue, 11 Aug 2026 10:37:06 +0100 Message-ID: <20260811094829.98794-5-dwmw2@infradead.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260811094829.98794-1-dwmw2@infradead.org> References: <20260811094829.98794-1-dwmw2@infradead.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Sender: David Woodhouse X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org. See http://www.infradead.org/rpr.html From: Hyunwoo Kim kvm_xen_set_evtchn_fast() assumes the port range check in max_evtchn_port() and the bitmap layout selection observe the same shinfo mode, but each calls kvm_xen_has_64bit_shinfo() separately. If the guest changes the mode in between, a port accepted by the 64-bit range check is handled with the 32-bit layout, and port_word_bit falls outside evtchn_pending_sel. Latch kvm_xen_has_64bit_shinfo() once on entry so the range check and both layout computations use the same value. In practice this is harmless: the evtchn_pending bitmap is at the same offset in both native and compat shared_info layouts, so a stale mode just results in setting a bit in what the guest (in its new compat mode) considers the evtchn_mask, wallclock, or the arch_shared_info fields which follow it =E2=80=94 all of which are in the guest's own page. Even wi= th this fix, the same corruption can occur if 64-bit mode is latched and the guest switches to 32-bit mode immediately afterward. Like Xen, KVM makes no attempt to *convert* when shinfo mode is changed. Only the wallclock field is updated in the new location. This fix is for internal consistency rather than correcting any observable bug. Fixes: 14243b387137 ("KVM: x86/xen: Add KVM_IRQ_ROUTING_XEN_EVTCHN and even= t channel delivery") Reported-by: Hyunwoo Kim Closes: https://lore.kernel.org/all/aiHPPUk5DY7rH-zL@v4bel/ Signed-off-by: Hyunwoo Kim [dwmw2: Rework on top of long_mode/has_64bit_shinfo cleanups] Signed-off-by: David Woodhouse --- arch/x86/kvm/xen.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c index 00894afea9be..9edfdc585337 100644 --- a/arch/x86/kvm/xen.c +++ b/arch/x86/kvm/xen.c @@ -1423,14 +1423,19 @@ static int kvm_xen_hypercall_complete_userspace(str= uct kvm_vcpu *vcpu) return kvm_xen_hypercall_set_result(vcpu, run->xen.u.hcall.result); } =20 -static inline int kvm_max_evtchn_port(struct kvm *kvm) +static inline int max_evtchn_port(bool has_64bit_shinfo) { - if (kvm_xen_has_64bit_shinfo(kvm)) + if (has_64bit_shinfo) return EVTCHN_2L_NR_CHANNELS; else return COMPAT_EVTCHN_2L_NR_CHANNELS; } =20 +static inline int kvm_max_evtchn_port(struct kvm *kvm) +{ + return max_evtchn_port(kvm_xen_has_64bit_shinfo(kvm)); +} + static bool wait_pending_event(struct kvm_vcpu *vcpu, int nr_ports, evtchn_port_t *ports) { @@ -1800,8 +1805,9 @@ static void kvm_xen_check_poller(struct kvm_vcpu *vcp= u, int port) int kvm_xen_set_evtchn_fast(struct kvm_xen_evtchn *xe, struct kvm *kvm) { struct gfn_to_pfn_cache *gpc =3D &kvm->arch.xen.shinfo_cache; - struct kvm_vcpu *vcpu; + bool has_64bit_shinfo =3D kvm_xen_has_64bit_shinfo(kvm); unsigned long *pending_bits, *mask_bits; + struct kvm_vcpu *vcpu; unsigned long flags; int port_word_bit; bool kick_vcpu =3D false; @@ -1817,7 +1823,7 @@ int kvm_xen_set_evtchn_fast(struct kvm_xen_evtchn *xe= , struct kvm *kvm) WRITE_ONCE(xe->vcpu_idx, vcpu->vcpu_idx); } =20 - if (xe->port >=3D kvm_max_evtchn_port(kvm)) + if (xe->port >=3D max_evtchn_port(has_64bit_shinfo)) return -EINVAL; =20 rc =3D -EWOULDBLOCK; @@ -1828,7 +1834,7 @@ int kvm_xen_set_evtchn_fast(struct kvm_xen_evtchn *xe= , struct kvm *kvm) if (!kvm_gpc_check(gpc, PAGE_SIZE)) goto out_rcu; =20 - if (kvm_xen_has_64bit_shinfo(kvm)) { + if (has_64bit_shinfo) { struct shared_info *shinfo =3D gpc->khva; pending_bits =3D (unsigned long *)&shinfo->evtchn_pending; mask_bits =3D (unsigned long *)&shinfo->evtchn_mask; @@ -1869,7 +1875,7 @@ int kvm_xen_set_evtchn_fast(struct kvm_xen_evtchn *xe= , struct kvm *kvm) goto out_rcu; } =20 - if (kvm_xen_has_64bit_shinfo(kvm)) { + if (has_64bit_shinfo) { struct vcpu_info *vcpu_info =3D gpc->khva; if (!test_and_set_bit(port_word_bit, &vcpu_info->evtchn_pending_sel)) { WRITE_ONCE(vcpu_info->evtchn_upcall_pending, 1); --=20 2.55.0 From nobody Tue Sep 29 06:59:45 2026 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 500F443CED2; Tue, 11 Aug 2026 10:50:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786445407; cv=none; b=UE4AwhShA55DPvtV5vbMnPXNyhqcXxEIweDzA8ToyA5X0VAScIywviK7kCCOWp14E/w7/YRicSKV9xXYxz/YPCFzYm/MQvn89HQMacypxBOnUL8VJmusHR6IeUgsfttM9qVPQFqDC37BxZf723mqSUVwyvbQIGAm6YylUXXbH1w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786445407; c=relaxed/simple; bh=gWgiawnQhvZW4FThCZKdr1cLrYD9u3vLWQKotfB1p0U=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ca40n4+l06sI9hOHxSFiUWABUHr+uAyHCtQWv010/NgI8+nL2+6dvAwRoMeCfJYfMTEsbVIYiE8PSWKyIYhlqeVOX8yHR49pIM1wii/3w2QmvmzaxJhRzlSmi9Fmi6OG7cJwA8NBUOgff2SxU2EfBs8W6NEP8aHp/SBJ7ViYo1E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=casper.srs.infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=evxAVjhz; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=casper.srs.infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="evxAVjhz" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Sender:Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: Reply-To:Content-Type:Content-ID:Content-Description; bh=pyEs/Jnqe1H9I/J/i4iGoSnt+geI+86GQFWBwGlivrE=; b=evxAVjhzs7iFz/n9q9EaNxJ4S2 Rq0DccOXTTP/yf2jBRMHxX1HXjeT711NBzZHcV6G356n47OxrdZiIp55b5wbqEdSbOGMLfTsn2AnC BbPuCk7loHV/nP++FYHXd4hBxCDyoPk7465TKSb5kMgCpX8A7jtsZz/DjETGoZnYIBF4hD3mEEa7n eQnrV/d1gHRigM0cS4YM+5XDNQwfvyBibwznDkn8IKKcIItq/9lTr8qk8zuDyJ+8qqWAUlyhEWuL9 o9/jAfkvZ0vaVBcfVRAFhBcsZdKl1iI6BNgIFOrEHpcn9BL8CebKxxEnINRiXCuZiOC9usHnYqyuL P/TQtuBg==; Received: from [2001:8b0:10b:1::425] (helo=i7.infradead.org) by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1wtj60-0000000GFnV-1SlO; Tue, 11 Aug 2026 09:48:41 +0000 Received: from dwoodhou by i7.infradead.org with local (Exim 4.99.4 #2 (Red Hat Linux)) id 1wtj5z-00000000PjM-3GOW; Tue, 11 Aug 2026 10:48:31 +0100 From: David Woodhouse To: seanjc@google.com, pbonzini@redhat.com Cc: dwmw@amazon.co.uk, paul@xen.org, joao.m.martins@oracle.com, boris.ostrovsky@oracle.com, ankur.a.arora@oracle.com, tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, x86@kernel.org, syzbot+208f7f3e5f59c11aeb90@syzkaller.appspotmail.com, syzkaller-bugs@googlegroups.com, suryasaimadhu369@gmail.com, lkp@intel.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 05/11] KVM: x86/xen: Latch shinfo mode in kvm_xen_schedop_poll() Date: Tue, 11 Aug 2026 10:37:07 +0100 Message-ID: <20260811094829.98794-6-dwmw2@infradead.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260811094829.98794-1-dwmw2@infradead.org> References: <20260811094829.98794-1-dwmw2@infradead.org> 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 Sender: David Woodhouse X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org. See http://www.infradead.org/rpr.html Content-Type: text/plain; charset="utf-8" From: David Woodhouse kvm_xen_schedop_poll() validates port numbers against kvm_max_evtchn_port() and then calls wait_pending_event() which reads the shinfo mode again to select the bitmap layout. Latch kvm_xen_has_64bit_shinfo() once and pass it to both max_evtchn_port() and wait_pending_event(). As with the previous fix to kvm_xen_set_evtchn_fast(), this is harmless in practice for the same reasons: the inconsistency can only corrupt fields in the guest's own shared_info page, and the same corruption can occur anyway if the mode changes immediately after the latch. Fixes: d518b9d0fc80 ("KVM: x86/xen: handle PV spinlocks slowpath") Assisted-by: Kiro:claude-opus-4.6-1m Signed-off-by: David Woodhouse --- arch/x86/kvm/xen.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c index 9edfdc585337..e249a1b1d446 100644 --- a/arch/x86/kvm/xen.c +++ b/arch/x86/kvm/xen.c @@ -1436,8 +1436,8 @@ static inline int kvm_max_evtchn_port(struct kvm *kvm) return max_evtchn_port(kvm_xen_has_64bit_shinfo(kvm)); } =20 -static bool wait_pending_event(struct kvm_vcpu *vcpu, int nr_ports, - evtchn_port_t *ports) +static bool wait_pending_event(struct kvm_vcpu *vcpu, bool has_64bit_shinf= o, + int nr_ports, evtchn_port_t *ports) { struct kvm *kvm =3D vcpu->kvm; struct gfn_to_pfn_cache *gpc =3D &kvm->arch.xen.shinfo_cache; @@ -1452,7 +1452,7 @@ static bool wait_pending_event(struct kvm_vcpu *vcpu,= int nr_ports, goto out_rcu; =20 ret =3D false; - if (kvm_xen_has_64bit_shinfo(kvm)) { + if (has_64bit_shinfo) { struct shared_info *shinfo =3D gpc->khva; pending_bits =3D (unsigned long *)&shinfo->evtchn_pending; } else { @@ -1477,6 +1477,7 @@ static bool wait_pending_event(struct kvm_vcpu *vcpu,= int nr_ports, static bool kvm_xen_schedop_poll(struct kvm_vcpu *vcpu, bool is_64bit, u64 param, u64 *r) { + bool has_64bit_shinfo =3D kvm_xen_has_64bit_shinfo(vcpu->kvm); struct sched_poll sched_poll; evtchn_port_t port, *ports; struct x86_exception e; @@ -1535,7 +1536,7 @@ static bool kvm_xen_schedop_poll(struct kvm_vcpu *vcp= u, bool is_64bit, } =20 for (i =3D 0; i < sched_poll.nr_ports; i++) { - if (ports[i] >=3D kvm_max_evtchn_port(vcpu->kvm)) { + if (ports[i] >=3D max_evtchn_port(has_64bit_shinfo)) { *r =3D -EINVAL; goto out; } @@ -1548,7 +1549,7 @@ static bool kvm_xen_schedop_poll(struct kvm_vcpu *vcp= u, bool is_64bit, =20 set_bit(vcpu->vcpu_idx, vcpu->kvm->arch.xen.poll_mask); =20 - if (!wait_pending_event(vcpu, sched_poll.nr_ports, ports)) { + if (!wait_pending_event(vcpu, has_64bit_shinfo, sched_poll.nr_ports, port= s)) { kvm_set_mp_state(vcpu, KVM_MP_STATE_HALTED); =20 if (sched_poll.timeout) --=20 2.55.0 From nobody Tue Sep 29 06:59:45 2026 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 1BBF743C7DA; Tue, 11 Aug 2026 10:49:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786445400; cv=none; b=UwI85Henz8ComkAQhVHZg3S/igV9Kur/zYN3uHoYUpoq7azKovJmTh3KzLwoUV2MpMalj7dujPGrJazhPXuA+8my83K752+A7vzadu3s0tFUHSn0A2sKpUud8PD8H/eEITcGXdUn7HTsXG+nPhAEwLfc7NY3GMTQKqrYBCYmqnY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786445400; c=relaxed/simple; bh=Pi0W17fIcQc03562r9z7BMmW5ptnYH9r6LIb/KkLqog=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=D3ofgF2MsCebd5cHvm+EnTj69ZRdVADDFp0K5SDu+cZSLc8XVK3kDTQ9pMWZ8WrAEdlcJKwyE0h4f2BhqVPDl0/dOLAv/roOCXmNBi52tlFfBStbbAr8GrpANghZ7kMg9INpGk7dHhEswxfvzUXS2RGUNx0bI6J5Hrcj5jhW0hg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=casper.srs.infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=CHi3+Jpt; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=casper.srs.infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="CHi3+Jpt" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Sender:Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: Reply-To:Content-Type:Content-ID:Content-Description; bh=DVYednfLFKi3uVt28HHfqbxXLz1OLp0vitlIQe57Nb4=; b=CHi3+JptfPcViUZjAORoO8N5NV JnJLMWWad4eUYVxiOjJi5O/tcTIrPzKAAzDoMTh1ACNGDR8/Ge4u/fi/bf3xg777Swx0Dy26eo1NH ZMUoteeZnmuuc48q1gbZZ2JrN+L0KjfixI8OLkRFwp2U7YN3CbBfxu34NZ81YkFTjCCqXnq8J408p B9PoksRvVThFq/fnxOqweesmog8mCDrLJmPCJ1DmJ8xRKiZv+UTquVQQBg+0yiuz91koDvH5r+CQ1 /+B3tCIs0AW0YvrkvPrgjul0BSv9YZLY41DYXw7d70ySp/OIKlbFT0thiFOZp8oW7zeaFZvisfZLU JqulrYMQ==; Received: from [2001:8b0:10b:1::425] (helo=i7.infradead.org) by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1wtj60-0000000GFnU-1Rhd; Tue, 11 Aug 2026 09:48:42 +0000 Received: from dwoodhou by i7.infradead.org with local (Exim 4.99.4 #2 (Red Hat Linux)) id 1wtj5z-00000000PjP-3Qbi; Tue, 11 Aug 2026 10:48:31 +0100 From: David Woodhouse To: seanjc@google.com, pbonzini@redhat.com Cc: dwmw@amazon.co.uk, paul@xen.org, joao.m.martins@oracle.com, boris.ostrovsky@oracle.com, ankur.a.arora@oracle.com, tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, x86@kernel.org, syzbot+208f7f3e5f59c11aeb90@syzkaller.appspotmail.com, syzkaller-bugs@googlegroups.com, suryasaimadhu369@gmail.com, lkp@intel.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 06/11] KVM: x86/xen: Enforce 4-byte alignment of vcpu_info registration Date: Tue, 11 Aug 2026 10:37:08 +0100 Message-ID: <20260811094829.98794-7-dwmw2@infradead.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260811094829.98794-1-dwmw2@infradead.org> References: <20260811094829.98794-1-dwmw2@infradead.org> 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 Sender: David Woodhouse X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org. See http://www.infradead.org/rpr.html Content-Type: text/plain; charset="utf-8" From: David Woodhouse Xen's map_guest_area() enforces that vcpu_info is aligned to sizeof(xen_ulong_t). KVM has no such check, allowing a guest to register vcpu_info at an arbitrary byte alignment. Enforce unconditional 4-byte alignment regardless of the current shinfo mode. This is sufficient because subsequent commits ensure that all locked atomic operations on vcpu_info fields use at most 32-bit accesses. Return -ENXIO on failure, matching Xen's map_guest_area() behaviour for unaligned requests. Originally observed in review of an unrelated patch: https://lore.kernel.org/all/20260604193554.1BA311F00893@smtp.kernel.org/ Cc: stable@vger.kernel.org Fixes: 73e69a86347a ("KVM: x86/xen: register vcpu info") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/all/20260604193554.1BA311F00893@smtp.kernel= .org Assisted-by: Kiro:claude-opus-4.6-1m Signed-off-by: David Woodhouse --- arch/x86/kvm/xen.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c index e249a1b1d446..959d79eef0ce 100644 --- a/arch/x86/kvm/xen.c +++ b/arch/x86/kvm/xen.c @@ -925,6 +925,10 @@ int kvm_xen_vcpu_set_attr(struct kvm_vcpu *vcpu, struc= t kvm_xen_vcpu_attr *data) break; } =20 + r =3D -ENXIO; + if (!IS_ALIGNED(data->u.gpa, sizeof(u32))) + break; + r =3D kvm_gpc_activate(&vcpu->arch.xen.vcpu_info_cache, data->u.gpa, sizeof(struct vcpu_info)); } else { @@ -934,6 +938,10 @@ int kvm_xen_vcpu_set_attr(struct kvm_vcpu *vcpu, struc= t kvm_xen_vcpu_attr *data) break; } =20 + r =3D -ENXIO; + if (!IS_ALIGNED(data->u.hva, sizeof(u32))) + break; + r =3D kvm_gpc_activate_hva(&vcpu->arch.xen.vcpu_info_cache, data->u.hva, sizeof(struct vcpu_info)); } --=20 2.55.0 From nobody Tue Sep 29 06:59:45 2026 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 21C8043C7AF; Tue, 11 Aug 2026 10:49:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786445394; cv=none; b=UQixLVHRuIQmIu/d7WE2Oru6InHbDVWyvFvIGndRt5By2xWWSxVmYojbnw7k6HvVSIizi2JFUHuV+PwfutQltuANf749z+yv7tcU3sX0KHAOhgV3Cf/jCz8E3pou2lKZpHeVnNTgT+YSi89/YFBRntwbuaBOdGhIhvz/xhVZUyg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786445394; c=relaxed/simple; bh=zNx/aPeeZXaFykth++2z0CyLQZNAxDNzR9EDXDIYP3c=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=L9Ii+/1oBWJ+qeOf6ASMi/ML1e+1Iczk2ZVCyp2MPR/2iQxPWAC6o9c9LqYP8TfO21z40BpIyGfj5mPIb3BV1yD1RsrNdoegyxtjOgnjbOgTB3G9jFGW6Biqf4IkGb0lMhdrrQfMScyg7jalfRykCPKWYok79PbdD6wgjjK+3HY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=casper.srs.infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=KGjixxVe; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=casper.srs.infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="KGjixxVe" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Sender:Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: Reply-To:Content-Type:Content-ID:Content-Description; bh=cFOix9MEHzEkHL6OuSiUhv0LJF9jrpcWzI6x+Cu6k5w=; b=KGjixxVeU0LwoKhoerTjXMFvis SGQEEF8qjgHBlMQoIViBtJNCqqf+Pk+KgH1vt5o8qdpV9XCWXB0YdZud8EsgYj5e6jZrx/scb5ubj Smm/qOAGvgfos3flDPiHfyipYCB2Ok8cFZObOkqO5/3VUGVhmaZLsdFF5vziROLSbRNB8zAcqEsLr wkjR1zFBs1L2vudTdsPYN9AbEPtY1sGnBOcFG6X8CmlRRByB8iy0oIHOAKhVQ7hIcpr6pTmI6XFPe TF9+lWPDYZUjXPGCFckaiYz2mwOGdfKIDJ/FH3GQJoDkrOllEJetSSmkrXZnv+19v0celP8Mxj/Ju xgZKtMGw==; Received: from [2001:8b0:10b:1::425] (helo=i7.infradead.org) by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1wtj60-0000000GFnZ-1Szg; Tue, 11 Aug 2026 09:48:41 +0000 Received: from dwoodhou by i7.infradead.org with local (Exim 4.99.4 #2 (Red Hat Linux)) id 1wtj5z-00000000PjS-3gDp; Tue, 11 Aug 2026 10:48:31 +0100 From: David Woodhouse To: seanjc@google.com, pbonzini@redhat.com Cc: dwmw@amazon.co.uk, paul@xen.org, joao.m.martins@oracle.com, boris.ostrovsky@oracle.com, ankur.a.arora@oracle.com, tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, x86@kernel.org, syzbot+208f7f3e5f59c11aeb90@syzkaller.appspotmail.com, syzkaller-bugs@googlegroups.com, suryasaimadhu369@gmail.com, lkp@intel.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 07/11] KVM: x86/xen: Use 32-bit locked bts for vcpu_info evtchn_pending_sel Date: Tue, 11 Aug 2026 10:37:09 +0100 Message-ID: <20260811094829.98794-8-dwmw2@infradead.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260811094829.98794-1-dwmw2@infradead.org> References: <20260811094829.98794-1-dwmw2@infradead.org> 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 Sender: David Woodhouse X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org. See http://www.infradead.org/rpr.html Content-Type: text/plain; charset="utf-8" From: David Woodhouse Replace test_and_set_bit() on vcpu_info->evtchn_pending_sel with an explicit 'lock btsl' in kvm_xen_set_evtchn_fast(). The generic test_and_set_bit() uses a 64-bit locked operation ('lock btsq') on x86-64, and the address of the per-vCPU info is guest-controlled and only required to be 32-bit aligned, so an 8-byte access can generate a split-lock #AC exception. Since evtchn_pending_sel is at most 64 bits wide and port_word_bit ranges 0-63, a 32-bit 'lock btsl' suffices for both native and compat vcpu_info layouts, and only requires the 4-byte alignment that is already guaranteed by the registration path. This also eliminates the bogus cast of compat_vcpu_info's 32-bit evtchn_pending_sel to 'unsigned long *' which was the original source of the split-lock hazard. Note, KVM reuses the local gpc. The atomic accesses to pending_bits is on the page-aligned per-VM shared_info structure, i.e. doesn't need the same treatment as the access is guaranteed to be 64-bit aligned. Fixes: 14243b387137 ("KVM: x86/xen: Add KVM_IRQ_ROUTING_XEN_EVTCHN and even= t channel delivery") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/all/20260604193554.1BA311F00893@smtp.kernel= .org Suggested-by: Sean Christopherson Signed-off-by: David Woodhouse Assisted-by: Claude:claude-mythos-5 --- arch/x86/kvm/xen.c | 47 ++++++++++++++++++++++++++++++++-------------- 1 file changed, 33 insertions(+), 14 deletions(-) diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c index 959d79eef0ce..c935651906ec 100644 --- a/arch/x86/kvm/xen.c +++ b/arch/x86/kvm/xen.c @@ -1815,7 +1815,7 @@ int kvm_xen_set_evtchn_fast(struct kvm_xen_evtchn *xe= , struct kvm *kvm) { struct gfn_to_pfn_cache *gpc =3D &kvm->arch.xen.shinfo_cache; bool has_64bit_shinfo =3D kvm_xen_has_64bit_shinfo(kvm); - unsigned long *pending_bits, *mask_bits; + unsigned long *pending_bits, *mask_bits, vi_pending_sel_ofs; struct kvm_vcpu *vcpu; unsigned long flags; int port_word_bit; @@ -1848,11 +1848,18 @@ int kvm_xen_set_evtchn_fast(struct kvm_xen_evtchn *= xe, struct kvm *kvm) pending_bits =3D (unsigned long *)&shinfo->evtchn_pending; mask_bits =3D (unsigned long *)&shinfo->evtchn_mask; port_word_bit =3D xe->port / 64; + + vi_pending_sel_ofs =3D offsetof(struct vcpu_info, evtchn_pending_sel); } else { struct compat_shared_info *shinfo =3D gpc->khva; pending_bits =3D (unsigned long *)&shinfo->evtchn_pending; mask_bits =3D (unsigned long *)&shinfo->evtchn_mask; port_word_bit =3D xe->port / 32; + + vi_pending_sel_ofs =3D offsetof(struct compat_vcpu_info, evtchn_pending_= sel); + + /* test_and_set_bit() needs 64-bit alignment, but that's OK */ + BUILD_BUG_ON(offsetof(struct compat_shared_info, evtchn_pending) & 7); } =20 /* @@ -1868,6 +1875,8 @@ int kvm_xen_set_evtchn_fast(struct kvm_xen_evtchn *xe= , struct kvm *kvm) rc =3D -ENOTCONN; /* Masked */ kvm_xen_check_poller(vcpu, xe->port); } else { + bool old; + rc =3D 1; /* Delivered to the bitmap in shared_info. */ /* Now switch to the vCPU's vcpu_info to set the index and pending_sel */ read_unlock_irqrestore(&gpc->lock, flags); @@ -1884,19 +1893,29 @@ int kvm_xen_set_evtchn_fast(struct kvm_xen_evtchn *= xe, struct kvm *kvm) goto out_rcu; } =20 - if (has_64bit_shinfo) { - struct vcpu_info *vcpu_info =3D gpc->khva; - if (!test_and_set_bit(port_word_bit, &vcpu_info->evtchn_pending_sel)) { - WRITE_ONCE(vcpu_info->evtchn_upcall_pending, 1); - kick_vcpu =3D true; - } - } else { - struct compat_vcpu_info *vcpu_info =3D gpc->khva; - if (!test_and_set_bit(port_word_bit, - (unsigned long *)&vcpu_info->evtchn_pending_sel)) { - WRITE_ONCE(vcpu_info->evtchn_upcall_pending, 1); - kick_vcpu =3D true; - } + /* + * Explicitly use a 32-bit btsl instead of test_and_set_bit(), + * which would use btsq on x86-64. The vcpu_info is guest- + * controlled and only required to be 32-bit aligned, so a + * 64-bit access could generate a split-lock #AC. + * + * Note, this does not apply to the test_and_set_bit() on + * pending_bits above: that is in the per-VM shared_info, which + * is page aligned, so the access is guaranteed to be 64-bit + * aligned. + */ + old =3D GEN_BINARY_RMWcc(LOCK_PREFIX "btsl", + *(u32 *)(gpc->khva + vi_pending_sel_ofs), + c, "Ir", port_word_bit); + if (!old) { + struct vcpu_info *vi =3D gpc->khva; + + /* No need for compat handling */ + BUILD_BUG_ON(offsetof(struct vcpu_info, evtchn_upcall_pending) !=3D + offsetof(struct compat_vcpu_info, evtchn_upcall_pending)); + + WRITE_ONCE(vi->evtchn_upcall_pending, 1); + kick_vcpu =3D true; } =20 /* For the per-vCPU lapic vector, deliver it as MSI. */ --=20 2.55.0 From nobody Tue Sep 29 06:59:45 2026 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 E6A8941F349; Tue, 11 Aug 2026 09:49:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786441762; cv=none; b=tBzNs6Yd/fS+D8ITn4p+GqvzAhg9UzGC8dROivt0+3sAtd0ZAxGBN+f0kROncBqc1/o+99yXwP8/EBjIYSR0RWYKyao+9ZfWqYm/yvxtonJI9Dej//sHn7aBTAsWadx/AebDULo/RqqFADfMxQ/sV1OmV/QA+Kyb2dCm6tYiMmM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786441762; c=relaxed/simple; bh=uq1DNqYomQFdT1BWaGwFYLT/qILzlomnOSXCpumGnAU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=h3XK0Me/WyE984JI2zOCWC4hJXzcJk4Yz9UOG3oQF3yrQQW9QLL4lX77AXDqScEbmY15zglEBQWkWq4i+mnjFV4965/cY0sGrEqKS70sRVcaYxzwUQ+H3XBNffqa4l584WA7pQ0kcwxqEJprIw9E371OAApLzEIwg7PVZnCa6y4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=desiato.srs.infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=ovoen+Dl; arc=none smtp.client-ip=90.155.92.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=desiato.srs.infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="ovoen+Dl" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: Reply-To:Content-Type:Content-ID:Content-Description; bh=HkHpKY1j5MQrV8meOqWYb07EFaYUTTeiKv1xcOb7w90=; b=ovoen+Dliggi4EszTLf97NjiRT RjwuvdCPffjUZAD4oakIwVnd8zvxtsU28HwizWXNDbjorVKX5T7WB/0hSwsNXV+hmXuzA4UCUY6jc kSxdaHiCljAQWqCaYAxwAeku1aDwoIGesmtkgbM9Fe9maQVXYJZfjdkuN6CsxWTs4gCw8nsG1NmwC +R68JS2c1glKbHJ4QT2YK173RUWbUdJ5ufTjKVDGHwXWJM8IsvPeZYwAbLba0wpRgDEvBpi+jJmmP iM42yYweDIfvEk132Dcec5qQIdFjP6JUWWFF+xvcaMTwiSUw7Ix8GYvHUNeI959otuSaCppCZzP3H Sg1khRGQ==; Received: from [2001:8b0:10b:1::425] (helo=i7.infradead.org) by desiato.infradead.org with esmtpsa (Exim 4.99.2 #2 (Red Hat Linux)) id 1wtj62-0000000EU1S-46H3; Tue, 11 Aug 2026 09:48:35 +0000 Received: from dwoodhou by i7.infradead.org with local (Exim 4.99.4 #2 (Red Hat Linux)) id 1wtj5z-00000000PjV-3qNk; Tue, 11 Aug 2026 10:48:31 +0100 From: David Woodhouse To: seanjc@google.com, pbonzini@redhat.com Cc: dwmw@amazon.co.uk, paul@xen.org, joao.m.martins@oracle.com, boris.ostrovsky@oracle.com, ankur.a.arora@oracle.com, tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, x86@kernel.org, syzbot+208f7f3e5f59c11aeb90@syzkaller.appspotmail.com, syzkaller-bugs@googlegroups.com, suryasaimadhu369@gmail.com, lkp@intel.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 08/11] KVM: x86/xen: Use 32-bit atomics if vCPU's evtchn_pending_sel isn't aligned Date: Tue, 11 Aug 2026 10:37:10 +0100 Message-ID: <20260811094829.98794-9-dwmw2@infradead.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260811094829.98794-1-dwmw2@infradead.org> References: <20260811094829.98794-1-dwmw2@infradead.org> 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 Sender: David Woodhouse X-SRS-Rewrite: SMTP reverse-path rewritten from by desiato.infradead.org. See http://www.infradead.org/rpr.html Content-Type: text/plain; charset="utf-8" From: Sean Christopherson When propagating pending Xen events from KVM's "cache" to the guest-visible structure, use two 32-bit atomic operations to do the bitwise-OR into the guest-controlled structure if the structure isn't 64-bit aligned, i.e. if the guest registered its vcpu_info in 32-bit mode and then switched to 64-bit mode, in which case using a 64-bit atomic OR will generate a split-lock #AC (if enabled). Opportunistically isolate the clearing of the bits from KVM's cache, as that structure is KVM-controlled, i.e. is guaranteed to be 64-bit aligned. This will allow dropping the open-coded inline asm blobs in the future. [dwmw2: Cast to u64 before shifting; evtchn_pending_sel is unsigned long, so >> 32 is undefined on 32-bit even though the branch is unreachable there] Fixes: 14243b387137 ("KVM: x86/xen: Add KVM_IRQ_ROUTING_XEN_EVTCHN and even= t channel delivery") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/all/20260604193554.1BA311F00893@smtp.kernel= .org Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202608071502.rYOi3Pg8-lkp@int= el.com/ Signed-off-by: Sean Christopherson Signed-off-by: David Woodhouse --- arch/x86/kvm/xen.c | 29 ++++++++++++++++++++++------- 1 file changed, 22 insertions(+), 7 deletions(-) diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c index c935651906ec..419b07fdaa3a 100644 --- a/arch/x86/kvm/xen.c +++ b/arch/x86/kvm/xen.c @@ -663,13 +663,28 @@ void kvm_xen_inject_pending_events(struct kvm_vcpu *v) if (kvm_xen_has_64bit_shinfo(v->kvm)) { struct vcpu_info *vi =3D gpc->khva; =20 - asm volatile(LOCK_PREFIX "orq %0, %1\n" - "notq %0\n" - LOCK_PREFIX "andq %0, %2\n" - : "=3Dr" (evtchn_pending_sel), - "+m" (vi->evtchn_pending_sel), - "+m" (v->arch.xen.evtchn_pending_sel) - : "0" (evtchn_pending_sel)); + if (IS_ALIGNED((unsigned long)&vi->evtchn_pending_sel, sizeof(u64))) + asm volatile(LOCK_PREFIX "orq %[src], %[dst]\n" + : [dst] "+m" (vi->evtchn_pending_sel) + : [src] "r" (evtchn_pending_sel)); + else + /* + * The cast keeps the shift well-defined on 32-bit, + * where evtchn_pending_sel is 32 bits wide and this + * branch is unreachable anyway (this is inside + * kvm_xen_has_64bit_shinfo(), which is gated on + * IS_ENABLED(CONFIG_64BIT)). + */ + asm volatile(LOCK_PREFIX "orl %[src_lo], %[dst_lo]\n" + LOCK_PREFIX "orl %[src_hi], %[dst_hi]\n" + : [dst_lo] "+m" (vi->evtchn_pending_sel), + [dst_hi] "+m" (*(((u32 *)&vi->evtchn_pending_sel) + 1)) + : [src_lo] "r" ((u32)evtchn_pending_sel), + [src_hi] "r" ((u32)((u64)evtchn_pending_sel >> 32))); + + asm volatile(LOCK_PREFIX "andq %1, %0\n" + : "+m" (v->arch.xen.evtchn_pending_sel) + : "r" (~evtchn_pending_sel)); WRITE_ONCE(vi->evtchn_upcall_pending, 1); } else { u32 evtchn_pending_sel32 =3D evtchn_pending_sel; --=20 2.55.0 From nobody Tue Sep 29 06:59:45 2026 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 D9B4D3B6346; Tue, 11 Aug 2026 10:49:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786445366; cv=none; b=Q7PZJeEruTLxlcj6icPm+aGGVwqHo3iMzwTGfikQCLTwmFTLWbxWX9aV7IDF6rYOSjBi8PqOCA/V2WhmRaovtgfiJVyhQFyJ+nsUWI2V3UF1G90Vm6BAv9uA5YwqkZkQXMEVr6QoPdeBHlY713P0dnBYrwlXorPXaAn3UPl0UDU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786445366; c=relaxed/simple; bh=evDEYwD58eyvKVLHqE1JJJ6/5uvAVj1N5ZGj6tckCa8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=pWzXtl69HZZrMwwyNpMAr3RJgRuOAOsMLv7cDlRMyMS1QARrAaZ0sKzBGuh66cNfr4AShWNZEwvNLSBSqJQB6DKToCmyNci+tmxSctzXTBIGvanQwZB78eSt2sYb5hoHe1IyZHX3rz/Jt2qeF0tAk2Pqwk1M02a4hHjbqPuMGEA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=casper.srs.infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=sot7r9LV; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=casper.srs.infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="sot7r9LV" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Sender:Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: Reply-To:Content-Type:Content-ID:Content-Description; bh=Na/xhM+hWzJxsY5YVXVAzR7+i+b3B1RRwiuknTe5IXU=; b=sot7r9LV02XVQeTQ2XoyCbNBUT QIKxk6rsCmbMnbzlTZI6OVd9vvzthHMEeRhWD6RSlRr3riblYr6nl47/At9Ql2oT/oAaHfVXCJJAf BrQyGUy7+036CC0yOio/vHPn3Zx2xyE1IcGp9bjTTmu93W0iU8uxlYXti6Bvc2qmGd9vCmrLlt4w7 X+idAr5ZVNK91Srlh4Ry+ptu/qeu0+esB6RtG9qTrPhJDXFtUhYwNl4+0uXDxu4/PpQ4KctQnKe6J gds6G7WzPh+yp5oSHRvhDr+G4d0P4H+zKP3S3LLLPSrd9GVLo6C/rUTkh8yNWCAmxguHhHXUj9g5z ypc42oPA==; Received: from [2001:8b0:10b:1::425] (helo=i7.infradead.org) by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1wtj60-0000000GFnW-1SdB; Tue, 11 Aug 2026 09:48:40 +0000 Received: from dwoodhou by i7.infradead.org with local (Exim 4.99.4 #2 (Red Hat Linux)) id 1wtj5z-00000000PjY-40Go; Tue, 11 Aug 2026 10:48:31 +0100 From: David Woodhouse To: seanjc@google.com, pbonzini@redhat.com Cc: dwmw@amazon.co.uk, paul@xen.org, joao.m.martins@oracle.com, boris.ostrovsky@oracle.com, ankur.a.arora@oracle.com, tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, x86@kernel.org, syzbot+208f7f3e5f59c11aeb90@syzkaller.appspotmail.com, syzkaller-bugs@googlegroups.com, suryasaimadhu369@gmail.com, lkp@intel.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 09/11] KVM: x86/xen: Use atomic*() APIs instead of open coded equivalents Date: Tue, 11 Aug 2026 10:37:11 +0100 Message-ID: <20260811094829.98794-10-dwmw2@infradead.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260811094829.98794-1-dwmw2@infradead.org> References: <20260811094829.98794-1-dwmw2@infradead.org> 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 Sender: David Woodhouse X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org. See http://www.infradead.org/rpr.html Content-Type: text/plain; charset="utf-8" From: Sean Christopherson Replace the open coded atomic asm blobs in the Xen event injection code with equivalent atomic{,64}_xxx() operations. Casting the event channel to atomic types is ugly, but not as ugly as asm blobs. No functional change intended. Signed-off-by: Sean Christopherson Signed-off-by: David Woodhouse --- arch/x86/kvm/xen.c | 35 ++++++++++++----------------------- 1 file changed, 12 insertions(+), 23 deletions(-) diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c index 419b07fdaa3a..99f3ffa64fdb 100644 --- a/arch/x86/kvm/xen.c +++ b/arch/x86/kvm/xen.c @@ -662,12 +662,12 @@ void kvm_xen_inject_pending_events(struct kvm_vcpu *v) /* Now gpc->khva is a valid kernel address for the vcpu_info */ if (kvm_xen_has_64bit_shinfo(v->kvm)) { struct vcpu_info *vi =3D gpc->khva; + void *vi_pending_sel =3D &vi->evtchn_pending_sel; =20 - if (IS_ALIGNED((unsigned long)&vi->evtchn_pending_sel, sizeof(u64))) - asm volatile(LOCK_PREFIX "orq %[src], %[dst]\n" - : [dst] "+m" (vi->evtchn_pending_sel) - : [src] "r" (evtchn_pending_sel)); - else + if (IS_ALIGNED((unsigned long)vi_pending_sel, sizeof(u64))) { + atomic64_or(evtchn_pending_sel, vi_pending_sel); + } else { + atomic_or(evtchn_pending_sel, vi_pending_sel); /* * The cast keeps the shift well-defined on 32-bit, * where evtchn_pending_sel is 32 bits wide and this @@ -675,28 +675,17 @@ void kvm_xen_inject_pending_events(struct kvm_vcpu *v) * kvm_xen_has_64bit_shinfo(), which is gated on * IS_ENABLED(CONFIG_64BIT)). */ - asm volatile(LOCK_PREFIX "orl %[src_lo], %[dst_lo]\n" - LOCK_PREFIX "orl %[src_hi], %[dst_hi]\n" - : [dst_lo] "+m" (vi->evtchn_pending_sel), - [dst_hi] "+m" (*(((u32 *)&vi->evtchn_pending_sel) + 1)) - : [src_lo] "r" ((u32)evtchn_pending_sel), - [src_hi] "r" ((u32)((u64)evtchn_pending_sel >> 32))); - - asm volatile(LOCK_PREFIX "andq %1, %0\n" - : "+m" (v->arch.xen.evtchn_pending_sel) - : "r" (~evtchn_pending_sel)); + atomic_or((u64)evtchn_pending_sel >> 32, + vi_pending_sel + 4); + } + + atomic64_andnot(evtchn_pending_sel, (void *)&v->arch.xen.evtchn_pending_= sel); WRITE_ONCE(vi->evtchn_upcall_pending, 1); } else { - u32 evtchn_pending_sel32 =3D evtchn_pending_sel; struct compat_vcpu_info *vi =3D gpc->khva; =20 - asm volatile(LOCK_PREFIX "orl %0, %1\n" - "notl %0\n" - LOCK_PREFIX "andl %0, %2\n" - : "=3Dr" (evtchn_pending_sel32), - "+m" (vi->evtchn_pending_sel), - "+m" (v->arch.xen.evtchn_pending_sel) - : "0" (evtchn_pending_sel32)); + atomic_or(evtchn_pending_sel, (void *)&vi->evtchn_pending_sel); + atomic_andnot(evtchn_pending_sel, (void *)&v->arch.xen.evtchn_pending_se= l); WRITE_ONCE(vi->evtchn_upcall_pending, 1); } =20 --=20 2.55.0 From nobody Tue Sep 29 06:59:45 2026 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 E6B5342A15B; Tue, 11 Aug 2026 09:49:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786441762; cv=none; b=UlbOr2qvvEZhw5I/kzCa8C6yserVK9fM5BughfT+n+EiggKJ5ZqKgY478L1LGUZu/6Am5AJUNfCWail1RsxELby0u+x67L5x2f22wF4D1atJSfheK5idcWd5wdd9JeyQ8yj6rsUo3ILKy3CfczpUVTsl/AuOPFe2W1WLq9NcQZs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786441762; c=relaxed/simple; bh=LCgGs5ObVSkdEVmndBoydTIC1T2v5fzBEIw77k9Ar7g=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JYwlAVQ6ZQCD3KJWiFqhRT7pha8vF6Y4TH+8ayTjLyDe/G4efvrfvmlQO5ikodsS84LIomM3pKOYBF58Do/dp75TlvUeKS3H8qidKJVe0XMHjFzQsq/d3101rW2Nqj3DIz9nR/W2kd/5FHRlp5lchRv0/ScOyBM+jCeB6yhhNPs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=desiato.srs.infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=cZtHI+6y; arc=none smtp.client-ip=90.155.92.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=desiato.srs.infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="cZtHI+6y" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: Reply-To:Content-Type:Content-ID:Content-Description; bh=bRv/qlKPM3HRbunD0JVkSYIBB4xfGuKOP6yp+dFg87E=; b=cZtHI+6yCHJr+5LCs51zk/zkOO C0Xa4kf5DIOn5AlvxOdozlgFXD/CQT9zkF+KM7NsoWpMXAnU60SLfwZGms74zA/4OYhFzB2YxW2WC DryWXG7V5l0pbCIPnSAxgBuWavCN9zM/CSSrLPleK06tUIMDVmMKQD3SZUx0DEnvgPR53nlXzageU wok28rik0UCZFzFFfrNbB/1FaoDGbVA9N+7BJBOCP9qcR00Wnjc1dC48mZyhYy3gbmCRy3rnxg5Mz YDLWBK0rSOGdXlt93GNoGh6Y6qROgcPAwlDVCjZOQLwVX5XRiRei/o7klO68qwEg6HXKcr6A2eYlK KwUYftjQ==; Received: from [2001:8b0:10b:1::425] (helo=i7.infradead.org) by desiato.infradead.org with esmtpsa (Exim 4.99.2 #2 (Red Hat Linux)) id 1wtj62-0000000EU1T-46Bp; Tue, 11 Aug 2026 09:48:35 +0000 Received: from dwoodhou by i7.infradead.org with local (Exim 4.99.4 #2 (Red Hat Linux)) id 1wtj5z-00000000Pjb-4ABS; Tue, 11 Aug 2026 10:48:31 +0100 From: David Woodhouse To: seanjc@google.com, pbonzini@redhat.com Cc: dwmw@amazon.co.uk, paul@xen.org, joao.m.martins@oracle.com, boris.ostrovsky@oracle.com, ankur.a.arora@oracle.com, tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, x86@kernel.org, syzbot+208f7f3e5f59c11aeb90@syzkaller.appspotmail.com, syzkaller-bugs@googlegroups.com, suryasaimadhu369@gmail.com, lkp@intel.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 10/11] KVM: x86/xen: Take kvm->srcu in __kvm_xen_has_interrupt() Date: Tue, 11 Aug 2026 10:37:12 +0100 Message-ID: <20260811094829.98794-11-dwmw2@infradead.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260811094829.98794-1-dwmw2@infradead.org> References: <20260811094829.98794-1-dwmw2@infradead.org> 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 Sender: David Woodhouse X-SRS-Rewrite: SMTP reverse-path rewritten from by desiato.infradead.org. See http://www.infradead.org/rpr.html Content-Type: text/plain; charset="utf-8" From: David Woodhouse kvm_gpc_check() checks the cached memslot generation against the current one, which dereferences kvm->memslots and therefore requires kvm->srcu to be held. __kvm_xen_has_interrupt() does not take it. Most callers do happen to hold kvm->srcu, but not all of them: - kvm_emulate_halt() on the VM-Exit path, via kvm_vcpu_has_events() and kvm_cpu_has_extint(). vcpu_enter_guest() drops the vCPU's SRCU lock before entering the guest, so it is not held on the way back out. - kvm_vcpu_block() -> kvm_vcpu_check_block() -> kvm_arch_vcpu_runnable(), which is the case the existing comment in this function describes. On a PROVE_RCU kernel the former produces: WARNING: suspicious RCU usage include/linux/kvm_host.h:1092 suspicious rcu_dereference_check() usage! ... kvm_gpc_check+0x344/0x3e0 [kvm] __kvm_xen_has_interrupt+0x83/0x310 [kvm] kvm_cpu_has_extint+0x1ff/0x370 [kvm] kvm_cpu_has_interrupt+0x16/0x100 [kvm] kvm_vcpu_has_events+0x4ce/0x690 [kvm] kvm_emulate_halt+0x52/0x1f0 [kvm] vmx_vcpu_run+0x988/0x2630 [kvm_intel] Use guard(srcu) so that the three existing early returns don't each need an explicit unlock. SRCU read sections nest, so this is harmless on the paths which already hold it, and srcu_read_lock() does not sleep, so it is also safe in the atomic case which this function already handles. Fixes: 7caf9571563e ("KVM: x86/xen: Use gfn_to_pfn_cache for vcpu_info") Cc: stable@vger.kernel.org Signed-off-by: David Woodhouse Assisted-by: Claude:claude-mythos-5 --- arch/x86/kvm/xen.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c index 99f3ffa64fdb..ff55ff290afb 100644 --- a/arch/x86/kvm/xen.c +++ b/arch/x86/kvm/xen.c @@ -716,6 +716,16 @@ int __kvm_xen_has_interrupt(struct kvm_vcpu *v) BUILD_BUG_ON(sizeof(rc) !=3D sizeof_field(struct compat_vcpu_info, evtchn_upcall_pending)); =20 + /* + * kvm_gpc_check() checks the memslot generation, so kvm->srcu must be + * held. Most callers hold it already, but this is also reached from + * kvm_emulate_halt() on the VM-Exit path and from kvm_vcpu_block(), + * where vcpu_enter_guest() has already dropped the vCPU's SRCU lock. + * Taking SRCU does not sleep, so it is safe even in the atomic case + * which is handled below. + */ + guard(srcu)(&v->kvm->srcu); + read_lock_irqsave(&gpc->lock, flags); while (!kvm_gpc_check(gpc, sizeof(struct vcpu_info))) { read_unlock_irqrestore(&gpc->lock, flags); --=20 2.55.0 From nobody Tue Sep 29 06:59:45 2026 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 E69FB429CFA; Tue, 11 Aug 2026 09:49:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786441763; cv=none; b=MrNXdavmVcA1AJy9Q/hTrFbDgPjHNuTz585cqtWgVBGxu/QFO4YwZC6fOGRfCQlCIbu4vYspKXQU6Hk+TiaL1qQzRqAYCiVk9Mc3fJ2bmwxPkE2L7wm4wAqJxjuUI98+87W1YW6wnGaq3VwlWG9lNpyox2qv3kF+MLujj1JJNNY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786441763; c=relaxed/simple; bh=Vfnh/9fMaArhObs5D3xJh7Si1Lq3Co0mQ7suO5s1OI8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JlrR0sopPXD6htBt+cxoaK2fPOSWW0Z3hMSm/AYdNqaZFHHygQXhM/cbtii/0KKQx0MWV354Oq5u2Wh6H7dD4qOA5JA/z+/9I3M/7KLdnmFG87AAiSkdbrHk5ODrwBWUY+N8rT1UefV0UQGdZ5D/qF1EypYdDqUT7CabBnM4Pbw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=desiato.srs.infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=mK5bzx1M; arc=none smtp.client-ip=90.155.92.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=desiato.srs.infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="mK5bzx1M" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: Reply-To:Content-Type:Content-ID:Content-Description; bh=+lDKzQVjcsB78v51FfJbUti+HDh80svUEsboABm2Q3E=; b=mK5bzx1Mb0wC7hQAIqjpQccrlh ky+yPH6Hnmg0IMImOcHXWIsF0Enh/8JawNgHeZbjsX3MVqG4LqyeUaghxXT6H6H54T7KFvihIyZak szoX2x9q3UtBDZQQQjmu0d0jGkK/C1iNKO0yQ/JogncwjxVTXVnzjXsmPBookr0riQeJ8hWSo4Ahs 5B6HMMxB46lQojQT8OIcumrzKbIn61aGJgf3jBGNVc2bMPpXjZXRqvzQBUTnjANeVSXkPJVJUsPWz h/nNuisadBQNnmdQz6HkD0qXKOICH2dDEs/9PGl/j6q/SnyQUXTiXnLFcpdgM8dPZxbjkIDJ1j0LV sbIZ2ydQ==; Received: from [2001:8b0:10b:1::425] (helo=i7.infradead.org) by desiato.infradead.org with esmtpsa (Exim 4.99.2 #2 (Red Hat Linux)) id 1wtj62-0000000EU1U-472u; Tue, 11 Aug 2026 09:48:35 +0000 Received: from dwoodhou by i7.infradead.org with local (Exim 4.99.4 #2 (Red Hat Linux)) id 1wtj60-00000000Pje-08XE; Tue, 11 Aug 2026 10:48:32 +0100 From: David Woodhouse To: seanjc@google.com, pbonzini@redhat.com Cc: dwmw@amazon.co.uk, paul@xen.org, joao.m.martins@oracle.com, boris.ostrovsky@oracle.com, ankur.a.arora@oracle.com, tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, x86@kernel.org, syzbot+208f7f3e5f59c11aeb90@syzkaller.appspotmail.com, syzkaller-bugs@googlegroups.com, suryasaimadhu369@gmail.com, lkp@intel.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 11/11] KVM: pfncache: use a dedicated invalidation sequence for cache refresh Date: Tue, 11 Aug 2026 10:37:13 +0100 Message-ID: <20260811094829.98794-12-dwmw2@infradead.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260811094829.98794-1-dwmw2@infradead.org> References: <20260811094829.98794-1-dwmw2@infradead.org> 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 Sender: David Woodhouse X-SRS-Rewrite: SMTP reverse-path rewritten from by desiato.infradead.org. See http://www.infradead.org/rpr.html Content-Type: text/plain; charset="utf-8" From: David Woodhouse The gfn_to_pfn_cache refresh path guards against mmu notifier invalidations which complete while it has dropped gpc->lock for the HVA->PFN lookup: hva_to_pfn_retry() samples kvm->mmu_invalidate_seq and retries if it changed, or if mn_active_invalidate_count is still elevated. That is insufficient for HVA-based caches. mmu_invalidate_seq is only advanced by kvm_mmu_invalidate_end() when the invalidated range overlaps a memslot, and an HVA-based cache (e.g. the Xen shared_info page mapped with KVM_XEN_ATTR_TYPE_SHARED_INFO_HVA) need not be backed by any memslot at all. An invalidation of the cached HVA which starts and ends entirely within the lookup window is thus invisible to the retry check: mn_active_invalidate_count is back to zero and the sequence never moved. The refresh then publishes a mapping of a page which has already been freed, and the next reader dereferences it: BUG: KASAN: use-after-free in kvm_xen_shared_info_init+0x3c6/0x440 Read of size 4 at addr ffff8880599c2900 by task syz.2.383/7257 Since gfn_to_pfn_cache_invalidate_start() deliberately skips caches which are not currently valid (including one whose refresh is in progress, as the refresh clears the valid flag before dropping the lock), the retry check is the only line of defence, and it must fire for *any* invalidation, not just those hitting a memslot. Add a dedicated kvm->gpc_invalidate_seq, incremented by every kvm_mmu_notifier_invalidate_range_end() under mn_invalidate_lock before mn_active_invalidate_count is decremented, and check it in hva_to_pfn_retry() instead of mmu_invalidate_seq. Incrementing in range_end() in the same critical section as the in-progress count also closes the variant where the cache is activated with the contested HVA only after invalidate_range_start() has run. The same bug is also reachable through the per-vCPU vcpu_info cache (KVM_XEN_VCPU_ATTR_TYPE_VCPU_INFO_HVA), where the stale mapping is then dereferenced by kvm_setup_guest_pvclock() on the next KVM_RUN: BUG: KASAN: use-after-free in kvm_setup_guest_pvclock+0x5bf/0x660 This intentionally makes refresh retry on *unrelated* mmu notifier events; restoring precision (and reworking the GPC locking more generally) is left for a subsequent series. Reproducers: https://david.woodhou.se/xen_shinfo_race.c https://david.woodhou.se/vcpu_info_race.c Suggested-by: Sean Christopherson Reported-by: syzbot+0948c82180d475ad24e2@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6a0c5f2c.a00a0220.2c7954.0000.GAE@googl= e.com/ Tested-by: syzbot+0948c82180d475ad24e2@syzkaller.appspotmail.com Reported-by: syzbot+fb7c2dd166d3ea63df2a@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6a426dd2.854d4ab9.360e1d.0008.GAE@googl= e.com/ Fixes: b9220d32799a ("KVM: x86/xen: allow shared_info to be mapped by fixed= HVA") Cc: stable@vger.kernel.org Signed-off-by: David Woodhouse Assisted-by: Claude:claude-mythos-5 --- include/linux/kvm_host.h | 2 ++ virt/kvm/kvm_main.c | 10 ++++++++++ virt/kvm/pfncache.c | 18 +++++++++--------- 3 files changed, 21 insertions(+), 9 deletions(-) diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 03bfc92864b6..3dd04605f2e5 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -855,6 +855,8 @@ struct kvm { gfn_t mmu_invalidate_range_start; gfn_t mmu_invalidate_range_end; =20 + unsigned long gpc_invalidate_seq; + struct list_head devices; u64 manual_dirty_log_protect; struct dentry *debugfs_dentry; diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 345d56a15fa4..41c88a8ade95 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -812,6 +812,16 @@ static void kvm_mmu_notifier_invalidate_range_end(stru= ct mmu_notifier *mn, =20 /* Pairs with the increment in range_start(). */ spin_lock(&kvm->mn_invalidate_lock); + kvm->gpc_invalidate_seq++; + + /* + * As with the MMU sequence counter and mmu_invalidate_in_progress, the + * GPC sequence increase must be visible before the invalidate count + * goes to zero. Pairs with the smp_rmb() in + * mmu_notifier_retry_cache(). + */ + smp_wmb(); + if (!WARN_ON_ONCE(!kvm->mn_active_invalidate_count)) --kvm->mn_active_invalidate_count; wake =3D !kvm->mn_active_invalidate_count; diff --git a/virt/kvm/pfncache.c b/virt/kvm/pfncache.c index 728d2c1b488a..3659686b97c2 100644 --- a/virt/kvm/pfncache.c +++ b/virt/kvm/pfncache.c @@ -124,7 +124,7 @@ static void gpc_unmap(kvm_pfn_t pfn, void *khva) #endif } =20 -static inline bool mmu_notifier_retry_cache(struct kvm *kvm, unsigned long= mmu_seq) +static inline bool mmu_notifier_retry_cache(struct kvm *kvm, unsigned long= gpc_seq) { /* * mn_active_invalidate_count acts for all intents and purposes @@ -136,20 +136,20 @@ static inline bool mmu_notifier_retry_cache(struct kv= m *kvm, unsigned long mmu_s * Note, it does not matter that mn_active_invalidate_count * is not protected by gpc->lock. It is guaranteed to * be elevated before the mmu_notifier acquires gpc->lock, and - * isn't dropped until after mmu_invalidate_seq is updated. + * isn't dropped until after gpc_invalidate_seq is updated. */ if (kvm->mn_active_invalidate_count) return true; =20 /* * Ensure mn_active_invalidate_count is read before - * mmu_invalidate_seq. This pairs with the smp_wmb() in - * mmu_notifier_invalidate_range_end() to guarantee either the + * gpc_invalidate_seq. This pairs with the smp_wmb() in + * kvm_mmu_notifier_invalidate_range_end() to guarantee either the * old (non-zero) value of mn_active_invalidate_count or the - * new (incremented) value of mmu_invalidate_seq is observed. + * new (incremented) value of gpc_invalidate_seq is observed. */ smp_rmb(); - return kvm->mmu_invalidate_seq !=3D mmu_seq; + return kvm->gpc_invalidate_seq !=3D gpc_seq; } =20 static kvm_pfn_t hva_to_pfn_retry(struct gfn_to_pfn_cache *gpc) @@ -158,7 +158,7 @@ static kvm_pfn_t hva_to_pfn_retry(struct gfn_to_pfn_cac= he *gpc) void *old_khva =3D (void *)PAGE_ALIGN_DOWN((uintptr_t)gpc->khva); kvm_pfn_t new_pfn =3D KVM_PFN_ERR_FAULT; void *new_khva =3D NULL; - unsigned long mmu_seq; + unsigned long gpc_seq; struct page *page; =20 struct kvm_follow_pfn kfp =3D { @@ -181,7 +181,7 @@ static kvm_pfn_t hva_to_pfn_retry(struct gfn_to_pfn_cac= he *gpc) gpc->valid =3D false; =20 do { - mmu_seq =3D gpc->kvm->mmu_invalidate_seq; + gpc_seq =3D gpc->kvm->gpc_invalidate_seq; smp_rmb(); =20 write_unlock_irq(&gpc->lock); @@ -232,7 +232,7 @@ static kvm_pfn_t hva_to_pfn_retry(struct gfn_to_pfn_cac= he *gpc) * attempting to refresh. */ WARN_ON_ONCE(gpc->valid); - } while (mmu_notifier_retry_cache(gpc->kvm, mmu_seq)); + } while (mmu_notifier_retry_cache(gpc->kvm, gpc_seq)); =20 gpc->valid =3D true; gpc->pfn =3D new_pfn; --=20 2.55.0