Re: [RFC PATCH v2 00/11] AMD broadcast TLB invalidation

[Rik van Riel <riel@surriel.com>]

On Tue, 2024-12-24 at 18:08 +0000, Michael Kelley wrote:
> From: riel@surriel.com <riel@surriel.com> Sent: Sunday, December 22,
> 2024 6:55 PM
> 
> > 
> > Add support for broadcast TLB invalidation using AMD's INVLPGB
> > instruction.
> 
> > This allows the kernel to invalidate TLB entries on remote CPUs
> > without
> > needing to send IPIs, without having to wait for remote CPUs to
> > handle
> > those interrupts, and with less interruption to what was running on
> > those CPUs.
> > 
> > Because x86 PCID space is limited, and there are some very large
> > systems out there, broadcast TLB invalidation is only used for
> > processes that are active on 3 or more CPUs, with the threshold
> > being gradually increased the more the PCID space gets exhausted.
> 
> Rik --
> 
> What is this patch set's expectation about INVLPGB and TLBSYNC
> availability and usage in a VM? I see that INVLPGB and TLBYSNC
> behavior in a VM is spec'ed in the AMD Programmer's Manual, but
> I wonder about their impact in a multi-tenant host like in a public
> cloud environment. And given what this patch set does in assigning
> global ASIDs, should X86_FEATURE_INVLPGB be disabled if
> running in a VM where the hypervisor for whatever reason has
> enabled INVLPGB/TLBSYNC in its VMs?
> 
This patch series enables bare metal INVLPGB functionality.

Virtual machines should probably not expose the INVPLGB
CPUID feature bit to guests, since virtual machine
invalidation seems to work differently than bare metal
invalidation.

For one, the ASID seems to actually mean something in
SVM context, while trying to use the ASID in bare metal
blows up :)


-- 
All Rights Reversed.