Re: [RFC PATCH v3 3/3] x86/hvm: Introduce Xen-wide ASID allocator

[Jan Beulich <jbeulich@xxxxxxxx>]

On 29.08.2025 16:13, Teddy Astie wrote:
> Le 28/08/2025 à 15:05, Jan Beulich a écrit :
>> On 26.06.2025 16:01, Teddy Astie wrote:
>>> Is it possible to have multiples vCPUs of a same domain simultaneously
>>> scheduled on top of a single pCPU ? If so, it would need a special
>>> consideration for this corner case, such as we don't miss a TLB flush
>>> in such cases.
>>
>> No, how would two entities be able to run on a single pCPU at any single
>> point in time?
>>
> 
> It was more concerning regarding having 2 vCPUs of the same domain (thus 
> sharing the same ASID) running consecutively, e.g having on the same core
>    dom1.vcpu1 -> dom1.vcpu2
> 
> without a appropriate TLB flush; because the address space may not be 
> consistent between 2 vCPUs.
> 
> I found a approach to fix it by tracking per domain which vCPU last ran 
> on each pCPU so that in case of mismatch, we need to TLB flush. Along 
> with explictely flush the TLB when the vCPU is migrated, because in the 
> case too the TLB can be inconsistent for the ASID.

Yet that wants constraining to the case where the address spaces are indeed
at risk of being different, i.e. when distinct P2Ms are in use on the two
vCPU-s.

>>> I get various stability when testing shadow paging in these patches, unsure
>>> what's the exact root case. HAP works perfectly fine though.
>>>
>>> TODO:
>>> - Intel: Don't assign the VPID at each VMENTER, though we need
>>>    to rethink how we manage VMCS with nested virtualization / altp2m
>>>    for changing this behavior.
>>> - AMD: Consider hot-plug of CPU with ERRATA_170. (is it possible ?)
>>> - Consider cases where we don't have enough ASIDs (e.g Xen as nested guest)
>>> - Nested virtualization ASID management
>>
>> For these last two points - maybe we really need a mixed model?
>>
> 
> Mixed model would not allow future support for broadcast TLB 
> invalidation (even for hypervisor use) with e.g AMD INVLPGB or (future) 
> Intel Remote Action Request.

Why? For a VM using the traditional model we wouldn't be able to leverage
those, but for others we could. And imo it's better to be able to run a VM
at all, even if not with all possible accelerations, than to refuse running
it.

Jan