On 2/28/25 09:02, Tom Lendacky wrote: > On 2/27/25 19:13, Rik van Riel wrote: >> On Wed, 2025-02-26 at 12:12 -0600, Tom Lendacky wrote: >>> >>> As long as you keep the ASID value in EDX[15:0] as 0, then you won't >>> #GP. ASID 0 is the host/hypervisor. An ASID > 0 belongs to a guest. >>> >> I've been spending some time reading the KVM code, >> and I don't think invlpgb would be currently useful >> with KVM. >> >> From reading pre_svm_run(), new_asid(), and svm_vcpu_run(), >> it looks like the ASID number used might be different for >> each VCPU, assigned on a per (physical host) CPU basis. >> >> It would take some surgery to change that around. >> >> Some googling around also suggests that the ASID address >> space is even more limited than the PCID address space :( > > Right, to support using INVLPGB in guests you need a global ASID, which is > an ASID that doesn't change over the VMs lifetime and is used on all > vCPUs. Global ASIDs are only available and used today with SEV guests. At > that point you would not intercept the instruction and, based on APM vol > 3, the ASID value is replaced with the guest ASID value. > > "A guest that executes a legal INVLPGB that is not intercepted will have > the requested ASID field replaced by the current ASID and the valid ASID > bit set before doing the broadcast invalidation." > > So I'm in the process of verifying that issuing INVLPLG in a guest with > the ASID valid bit set and an ASID value of 0 (EDX[15:0]) won't #GP, but > will just replace the specified ASID value with the guest ASID value in > hardware. I verified that when (a non-intercepted) INVLPGB is issued in a guest, hardware will set the ASID valid bit and use the guest ASID value (regardless of the value specified in EDX[15:0]) before doing the broadcast invalidation. So the implementation of setting the ASID-valid bit and specifying ASID 0 is not incompatible in the guest. Thanks, Tom > > For non-SEV guests, INVLPGB would need to be intercepted and somehow > emulated or just not advertised to the guest so that the IPI path is used. > > Thanks, > Tom > >>
