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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 16.06.2026 15:46, Teddy Astie wrote:
> 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. 

I fear don't understand this, in particular since you also say ...

> 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).

... this: If they all use the same ASID, why would any tracking be needed?

> 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())

Luckily this is better understandable.

> 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.

Before we settle on any wording, I think it needs to become clear why /
whether such tracking is really needed. It feels fragile to say the
least. Might be best to start with flushing in too many cases, and only
later see about optimizing things.

Jan