Re: [RFC PATCH 2/7] common: Track latest pCPU that ran the vCPU

[Teddy Astie <teddy.astie@xxxxxxxxxx>]

Le 04/05/2026 à 17:51, Jan Beulich a écrit :
> On 15.04.2026 15:32, Teddy Astie wrote:
> > Track on which pCPU each vCPU of a domain ran. This will
> > be used to know whether a TLB flush is required or not
> > when the vCPU is migrated on another pCPU.
> Somewhat related tracking already exists - see the dirty_cpumask field.
I've seen it, but I'm not sure how it can be leveraged here.

I will try to take a closer look if that could be used instead.

> But what title and description say doesn't match ...
>
> > @@ -977,6 +978,8 @@ void asmlinkage svm_vmenter_helper(void)
> >   
> >       svm_sync_vmcb(curr, vmcb_needs_vmsave);
> >   
> > +    curr->domain->latest_vcpu[cpu] = curr->vcpu_id;
> ... the implementation anyway: You track which vCPU last ran on a given
> pCPU. Since the same pCPU may have run multiple vCPU-s which then weren't
> scheduled again, you lose data afaict.
I mixed up the wording. But the implementation is the proper intent.

It's more

  Track which vCPU of the domain each pCPU ran.

> > @@ -992,6 +993,13 @@ struct domain *domain_create(domid_t domid,
> >       if ( !zalloc_cpumask_var(&d->dirty_cpumask) )
> >           goto fail;
> >   
> > +    err = -ENOMEM;
> > +    d->latest_vcpu = xmalloc_array(int, nr_cpu_ids);
> xvmalloc_array() please, as this can be huge. It possibly being huge is
> also of concern.
>
> > --- a/xen/include/xen/sched.h
> > +++ b/xen/include/xen/sched.h
> > @@ -567,6 +567,10 @@ struct domain
> >       /* Bitmask of CPUs which are holding onto this domain's state. */
> >       cpumask_var_t    dirty_cpumask;
> >   
> > +    /* Mapping of the latest vCPU that ran on a specific CPU
> > +     * (-1 if the vCPU hasn't ran yet) */
> > +    int *latest_vcpu;
> Why plain int? You don't really leverage -1 as a sentinel, and any
> unsigned value >= nr_cpu_ids would do in its stead.
int is not really required here in practice. It's more here to express a 
invalid state instead of leaving 0 (which would be first pCPU) even if 
it would not change the overall behavior. Using ~0 could also work 
alternatively.
> Jan
Teddy

Attachment: OpenPGP_0x660FA9D102CBCFD0.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature