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

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




Reply via email to