From: sashiko-bot@kernel.org
To: "David Woodhouse" <dwmw2@infradead.org>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH 6/8] KVM: x86/xen: Enforce alignment of vcpu_info registration
Date: Fri, 05 Jun 2026 14:44:58 +0000 [thread overview]
Message-ID: <20260605144458.C938E1F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260605143034.3603-7-dwmw2@infradead.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Enforcing hypercall-time alignment checks inside KVM_XEN_VCPU_SET_ATTR breaks live migration for guests that registered a 4-byte aligned vcpu_info in 32-bit mode and subsequently switched to 64-bit mode.
--
commit cfaeaf400a74663fc7a7498659d4e3aee30b0640
Author: David Woodhouse <dwmw@amazon.co.uk>
Subject: KVM: x86/xen: Enforce alignment of vcpu_info registration
This commit enforces that the vcpu_info GPA and HVA are aligned to the size
of a xen_ulong_t based on the guest's bitness. It returns -ENXIO for
requests that do not meet the alignment requirements.
Link: https://lore.kernel.org/all/20260604193554.1BA311F00893@smtp.kernel.org/
> diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c
> index 40b98e70c2dfe..9a6bb094a44f4 100644
> --- a/arch/x86/kvm/xen.c
> +++ b/arch/x86/kvm/xen.c
> @@ -926,6 +926,12 @@ int kvm_xen_vcpu_set_attr(struct kvm_vcpu *vcpu, struct kvm_xen_vcpu_attr *data)
> break;
> }
>
> + r = -ENXIO;
> + if (!IS_ALIGNED(data->u.gpa,
> + kvm_xen_has_64bit_shinfo(vcpu->kvm) ?
> + sizeof(unsigned long) : sizeof(u32)))
> + break;
> +
[Severity: High]
The commit message mentions that a guest can validly register a vcpu_info at
a 4-byte aligned address while in 32-bit mode and then switch to 64-bit mode.
If a VM does this, what happens during live migration?
If the VMM restores the VM-wide LONG_MODE state before restoring the vCPU
state via kvm_xen_vcpu_set_attr(), kvm_xen_has_64bit_shinfo() will evaluate to
true.
Could this cause KVM to incorrectly enforce 8-byte alignment and reject
the valid 4-byte aligned GPA with -ENXIO, breaking the migration?
> r = kvm_gpc_activate(&vcpu->arch.xen.vcpu_info_cache,
> data->u.gpa, sizeof(struct vcpu_info));
> } else {
> @@ -935,6 +941,12 @@ int kvm_xen_vcpu_set_attr(struct kvm_vcpu *vcpu, struct kvm_xen_vcpu_attr *data)
> break;
> }
>
> + r = -ENXIO;
> + if (!IS_ALIGNED(data->u.hva,
> + kvm_xen_has_64bit_shinfo(vcpu->kvm) ?
> + sizeof(unsigned long) : sizeof(u32)))
> + break;
> +
[Severity: High]
Does this HVA alignment check suffer from the same state restoration ordering
issue during live migration?
> r = kvm_gpc_activate_hva(&vcpu->arch.xen.vcpu_info_cache,
> data->u.hva, sizeof(struct vcpu_info));
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260605143034.3603-1-dwmw2@infradead.org?part=6
next prev parent reply other threads:[~2026-06-05 14:44 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
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 [this message]
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=20260605144458.C938E1F00893@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dwmw2@infradead.org \
--cc=kvm@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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