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