Message-ID: <4b562cd0-7500-4b3a-8f5c-e6acfea2896e@intel.com>
Date: Thu, 21 Nov 2024 07:07:44 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Peter Zijlstra <peterz@...radead.org>,
 Valentin Schneider <vschneid@...hat.com>
Cc: linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
 kvm@...r.kernel.org, linux-mm@...ck.org, bpf@...r.kernel.org,
 x86@...nel.org, rcu@...r.kernel.org, linux-kselftest@...r.kernel.org,
 Steven Rostedt <rostedt@...dmis.org>, Masami Hiramatsu
 <mhiramat@...nel.org>, Jonathan Corbet <corbet@....net>,
 Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
 Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
 "H. Peter Anvin" <hpa@...or.com>, Paolo Bonzini <pbonzini@...hat.com>,
 Wanpeng Li <wanpengli@...cent.com>, Vitaly Kuznetsov <vkuznets@...hat.com>,
 Andy Lutomirski <luto@...nel.org>, Frederic Weisbecker
 <frederic@...nel.org>, "Paul E. McKenney" <paulmck@...nel.org>,
 Neeraj Upadhyay <quic_neeraju@...cinc.com>,
 Joel Fernandes <joel@...lfernandes.org>,
 Josh Triplett <josh@...htriplett.org>, Boqun Feng <boqun.feng@...il.com>,
 Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 Lai Jiangshan <jiangshanlai@...il.com>, Zqiang <qiang.zhang1211@...il.com>,
 Andrew Morton <akpm@...ux-foundation.org>,
 Uladzislau Rezki <urezki@...il.com>, Christoph Hellwig <hch@...radead.org>,
 Lorenzo Stoakes <lstoakes@...il.com>, Josh Poimboeuf <jpoimboe@...nel.org>,
 Jason Baron <jbaron@...mai.com>, Kees Cook <keescook@...omium.org>,
 Sami Tolvanen <samitolvanen@...gle.com>, Ard Biesheuvel <ardb@...nel.org>,
 Nicholas Piggin <npiggin@...il.com>,
 Juerg Haefliger <juerg.haefliger@...onical.com>,
 Nicolas Saenz Julienne <nsaenz@...nel.org>,
 "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
 Nadav Amit <namit@...are.com>, Dan Carpenter <error27@...il.com>,
 Chuang Wang <nashuiliang@...il.com>, Yang Jihong <yangjihong1@...wei.com>,
 Petr Mladek <pmladek@...e.com>, "Jason A. Donenfeld" <Jason@...c4.com>,
 Song Liu <song@...nel.org>, Julian Pidancet <julian.pidancet@...cle.com>,
 Tom Lendacky <thomas.lendacky@....com>, Dionna Glaze
 <dionnaglaze@...gle.com>, Thomas Weißschuh
 <linux@...ssschuh.net>, Juri Lelli <juri.lelli@...hat.com>,
 Marcelo Tosatti <mtosatti@...hat.com>, Yair Podemsky <ypodemsk@...hat.com>,
 Daniel Wagner <dwagner@...e.de>, Petr Tesarik <ptesarik@...e.com>
Subject: Re: [RFC PATCH v3 13/15] context_tracking,x86: Add infrastructure to
 defer kernel TLBI

On 11/21/24 03:12, Peter Zijlstra wrote:
>> I see e.g. ds_clear_cea() clears PTEs that can have the _PAGE_GLOBAL flag,
>> and it correctly uses the non-deferrable flush_tlb_kernel_range().
> 
> I always forget what we use global pages for, dhansen might know, but
> let me try and have a look.
> 
> I *think* we only have GLOBAL on kernel text, and that only sometimes.

I think you're remembering how _PAGE_GLOBAL gets used when KPTI is in play.

Ignoring KPTI for a sec... We use _PAGE_GLOBAL for all kernel mappings.
Before PCIDs, global mappings let the kernel TLB entries live across CR3
writes. When PCIDs are in play, global mappings let two different ASIDs
share TLB entries.

When KPTI is around, the kernel writes CR3 at user/kernel switches to
make sure secrets are unmapped and can't be leaked by Meltdown. But
unmapping those secrets doesn't do squat if they were mapped globally
since they'll still be in the TLB and quite usable. There, we're more
judicious and only mark performance-sensitive things that are not secret
to be global, like kernel text.

Powered by blists - more mailing lists