Re: [PATCH v3 04/10] KVM: x86/xen: Punt singleshot timer hcalls to userspace if Xen vCPU ID isn't set
From: David Woodhouse
Date: Fri Jun 26 2026 - 11:21:51 EST
On Fri, 2026-06-26 at 07:27 -0700, Sean Christopherson wrote:
>
> > > Note, KVM's handling of KVM_XEN_VCPU_ATTR_TYPE_VCPU_ID restricts the ID to
> > > KVM_MAX_VCPUS, so there's no chance of a valid ID colliding with -1u.
> >
> > Nit: XEN_VCPU_ID_INVALID isn't -1u; it's U32_MAX.
> >
> > I'd have been slightly happier if you'd used an explicit -1U, perhaps
> > with a name of its own (although I guess we wouldn't want to call it
> > KVM_VCPU_IDX_INVALID in the *Xen* part).
>
> Ya, I was 50/50 on having KVM define its own INVALID macro versus reusing what
> the Xen-the-guest has. I didn't want to open code the literal, because that
> would require open coding a somewhat magical value in multiple locations. And
> having XEN_VCPU_ID_INVALID and KVM_XEN_VCPU_ID_INVALID, with the same value,
> seemed even worse than reusing a macro that isn't strictly owned by KVM.
>
> What if I also add a compile-timer assertion? In the end, KVM doesn't care what
> value XEN_VCPU_ID_INVALID uses, so long as it can't colled with what is allowed
> by KVM_XEN_VCPU_ATTR_TYPE_VCPU_ID.
Yeah, that makes sense. It's consistent with the build-time assertions
we have elsewhere in the Xen code to document other such things we hold
to be true.
I'd probably have put it along with the code which *uses*
XEN_VCPU_ID_INVALID but I guess it doesn't matter.
> diff --git arch/x86/kvm/xen.c arch/x86/kvm/xen.c
> index 3ed6686e0a1a..5c60ed9ef2cc 100644
> --- arch/x86/kvm/xen.c
> +++ arch/x86/kvm/xen.c
> @@ -1103,6 +1103,8 @@ int kvm_xen_vcpu_set_attr(struct kvm_vcpu *vcpu, struct kvm_xen_vcpu_attr *data)
> break;
>
> case KVM_XEN_VCPU_ATTR_TYPE_VCPU_ID:
> + BUILD_BUG_ON(XEN_VCPU_ID_INVALID < KVM_MAX_VCPUS);
> +
> if (data->u.vcpu_id >= KVM_MAX_VCPUS)
> r = -EINVAL;
> else {
Attachment:
smime.p7s
Description: S/MIME cryptographic signature