Re: [PATCH] x86/hvm: Allow supplying a dynamic start ASID

[Vaishali Thakkar <vaishali.thakkar@vates.tech>]

On 4/16/24 4:25 PM, Vaishali Thakkar wrote:
> On 4/16/24 4:12 PM, Andrew Cooper wrote:
>> On 16/04/2024 9:54 am, Vaishali Thakkar wrote:
>>> Currently, Xen always starts the ASID allocation at 1. But
>>> for SEV technologies the ASID space is divided. This is
>>> because it's a security issue if a guest is started as
>>> ES/SNP and is migrated to SEV-only. So, the types are
>>> tracked explicitly.
>>>
>>> Thus, in preparation of SEV support in Xen, add min_asid
>>> to allow supplying the dynamic start ASID during the
>>> allocation process.
>>>
>>> Signed-off-by: Vaishali Thakkar <vaishali.thakkar@vates.tech>
>>
>> Mechanically, this is fine, but is it going to be useful in the long term?
>>
>> For SEV and SEV-ES/SNP, we must run the VM in the single fixed ASID
>> negotiated with the ASP.  This is not not optional.
>>
>> For non-encrypted VMs, we are free to choose between using the remaining
>> ASID space as we used to (i.e. run it per-pCPU and tick it over to flush
>> the TLBs), or to run it in a fixed ASID per guest too.
>>
>> The latter lets us use INVLPGB, and would avoid maintaining two
>> different TLB-tagging schemes.
>>
>>
>> I'd say that we absolutely do want INVLPGB support for managing
>> non-encrypted VMs, and we cannot mix both fixed and floating ASIDs at
>> the same time.
>
> I agree that having a both schemes at the time is not practical. And I've
> some RFC patches in work to propose fixed ASID scheme for all domains
> (encrypted or not) to start a discussion regarding that.
>
> IMO, this patch is still useful because my idea was to then use min_asid
> as a holder to separate out the non-encrypted, encrypted space and SEV ES/
> SNP ASID space. If it's more easier to see the usefulness of this patch
> along with other asid fixes, I'm fine with putting it in that RFC patchset.
> But I thought that this change was independent enough to be sent by
> itself.

s/encrypted/SEV

>> We should seriously consider whether it's worth maintaining two schemes,
>> or just switching wholesale to a fixed ASID scheme.
>>
>> I don't have a good answer here...  If it where anything but TLB
>> flushing, it would be an obvious choice, but TLB handling bugs are some
>> of the nastiest to show up.
>>
>> ~Andrew
>
>