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

[Vaishali Thakkar <vaishali.thakkar@xxxxxxxxxx>]

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

> 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