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

[Teddy Astie <teddy.astie@xxxxxxxxxx>]

Le 05/05/2026 à 12:32, Jan Beulich a écrit :
> On 05.05.2026 12:17, Teddy Astie wrote:
> > 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.
> Okay, yet then (as already pointed out) how do you know vCPU0 ran last on
> a given pCPU if after its de-scheduling vCPU1 (of the same domain) was
> put there. Your track record (after de-scheduling vCPU1) will say only
> vCPU1; information on vCPU0 will be lost. Yet then, as also indicated,
> it's not quite clear to me how exactly you mean to leverage this tracking.
The idea is to know which vCPU of the domain the pCPU ASID is holding. 
Hence, we need to know which was the latest running vCPU of the domain 
on a per pCPU basis (now that each domain has it's own unique ASID, and 
each pCPU has its own TLB).
Intermediate vCPUs are not useful, given that the TLB is expected to be 
flushed when switching vCPUs of a same domain (as they share the same ASID).
So overall, we flush the TLB when either :
- switching betweens vCPU of a same domain on a single pCPU
- the vCPU was previously ran elsewhere (this is dealt in patch 3 
through old_cpu != new_cpu check in sched_unit_migrate_finish())
I think the commit description is lacking the "last vCPU" idea.

Would this be better ? :

Introduce last_vcpu which maps each pCPU to the latest vCPU that ran on 
it. This will be used to know whether a TLB flush is required or not
when the pCPU TLB doesn't hold this vCPU state anymore.

> Jan
Teddy

Attachment: OpenPGP_0x660FA9D102CBCFD0.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature