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

[Sean Christopherson <seanjc@google.com>]

On Fri, Feb 28, 2025, 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 :(

KVM's mess of ASID handling isn't due to space limitations, it's because early
AMD hardware didn't support a targeted ASID flush.  To avoid flushing the entire
TLB, KVM fudged around lack of precise flushing by using a new ASID.  Under the
hood, hardware uses the new ASID so the previous entries are effectively"flushed",
and will eventually be flushed for real once their evicted due to TLB pressure.

Irrespective of INVLPGB support, I am all in favor of ripping out the ASID
shenanigans in favor of static, per-VM ASIDs for all VM types.  For CPUs that
don't support FLUSHBYASID, KVM can simply blast TLB_CONTROL_FLUSH_ALL_ASID.

FLUSHBYASID was added ~15 years ago.  If someone is still running hardware that's
that old, they can't possibly care about performance.

That would meaningfuly simplify KVM code, likely be a performance win on modern
hardware, and gives us direct line of sight to using INVLPGB (assuming it's a
performance win).
 
> Right, to support using INVLPGB in guests you need a global ASID, 

I'm pretty sure Rik is talking about using INVLPGB in the _host_, e.g. by doing
INVLPGB in kvm_arch_flush_remote_tlbs() instead of blasing an IPI to all vCPUs.