From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A7CC81DC198 for ; Wed, 15 Apr 2026 12:02:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776254574; cv=none; b=jp62kx9ef6ZU/hoYToR7opQXHwq5ZiXLitaxY7Rnk2UrUoleUvfauLFY3BQ49N9uF4jgWGxDQrEwebjenOviABY1FFW6PeMoxG0lkwvi3Xdn3QFmqCrhkQ1ZONSTpGe2Usf2FGe8w8zQa3T/MF/gqqg6r8UfJpTKNXFYp7QLFdw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776254574; c=relaxed/simple; bh=eKpAfFlcF7u1s2jPRNx9CVvNstoHhkqQHcfDi4NbSzY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=YRUsYYtfinvilWu7Tpw8dyDUBNAVhgqUNDcncVni2sGCYYWFzl4MJaOI+sNMlfwS74a4w13pYZAjnj9lbFFbprLu6mYwKbrR8rhCSS5GwTiRwJ6KOqDqgf3B7uJxj98KZAt7GI1WZheuGNLk8ODbgseexjJ2MEVD+HFvPM2uIbk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=dDqaIIub; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="dDqaIIub" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DAF24C19424; Wed, 15 Apr 2026 12:02:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776254574; bh=eKpAfFlcF7u1s2jPRNx9CVvNstoHhkqQHcfDi4NbSzY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=dDqaIIubJna8ZP2jWgq3qJm/LFyOcYl8FNtme5bdPRGBfmajV8Vx55SK8VCZ6epSz cEmE81itZ5YJGUSx474OdIVgCBYgpGHw/yynmBNhQcc7t5mJctJePxrTOvzx4p3UlG 8wMccEaCVlKYf0eEYGMa0w6K+iJqMbOSCYmyfRth0GUKfskAOPXXTmpxOMfYGCqIhW pGl+CfUmgnr3JxAGFoYl4Wy6ZR+zWSAacBk7e9Ya5h7ztpsf/6sAb6dpbOmrdSX4kd +f+3UBwCTMPRRjTeDrEilwjLCuG68pDLJrLjBpe8tWNr68eGM68R0luoAlBlooJbIE tFT5vDJ4aMYqw== Date: Wed, 15 Apr 2026 14:02:51 +0200 From: Frederic Weisbecker To: Valentin Schneider Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Andy Lutomirski , Peter Zijlstra , Arnaldo Carvalho de Melo , Josh Poimboeuf , Paolo Bonzini , Arnd Bergmann , "Paul E. McKenney" , Jason Baron , Steven Rostedt , Ard Biesheuvel , Sami Tolvanen , "David S. Miller" , Neeraj Upadhyay , Joel Fernandes , Josh Triplett , Boqun Feng , Uladzislau Rezki , Mathieu Desnoyers , Mel Gorman , Andrew Morton , Masahiro Yamada , Han Shen , Rik van Riel , Jann Horn , Dan Carpenter , Oleg Nesterov , Juri Lelli , Clark Williams , Tomas Glozar , Yair Podemsky , Marcelo Tosatti , Daniel Wagner , Petr Tesarik , Shrikanth Hegde Subject: Re: [RFC PATCH v8 08/10] x86/mm/pti: Introduce a kernel/user CR3 software signal Message-ID: References: <20260324094801.3092968-1-vschneid@redhat.com> <20260324094801.3092968-9-vschneid@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260324094801.3092968-9-vschneid@redhat.com> Le Tue, Mar 24, 2026 at 10:47:59AM +0100, Valentin Schneider a écrit : > Later commits will rely on being able to check whether a remote CPU is > using the kernel or the user CR3. > > This software signal needs to be updated before the actual CR3 write, IOW > it always immediately precedes it: > > KERNEL_CR3_LOADED := 1 > SWITCH_TO_KERNEL_CR3 > [...] > KERNEL_CR3_LOADED := 0 > SWITCH_TO_USER_CR3 > > The variable also gets mapped into the user space visible pages. > I tried really hard not to do that, and at some point had something mostly > working with having an alias to it through the cpu_entry_area accessed like > so before the switch to the kernel CR3: > > subq $10, %rsp > sgdt (%rsp) > movq 2(%rsp), \scratch_reg /* GDT address */ > addq $10, %rsp > > movl $1, CPU_ENTRY_AREA_kernel_cr3(\scratch_reg) > > however this explodes when running 64-bit user code that invokes SYSCALL, > since the scratch reg is %rsp itself, and I figured this was enough headaches. > > This will only be really useful for NOHZ_FULL CPUs, but it should be > cheaper to unconditionally update a never-used per-CPU variable living in > its own cacheline than to check a shared cpumask such as > housekeeping_cpumask(HK_TYPE_KERNEL_NOISE) > at every entry. > > Signed-off-by: Valentin Schneider > --- > arch/x86/Kconfig | 14 +++++++++++++ > arch/x86/entry/calling.h | 13 ++++++++++++ > arch/x86/entry/syscall_64.c | 4 ++++ > arch/x86/include/asm/tlbflush.h | 3 +++ > arch/x86/mm/pti.c | 36 ++++++++++++++++++++++----------- > 5 files changed, 58 insertions(+), 12 deletions(-) > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 80527299f859a..f680e83cd5962 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -2192,6 +2192,20 @@ config ADDRESS_MASKING > The capability can be used for efficient address sanitizers (ASAN) > implementation and for optimizations in JITs. > > +config TRACK_CR3 > + def_bool n > + prompt "Track which CR3 is in use" > + depends on X86_64 && MITIGATION_PAGE_TABLE_ISOLATION && NO_HZ_FULL > + help > + This option adds a software signal that allows checking remotely > + whether a CPU is using the user or the kernel page table. > + > + This allows further optimizations for NOHZ_FULL CPUs. > + > + This obviously makes the user<->kernel transition overhead even worse. > + > + If unsure, say N. > + > config HOTPLUG_CPU > def_bool y > depends on SMP > diff --git a/arch/x86/entry/calling.h b/arch/x86/entry/calling.h > index 77e2d920a6407..4099b7d86efd9 100644 > --- a/arch/x86/entry/calling.h > +++ b/arch/x86/entry/calling.h > @@ -9,6 +9,7 @@ > #include > #include > #include > +#include > > /* > > @@ -170,8 +171,17 @@ For 32-bit we have the following conventions - kernel is built with > andq $(~PTI_USER_PGTABLE_AND_PCID_MASK), \reg > .endm > > +.macro NOTE_CR3_SWITCH scratch_reg:req in_kernel:req > +#ifdef CONFIG_TRACK_CR3 > + STATIC_BRANCH_FALSE_LIKELY housekeeping_overridden, .Lend_\@ > + movl \in_kernel, PER_CPU_VAR(kernel_cr3_loaded) Does this need full ordering of some sort? Like this should be LOCK xadd ? Thanks. -- Frederic Weisbecker SUSE Labs