On 12/25/24 08:48, Rik van Riel wrote: > On Tue, 2024-12-24 at 18:08 +0000, Michael Kelley wrote: >> From: riel@xxxxxxxxxxx <riel@xxxxxxxxxxx> 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 :) Note that global ASIDs (relative to VMs) are different from the broadcast ASIDs being used here. IIUC, the broadcast ASIDs here get translated to a PCID value (kern_pcid(asid) or user_pcid(asid) in patch #9). Thanks, Tom > >
