From: David Laight <david.laight.linux@gmail.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Sean Christopherson <seanjc@google.com>,
Paul Durrant <paul@xen.org>, Hyunwoo Kim <imv4bel@gmail.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/8] KVM: x86/xen: Introduce kvm_xen_has_64bit_shinfo() macro
Date: Sat, 6 Jun 2026 10:30:43 +0100 [thread overview]
Message-ID: <20260606103043.0d9a4baf@pumpkin> (raw)
In-Reply-To: <20260605143034.3603-3-dwmw2@infradead.org>
On Fri, 5 Jun 2026 15:17:27 +0100
David Woodhouse <dwmw2@infradead.org> wrote:
> From: David Woodhouse <dwmw@amazon.co.uk>
>
> 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.
If another vCPU changes the flag then isn't it all broken?
The code seems to need the value to be stable.
-- David
>
> This is the KVM equivalent of Xen's !has_32bit_shinfo().
>
> Assisted-by: Kiro:claude-opus-4.6-1m
> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
> ---
> 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 a7ab19f38b59..acd3cd87dd2f 100644
> --- a/arch/x86/kvm/xen.c
> +++ b/arch/x86/kvm/xen.c
> @@ -72,7 +72,7 @@ static int kvm_xen_shared_info_init(struct kvm *kvm)
> BUILD_BUG_ON(offsetof(struct shared_info, wc) != 0xc00);
> BUILD_BUG_ON(offsetof(struct shared_info, wc_sec_hi) != 0xc0c);
>
> - if (IS_ENABLED(CONFIG_64BIT) && kvm->arch.xen.long_mode) {
> + if (kvm_xen_has_64bit_shinfo(kvm)) {
> struct shared_info *shinfo = gpc->khva;
>
> wc_sec_hi = &shinfo->wc_sec_hi;
> @@ -390,7 +390,7 @@ static void kvm_xen_update_runstate_guest(struct kvm_vcpu *v, bool atomic)
> BUILD_BUG_ON(sizeof_field(struct vcpu_runstate_info, time) !=
> sizeof(vx->runstate_times));
>
> - if (IS_ENABLED(CONFIG_64BIT) && v->kvm->arch.xen.long_mode) {
> + if (kvm_xen_has_64bit_shinfo(v->kvm)) {
> user_len = sizeof(struct vcpu_runstate_info);
> times_ofs = offsetof(struct vcpu_runstate_info,
> state_entry_time);
> @@ -661,7 +661,7 @@ void kvm_xen_inject_pending_events(struct kvm_vcpu *v)
> }
>
> /* 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 = gpc->khva;
>
> asm volatile(LOCK_PREFIX "orq %0, %1\n"
> @@ -978,7 +978,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 = sizeof(struct vcpu_runstate_info);
> else
> sz = sizeof(struct compat_vcpu_runstate_info);
> @@ -1424,7 +1424,7 @@ static int kvm_xen_hypercall_complete_userspace(struct kvm_vcpu *vcpu)
>
> 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;
> @@ -1446,7 +1446,7 @@ static bool wait_pending_event(struct kvm_vcpu *vcpu, int nr_ports,
> goto out_rcu;
>
> ret = false;
> - if (IS_ENABLED(CONFIG_64BIT) && kvm->arch.xen.long_mode) {
> + if (kvm_xen_has_64bit_shinfo(kvm)) {
> struct shared_info *shinfo = gpc->khva;
> pending_bits = (unsigned long *)&shinfo->evtchn_pending;
> } else {
> @@ -1820,7 +1820,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;
>
> - if (IS_ENABLED(CONFIG_64BIT) && kvm->arch.xen.long_mode) {
> + if (kvm_xen_has_64bit_shinfo(kvm)) {
> struct shared_info *shinfo = gpc->khva;
> pending_bits = (unsigned long *)&shinfo->evtchn_pending;
> mask_bits = (unsigned long *)&shinfo->evtchn_mask;
> @@ -1861,7 +1861,7 @@ int kvm_xen_set_evtchn_fast(struct kvm_xen_evtchn *xe, struct kvm *kvm)
> goto out_rcu;
> }
>
> - if (IS_ENABLED(CONFIG_64BIT) && kvm->arch.xen.long_mode) {
> + if (kvm_xen_has_64bit_shinfo(kvm)) {
> struct vcpu_info *vcpu_info = 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;
next prev parent reply other threads:[~2026-06-06 9:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-05 14:17 [PATCH 0/8] KVM: x86/xen: Clean up 32-bit vs. 64-bit shared info mode handling David Woodhouse
2026-06-05 14:17 ` [PATCH 1/8] KVM: x86/xen: Rename 'longmode' to 'is_64bit' in hypercall handling David Woodhouse
2026-06-05 14:17 ` [PATCH 2/8] KVM: x86/xen: Introduce kvm_xen_has_64bit_shinfo() macro David Woodhouse
2026-06-06 9:30 ` David Laight [this message]
2026-06-06 9:35 ` David Woodhouse
2026-06-06 11:11 ` David Laight
2026-06-06 11:22 ` David Woodhouse
2026-06-05 14:17 ` [PATCH 3/8] KVM: x86/xen: Rename max_evtchn_port() to kvm_max_evtchn_port() David Woodhouse
2026-06-05 14:17 ` [PATCH 4/8] KVM: x86/xen: Latch shinfo mode in kvm_xen_set_evtchn_fast() David Woodhouse
2026-06-05 14:17 ` [PATCH 5/8] KVM: x86/xen: Latch shinfo mode in kvm_xen_schedop_poll() David Woodhouse
2026-06-05 14:17 ` [PATCH 6/8] KVM: x86/xen: Enforce alignment of vcpu_info registration David Woodhouse
2026-06-05 14:17 ` [PATCH 7/8] KVM: x86/xen: Use 32-bit locked bts for vcpu_info evtchn_pending_sel David Woodhouse
2026-07-08 15:48 ` Sean Christopherson
2026-06-05 14:17 ` [PATCH 8/8] KVM: x86/xen: Use 32-bit locked ops in kvm_xen_inject_pending_events() David Woodhouse
2026-07-08 15:23 ` Sean Christopherson
2026-07-08 15:41 ` David Woodhouse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260606103043.0d9a4baf@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=dwmw2@infradead.org \
--cc=hpa@zytor.com \
--cc=imv4bel@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=paul@xen.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox