linux-kernel - Re: [PATCH 06/12] x86/mm: use INVLPGB for kernel TLB flushes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b6816ade400382185422babbbba39f206f357e9e.camel@surriel.com>
Date: Fri, 10 Jan 2025 11:08:02 -0500
From: Rik van Riel <riel@...riel.com>
To: Dave Hansen <dave.hansen@...el.com>, Nadav Amit <nadav.amit@...il.com>
Cc: the arch/x86 maintainers <x86@...nel.org>, Linux Kernel Mailing List	
 <linux-kernel@...r.kernel.org>, kernel-team@...a.com, Dave Hansen	
 <dave.hansen@...ux.intel.com>, luto@...nel.org, peterz@...radead.org,
 Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
 Borislav Petkov <bp@...en8.de>, "H. Peter Anvin"	 <hpa@...or.com>, Andrew
 Morton <akpm@...ux-foundation.org>, 	zhengqi.arch@...edance.com, "open
 list:MEMORY MANAGEMENT" <linux-mm@...ck.org>
Subject: Re: [PATCH 06/12] x86/mm: use INVLPGB for kernel TLB flushes

On Fri, 2025-01-10 at 07:14 -0800, Dave Hansen wrote:
> On 1/9/25 22:07, Nadav Amit wrote:
> > This is not my reading. I think that this reading assumes that
> > besides
> > the broadcast, some new “range flush” was added to the TLB. My
> > guess
> > is that this not the case, since presumably it would require a
> > different
> > TLB structure (and who does 2 changes at once 😉 ).
> 
> Reading it again, I think you're right.
> 
> The INVLPG and INVLPGB language is too close. It would also _talk_
> about
> invalidating a range rather than just incrementing an address to
> invalidate.
> 
> I think the key thing we need to decide is whether to treat a single
> INVLPGB(stride=8) more like a single INVLPGB or eight INVLPGBs.
> Measuring a bunch of invalidation looks should tell us that.

Would I be wrong to assume that the CPUs have
some optimizations built in to efficiently
execute an invalidation for "everything in a
PCID"?

The "global invalidate" we send does not
zap everything in the TLB, but only the
translations for a single PCID.

I suppose we should measure these things
at some point (after I do the other
cleanups?), because the CPUs may well have
made a bunch of optimizations that we
don't know about.

-- 
All Rights Reversed.