Re: [PATCH v13 06/14] x86/mm: use broadcast TLB flushing for page reclaim TLB flushing

Tom Lendacky
2025-02-28T15:02:27Z

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

>