Received: by 2002:a05:7412:cfc7:b0:fc:a2b0:25d7 with SMTP id by7csp1054366rdb; Mon, 19 Feb 2024 02:50:10 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCU3kWXEB2MxsrOImxhzoaZ69yE01noVCwk81/Yv6ATY8G69mNv0Qfylu9zwk3yskYiSOaE8BDWcy/fy2v/x1VYrlymXtHZwmB8l/3VfPg== X-Google-Smtp-Source: AGHT+IG5MXnT4uXMPdj8sj1du2nziuu1Eyp7fA8ppbzittHlfIv3LtL9koU6RIeqIYZNyqsBWj7t X-Received: by 2002:a17:906:b28c:b0:a3e:59e5:afb9 with SMTP id q12-20020a170906b28c00b00a3e59e5afb9mr2395381ejz.60.1708339810311; Mon, 19 Feb 2024 02:50:10 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708339810; cv=pass; d=google.com; s=arc-20160816; b=CKGswg8Wl7sWeGElHj2REY1YuD+wEQlvkT1t+ikwt1uX3YQk99EHepA8tYD8iXndJl M3NEapGRAGpKzUPzbd5vz2k72pgtinKk8UQKkMOTafS1VAH5KaIZrJ+WLydu4QSBMsND ftB8zsRyfgy7DrnrmmRI+TDV2xgTRoOjVmtOZZSwKhj++pzRgLbCeC+GfZcFxe/ywRjB atFqIhjbnWolYNHK++2sJ55yN4PGn7UrJJga5ktZ5MNQgHtGJWkEhJWPKhFLYgB8s4Bu No0L6rwwWwCRdyhMc0jABU86JmS8mdp1Fm2fId1k+ZsZj6CWaw/IZSj97+GzGZsCpCKW RTbg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :dkim-signature; bh=4MQJOsm12yyUfLXP8/4qqlhf10T9ODzbVu9qmdeeCKA=; fh=WpoxhhvNIEBLVNEyWRFCc3wZp7tnXwZtmTg2yZK0L1M=; b=llZnGzM5pp3AKPe67z6waQLk1tSpUc8vCOXpC8rID09PlkFFF2+pky1mQEMhF9jwF1 qxLlg1+FUnW2zbfiruaGJcp7c4CxZkYG2lpwkQ+2FswkYAfyZmv+wojeeuQFefSbvG5B uIwFvwcpu7sfruQs006ZY1yptR2lVJmeUyewi6ZE1qNJSjdb6qX8oVkNJ0CNiiTlFBB7 Vb+FQHWfhNp2zVnoJk+dTl0SnwTKvkxd0CmURQPxBhk9CoTN8MUeHBrFZbt7LPg1tWUj 3iEINh4d9O31y6SMLPdB7SbJRcpWQmLGXweShhn568vXWGHv08X7VFC45VDeoBFR6TjO W5bw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=2hEFR4fx; arc=pass (i=1 spf=pass spfdomain=google.com dkim=pass dkdomain=google.com dmarc=pass fromdomain=google.com); spf=pass (google.com: domain of linux-kernel+bounces-71148-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-71148-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id i23-20020a170906091700b00a3ed86dc13bsi23965ejd.265.2024.02.19.02.50.10 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Feb 2024 02:50:10 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-71148-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=2hEFR4fx; arc=pass (i=1 spf=pass spfdomain=google.com dkim=pass dkdomain=google.com dmarc=pass fromdomain=google.com); spf=pass (google.com: domain of linux-kernel+bounces-71148-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-71148-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id DDDF61F222C7 for ; Mon, 19 Feb 2024 10:50:09 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 8EB2A28DD2; Mon, 19 Feb 2024 10:50:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="2hEFR4fx" Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 013B928DAE for ; Mon, 19 Feb 2024 10:49:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708339801; cv=none; b=RikheSUFMYUPjytg8Xs1zl3rAkGP6tD5k0Z8C8kUErlwjILdusr0QwowDNxDRWVhc2d2UmL6rEZEyto0uBaVLdXzupvkPF71VuRMP7F0wBPQElU67Y1hYK4VLizVD33f54VTYoHtzNWlKnon24JdNddydR1lYIC/mbWW7vQup2g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708339801; c=relaxed/simple; bh=3caDZanIGLjsT+cFQP8A69Yvh0OigCSpUrynDatp140=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=txucsC5e76J2x1xfAb9htMza+mIP++SjFTcGAcPoT3nnjSuI031S0y2Eki8xFJDgviUYb1C/P21WEuuM2JDSY2BQ/19dLHve1tseENA0Wqm7khQS+LmpP+oo2QjM7KGKfmHiiVSBBOY7DNDKJ+V73Y2K6dn4m8ivrKaHAVEW6qE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=2hEFR4fx; arc=none smtp.client-ip=209.85.160.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Received: by mail-qt1-f171.google.com with SMTP id d75a77b69052e-42db1baff53so444541cf.0 for ; Mon, 19 Feb 2024 02:49:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1708339799; x=1708944599; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=4MQJOsm12yyUfLXP8/4qqlhf10T9ODzbVu9qmdeeCKA=; b=2hEFR4fxKnlsFeGEVNr/qv4PQvCyfYvC+d9/8kWNEzk6SKYxPNpWfhf5o5Q1auQyC2 wDgzLGB7UDtRnsjqXZPAu7gRGXLF5DS0lukmMACxeWMmesfyrH0FU5sx7s6GEWU9yZ54 Nx+VXV9nd/K1TFaSlAOTmbWMNdE/RHReLbQKO+XON+g3/ssXHMtxem/0Js91koXwRA+m xcx9WxxpAeRYzDft2w8cJ+dMiw2Wb2CIGtZfT9Bm2R9X2aRjs9j8RseP/wdZLqGFk39K be7xHTi96ld2XWpqCBivxhNBmBi+gxOeIhNRLz2gr1sg7Se4bhY0xqM/pKFngxi0PtYi /Gbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708339799; x=1708944599; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=4MQJOsm12yyUfLXP8/4qqlhf10T9ODzbVu9qmdeeCKA=; b=r2EoRBDZXT1UOQDA1nLvfSfQNqbJ3mgSESZGXKym7UyM4FAgep+cHIDYPdrQ87c4Te 5gk5eCKXJulSTrvkD7519k3xj6W+0rfiQpJDlIDBcHaFfwj+Kiudu/9iGCTi+c4Cj5a7 mWBAfu1hJsJHbOISj1C3kAqdE6tiVlSeWcXM1Y0IbYsaI1LAZd1scIGr3pyW08E7NO2P iRypFgT5qm0MYOPbq4kreXE9WFTj2STWt9CXk3PpiGxjV5NsJyl1fWrizBBahWyZCUXt rjsgZhe7zg06WO4tHGUgRs96183BJ257buFJ8oyNuPMhSGDpKCAjYHFZTgH4Iucn38+K neiQ== X-Gm-Message-State: AOJu0Yzb4Qsk59Vg2kvQondM/jfMsE2pPzh2H6ONSgnDzYb3CiE1m9yb keKhorfMzIT1AZEKv97q6k1gtvCwnvQ8z88uxfcpXMvTQJoUyMvux68Rign3a8SNeJvl6SQ45LD UuO91x8loWxz7AKIO+5lsFhcZvuTwtIUP8r9KSWFabK+ysxJ8xk6m X-Received: by 2002:ac8:5a55:0:b0:42e:16af:b149 with SMTP id o21-20020ac85a55000000b0042e16afb149mr112959qta.26.1708339798691; Mon, 19 Feb 2024 02:49:58 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20240108113950.360438-1-jackmanb@google.com> <170612139384.398.13715690088153668463.tip-bot2@tip-bot2> In-Reply-To: <170612139384.398.13715690088153668463.tip-bot2@tip-bot2> From: Brendan Jackman Date: Mon, 19 Feb 2024 11:49:46 +0100 Message-ID: Subject: Re: [tip: x86/entry] x86/entry: Avoid redundant CR3 write on paranoid returns To: linux-kernel@vger.kernel.org Cc: linux-tip-commits@vger.kernel.org, Lai Jiangshan , Thomas Gleixner , x86@kernel.org, Kevin Cheng , Yosry Ahmed Content-Type: text/plain; charset="UTF-8" [Apologies if you see this as a duplicate, accidentally sent the original in HTML, please disregard the other one] Hi Thomas, I have just noticed that the commit has disappeared from tip/x86/entry. Is that deliberate? Thanks, Brendan On Wed, 24 Jan 2024 at 19:36, tip-bot2 for Lai Jiangshan wrote: > > The following commit has been merged into the x86/entry branch of tip: > > Commit-ID: bb998361999e79bc87dae1ebe0f5bf317f632585 > Gitweb: https://git.kernel.org/tip/bb998361999e79bc87dae1ebe0f5bf317f632585 > Author: Lai Jiangshan > AuthorDate: Mon, 08 Jan 2024 11:39:50 > Committer: Thomas Gleixner > CommitterDate: Wed, 24 Jan 2024 13:57:59 +01:00 > > x86/entry: Avoid redundant CR3 write on paranoid returns > > The CR3 restore happens in: > > 1. #NMI return. > 2. paranoid_exit() (i.e. #MCE, #VC, #DB and #DF return) > > Contrary to the implication in commit 21e94459110252 ("x86/mm: Optimize > RESTORE_CR3"), the kernel never modifies CR3 in any of these exceptions, > except for switching from user to kernel pagetables under PTI. That > means that most of the time when returning from an exception that > interrupted the kernel no CR3 restore is necessary. Writing CR3 is > expensive on some machines. > > Most of the time because the interrupt might have come during kernel entry > before the user to kernel CR3 switch or the during exit after the kernel to > user switch. In the former case skipping the restore would be correct, but > definitely not for the latter. > > So check the saved CR3 value and restore it only, if it is a user CR3. > > Give the macro a new name to clarify its usage, and remove a comment that > was describing the original behaviour along with the not longer needed jump > label. > > Signed-off-by: Lai Jiangshan > Signed-off-by: Brendan Jackman > Signed-off-by: Thomas Gleixner > Link: https://lore.kernel.org/r/20240108113950.360438-1-jackmanb@google.com > > [Rewrote commit message; responded to review comments] > Change-Id: I6e56978c4753fb943a7897ff101f519514fa0827 > --- > arch/x86/entry/calling.h | 26 ++++++++++---------------- > arch/x86/entry/entry_64.S | 7 +++---- > 2 files changed, 13 insertions(+), 20 deletions(-) > > diff --git a/arch/x86/entry/calling.h b/arch/x86/entry/calling.h > index 9f1d947..92dca4a 100644 > --- a/arch/x86/entry/calling.h > +++ b/arch/x86/entry/calling.h > @@ -239,17 +239,19 @@ For 32-bit we have the following conventions - kernel is built with > .Ldone_\@: > .endm > > -.macro RESTORE_CR3 scratch_reg:req save_reg:req > +/* Restore CR3 from a kernel context. May restore a user CR3 value. */ > +.macro PARANOID_RESTORE_CR3 scratch_reg:req save_reg:req > ALTERNATIVE "jmp .Lend_\@", "", X86_FEATURE_PTI > > - ALTERNATIVE "jmp .Lwrcr3_\@", "", X86_FEATURE_PCID > - > /* > - * KERNEL pages can always resume with NOFLUSH as we do > - * explicit flushes. > + * If CR3 contained the kernel page tables at the paranoid exception > + * entry, then there is nothing to restore as CR3 is not modified while > + * handling the exception. > */ > bt $PTI_USER_PGTABLE_BIT, \save_reg > - jnc .Lnoflush_\@ > + jnc .Lend_\@ > + > + ALTERNATIVE "jmp .Lwrcr3_\@", "", X86_FEATURE_PCID > > /* > * Check if there's a pending flush for the user ASID we're > @@ -257,20 +259,12 @@ For 32-bit we have the following conventions - kernel is built with > */ > movq \save_reg, \scratch_reg > andq $(0x7FF), \scratch_reg > - bt \scratch_reg, THIS_CPU_user_pcid_flush_mask > - jnc .Lnoflush_\@ > - > btr \scratch_reg, THIS_CPU_user_pcid_flush_mask > - jmp .Lwrcr3_\@ > + jc .Lwrcr3_\@ > > -.Lnoflush_\@: > SET_NOFLUSH_BIT \save_reg > > .Lwrcr3_\@: > - /* > - * The CR3 write could be avoided when not changing its value, > - * but would require a CR3 read *and* a scratch register. > - */ > movq \save_reg, %cr3 > .Lend_\@: > .endm > @@ -285,7 +279,7 @@ For 32-bit we have the following conventions - kernel is built with > .endm > .macro SAVE_AND_SWITCH_TO_KERNEL_CR3 scratch_reg:req save_reg:req > .endm > -.macro RESTORE_CR3 scratch_reg:req save_reg:req > +.macro PARANOID_RESTORE_CR3 scratch_reg:req save_reg:req > .endm > > #endif > diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S > index c40f89a..aedd169 100644 > --- a/arch/x86/entry/entry_64.S > +++ b/arch/x86/entry/entry_64.S > @@ -968,14 +968,14 @@ SYM_CODE_START_LOCAL(paranoid_exit) > IBRS_EXIT save_reg=%r15 > > /* > - * The order of operations is important. RESTORE_CR3 requires > + * The order of operations is important. PARANOID_RESTORE_CR3 requires > * kernel GSBASE. > * > * NB to anyone to try to optimize this code: this code does > * not execute at all for exceptions from user mode. Those > * exceptions go through error_return instead. > */ > - RESTORE_CR3 scratch_reg=%rax save_reg=%r14 > + PARANOID_RESTORE_CR3 scratch_reg=%rax save_reg=%r14 > > /* Handle the three GSBASE cases */ > ALTERNATIVE "jmp .Lparanoid_exit_checkgs", "", X86_FEATURE_FSGSBASE > @@ -1404,8 +1404,7 @@ end_repeat_nmi: > /* Always restore stashed SPEC_CTRL value (see paranoid_entry) */ > IBRS_EXIT save_reg=%r15 > > - /* Always restore stashed CR3 value (see paranoid_entry) */ > - RESTORE_CR3 scratch_reg=%r15 save_reg=%r14 > + PARANOID_RESTORE_CR3 scratch_reg=%r15 save_reg=%r14 > > /* > * The above invocation of paranoid_entry stored the GSBASE