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