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: 18+ 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:44 ` sashiko-bot
2026-06-05 15:07 ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.