On 25/03/25 19:41, Jann Horn wrote: > On Tue, Mar 25, 2025 at 6:52 PM Valentin Schneider <vschn...@redhat.com> > wrote: >> On 20/02/25 09:38, Dave Hansen wrote: >> > But, honestly, I'm still not sure this is worth all the trouble. If >> > folks want to avoid IPIs for TLB flushes, there are hardware features >> > that *DO* that. Just get new hardware instead of adding this complicated >> > pile of software that we have to maintain forever. In 10 years, we'll >> > still have this software *and* 95% of our hardware has the hardware >> > feature too. >> >> Sorry, you're going to have to deal with my ignorance a little bit longer... >> >> Were you thinking x86 hardware specifically, or something else? >> AIUI things like arm64's TLBIVMALLE1IS can do what is required without any >> IPI: >> >> C5.5.78 >> """ >> The invalidation applies to all PEs in the same Inner Shareable shareability >> domain as the PE that >> executes this System instruction. >> """ >> >> But for (at least) these architectures: >> >> alpha >> x86 >> loongarch >> mips >> (non-freescale 8xx) powerpc >> riscv >> xtensa >> >> flush_tlb_kernel_range() has a path with a hardcoded use of on_each_cpu(), >> so AFAICT for these the IPIs will be sent no matter the hardware. > > On X86, both AMD and Intel have some fairly recently introduced CPU > features that can shoot down TLBs remotely. > > The patch series > <https://lore.kernel.org/all/20250226030129.530345-1-r...@surriel.com/> > adds support for the AMD flavor; that series landed in the current > merge window (it's present in the mainline git repository now and should > be part of 6.15). I think support for the Intel flavor has not yet > been implemented, but the linked patch series mentions a plan to look > at the Intel flavor next.
Thanks for the info!
