Re: [PATCH v3 04/10] KVM: x86/xen: Punt singleshot timer hcalls to userspace if Xen vCPU ID isn't set

[Sean Christopherson <seanjc@google.com>]

On Thu, Jun 25, 2026, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> >  	switch (cmd) {
> >  	case VCPUOP_set_singleshot_timer:
> >  		if (vcpu->arch.xen.vcpu_id != vcpu_id) {
> [ ... ]
> > @@ -2299,7 +2303,7 @@ static bool kvm_xen_hcall_evtchn_send(struct kvm_vcpu *vcpu, u64 param, u64 *r)
> >  
> >  void kvm_xen_init_vcpu(struct kvm_vcpu *vcpu)
> >  {
> > -	vcpu->arch.xen.vcpu_id = vcpu->vcpu_idx;
> > +	vcpu->arch.xen.vcpu_id = XEN_VCPU_ID_INVALID;
> 
> [Severity: High]
> Does this initialization break live migration when the ID isn't configured?

If userspace actually read the ID from KVM and migrated it blindly, but AFAIK
no VMM even uses KVM_GET_XEN_VCPU_ATTR to get the ID.

> When userspace calls KVM_GET_XEN_VCPU_ATTR, it retrieves the uninitialized ID
> as XEN_VCPU_ID_INVALID (which is U32_MAX).
> 
> On the destination host, attempting to restore this state fails because
> kvm_xen_vcpu_set_attr() explicitly rejects values >= KVM_MAX_VCPUS:
> 
> arch/x86/kvm/xen.c:kvm_xen_vcpu_set_attr() {
>     ...
>     case KVM_XEN_VCPU_ATTR_TYPE_VCPU_ID:
>         if (data->u.vcpu_id >= KVM_MAX_VCPUS)
>             r = -EINVAL;
>         else {
>     ...
> }
> 
> Will this cause KVM to unconditionally reject the valid state returned by
> GET_ATTR and return -EINVAL during live migration?
> 
> >  	vcpu->arch.xen.poll_evtchn = 0;
> >  
> >  	timer_setup(&vcpu->arch.xen.poll_timer, cancel_evtchn_poll, 0);
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260625223623.3376478-1-seanjc@google.com?part=4