Message ID | 20230207072902.5528-6-jgross@suse.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp2708575wrn; Mon, 6 Feb 2023 23:52:03 -0800 (PST) X-Google-Smtp-Source: AK7set+sBZrTjjqPiSHyjPAMitenxxcg+Zc8ak66SJ95sErF9fclMzrWbSuNi/AFT/8aBxc66Kqt X-Received: by 2002:a17:907:9b09:b0:88d:ba89:184e with SMTP id kn9-20020a1709079b0900b0088dba89184emr18698264ejc.31.1675756323145; Mon, 06 Feb 2023 23:52:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1675756323; cv=none; d=google.com; s=arc-20160816; b=YF/gPK/BihahJlg/XvDsPfd6lUbPCJuq8IcsnFp7xFeqG2aq7b601E0WWktTOLh/Ip Atu2Io/8teTHVFOUVHMNOM2c18Vq2xTIL58pbGf+8CDLu012Tg82E+J8TYnh9x9hYHcU XbuIzMX9vTsdkvHjbT7GuceI+dXobnR36bx3VuNGp8m7ch1IbAjtDaX0gVwCW16qb6XJ XDt181UtchzHI4SdoG9QdeFak4PM+2/Kiszipub29FkulgtD/pGcWpRQSnvt1tsKJ6MM t66rNzN1DmbF2h6g83E2Tp7YuHlw6MVX5xS/ffY8JirJh7agVhiFV32aAB9Vd/DSOWA/ HdFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=JQKD/lPKkbb0qc+8vhUXutdmkqWMq0MqdsxYYVlo8yw=; b=ZEa1iTLx2mnNYNHx9Uq7DaAfEhpHJbDr4xJf5H8Ask2lO4OZsC/ou3yy2ndt8Wq5/1 0gcXUDQ7ttAUjHat04+nsPFMYEexExAR3I804XkfYR7zU9ZODDzE3p7oovXTbeJZAwMk kbHKt7Qjw7c80YnIxJ19vcCeAXJ1xXFvYbXShUbuioShEwB6QoZpLV0xFuDWTWPidt/1 OdmhhpzaIrB0MXKrEeka6nwRgogD2UJvxBzwm5cZrBdiQOXH8w0SeEoHzb6GnvVEM4Rs LTKfs8APO1QCAbGwYlzPfGe0V45KSkzQOldeanu943CDmQf/2l1odJ5tgdpqPLikvUwG Id3g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=rhN5jlM6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id cj22-20020a17090715d600b008a6109abff5si4275219ejc.815.2023.02.06.23.51.40; Mon, 06 Feb 2023 23:52:03 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=rhN5jlM6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230191AbjBGH35 (ORCPT <rfc822;kmanaouilinux@gmail.com> + 99 others); Tue, 7 Feb 2023 02:29:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54194 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230203AbjBGH3n (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 7 Feb 2023 02:29:43 -0500 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1E88B37B59 for <linux-kernel@vger.kernel.org>; Mon, 6 Feb 2023 23:29:35 -0800 (PST) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id AD38333E13; Tue, 7 Feb 2023 07:29:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1675754973; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JQKD/lPKkbb0qc+8vhUXutdmkqWMq0MqdsxYYVlo8yw=; b=rhN5jlM6O0ZsxdaBTemQtSJgkBZPcxAZaNNtQJLq5Ihc0NbsHPi20j4I7fjRtIto2K4d4X zIDf3658nAGwSKwguO4O/FDqknFHsNoGM589ogc/tD0JkZ0n9T3dret8xtcVctvZFUQg5h qphoyoKo95W/LGOBbq3SIF1tfcz1TUM= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 54F1713A8C; Tue, 7 Feb 2023 07:29:33 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 83VgE9394WPaUQAAMHmgww (envelope-from <jgross@suse.com>); Tue, 07 Feb 2023 07:29:33 +0000 From: Juergen Gross <jgross@suse.com> To: linux-kernel@vger.kernel.org, x86@kernel.org Cc: lists@nerdbynature.de, mikelley@microsoft.com, torvalds@linux-foundation.org, Juergen Gross <jgross@suse.com>, Dave Hansen <dave.hansen@linux.intel.com>, Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com> Subject: [PATCH 5/6] x86/mm: only check uniform after calling mtrr_type_lookup() Date: Tue, 7 Feb 2023 08:29:01 +0100 Message-Id: <20230207072902.5528-6-jgross@suse.com> X-Mailer: git-send-email 2.35.3 In-Reply-To: <20230207072902.5528-1-jgross@suse.com> References: <20230207072902.5528-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1757157862121588389?= X-GMAIL-MSGID: =?utf-8?q?1757157862121588389?= |
Series |
x86/mtrr: fix handling with PAT but without MTRR
|
|
Commit Message
Juergen Gross
Feb. 7, 2023, 7:29 a.m. UTC
Today pud_set_huge() and pmd_set_huge() test for the MTRR type to be
WB or INVALID after calling mtrr_type_lookup(). Those tests can be
dropped, as the only reason to not use a large mapping would be
uniform being 0. Any MTRR type can be accepted as long as it applies
to the whole memory range covered by the mapping, as the alternative
would only be to map the same region with smaller pages instead using
the same PAT type as for the large mapping.
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Juergen Gross <jgross@suse.com>
---
arch/x86/mm/pgtable.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
Comments
On Tue, Feb 07, 2023 at 08:29:01AM +0100, Juergen Gross wrote: > Today pud_set_huge() and pmd_set_huge() test for the MTRR type to be > WB or INVALID after calling mtrr_type_lookup(). Those tests can be > dropped, as the only reason to not use a large mapping would be > uniform being 0. Any MTRR type can be accepted as long as it applies > to the whole memory range covered by the mapping, as the alternative > would only be to map the same region with smaller pages instead using > the same PAT type as for the large mapping. > > Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> > Signed-off-by: Juergen Gross <jgross@suse.com> > --- > arch/x86/mm/pgtable.c | 6 ++---- > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c > index e4f499eb0f29..7b9c5443d176 100644 > --- a/arch/x86/mm/pgtable.c > +++ b/arch/x86/mm/pgtable.c > @@ -721,8 +721,7 @@ int pud_set_huge(pud_t *pud, phys_addr_t addr, pgprot_t prot) > u8 mtrr, uniform; > > mtrr = mtrr_type_lookup(addr, addr + PUD_SIZE, &uniform); > - if ((mtrr != MTRR_TYPE_INVALID) && (!uniform) && > - (mtrr != MTRR_TYPE_WRBACK)) > + if (!uniform) > return 0; > > /* Bail out if we are we on a populated non-leaf entry: */ > @@ -748,8 +747,7 @@ int pmd_set_huge(pmd_t *pmd, phys_addr_t addr, pgprot_t prot) > u8 mtrr, uniform; > > mtrr = mtrr_type_lookup(addr, addr + PMD_SIZE, &uniform); > - if ((mtrr != MTRR_TYPE_INVALID) && (!uniform) && > - (mtrr != MTRR_TYPE_WRBACK)) { > + if (!uniform) { > pr_warn_once("%s: Cannot satisfy [mem %#010llx-%#010llx] with a huge-page mapping due to MTRR override.\n", > __func__, addr, addr + PMD_SIZE); > return 0; > -- See my reply here: https://lore.kernel.org/all/Y+DLqV5MfuBJRnb6@zn.tnic I understand it as WB is ok, for example, even if not uniform. That thing in mtrr_type_lookup(): /* * Look up the fixed ranges first, which take priority over * the variable ranges. */ if ((start < 0x100000) && (mtrr_state.have_fixed) && (mtrr_state.enabled & MTRR_STATE_MTRR_FIXED_ENABLED)) { is_uniform = 0; type = mtrr_type_lookup_fixed(start, end); goto out; } If that can return WB, then I guess that says it is still ok. Can the fixed ranges even cover a, at least a PMD? I guess I need to stare at this more. Lemme add Toshi who authored that code - he might have a comment or two. Thx.
On 07.02.23 12:42, Borislav Petkov wrote: > On Tue, Feb 07, 2023 at 08:29:01AM +0100, Juergen Gross wrote: >> Today pud_set_huge() and pmd_set_huge() test for the MTRR type to be >> WB or INVALID after calling mtrr_type_lookup(). Those tests can be >> dropped, as the only reason to not use a large mapping would be >> uniform being 0. Any MTRR type can be accepted as long as it applies >> to the whole memory range covered by the mapping, as the alternative >> would only be to map the same region with smaller pages instead using >> the same PAT type as for the large mapping. >> >> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> >> Signed-off-by: Juergen Gross <jgross@suse.com> >> --- >> arch/x86/mm/pgtable.c | 6 ++---- >> 1 file changed, 2 insertions(+), 4 deletions(-) >> >> diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c >> index e4f499eb0f29..7b9c5443d176 100644 >> --- a/arch/x86/mm/pgtable.c >> +++ b/arch/x86/mm/pgtable.c >> @@ -721,8 +721,7 @@ int pud_set_huge(pud_t *pud, phys_addr_t addr, pgprot_t prot) >> u8 mtrr, uniform; >> >> mtrr = mtrr_type_lookup(addr, addr + PUD_SIZE, &uniform); >> - if ((mtrr != MTRR_TYPE_INVALID) && (!uniform) && >> - (mtrr != MTRR_TYPE_WRBACK)) >> + if (!uniform) >> return 0; >> >> /* Bail out if we are we on a populated non-leaf entry: */ >> @@ -748,8 +747,7 @@ int pmd_set_huge(pmd_t *pmd, phys_addr_t addr, pgprot_t prot) >> u8 mtrr, uniform; >> >> mtrr = mtrr_type_lookup(addr, addr + PMD_SIZE, &uniform); >> - if ((mtrr != MTRR_TYPE_INVALID) && (!uniform) && >> - (mtrr != MTRR_TYPE_WRBACK)) { >> + if (!uniform) { >> pr_warn_once("%s: Cannot satisfy [mem %#010llx-%#010llx] with a huge-page mapping due to MTRR override.\n", >> __func__, addr, addr + PMD_SIZE); >> return 0; >> -- > > See my reply here: > > https://lore.kernel.org/all/Y+DLqV5MfuBJRnb6@zn.tnic > > I understand it as WB is ok, for example, even if not uniform. That > thing in mtrr_type_lookup(): > > /* > * Look up the fixed ranges first, which take priority over > * the variable ranges. > */ > if ((start < 0x100000) && > (mtrr_state.have_fixed) && > (mtrr_state.enabled & MTRR_STATE_MTRR_FIXED_ENABLED)) { > is_uniform = 0; > type = mtrr_type_lookup_fixed(start, end); > goto out; > } > > If that can return WB, then I guess that says it is still ok. Can the > fixed ranges even cover a, at least a PMD? I guess I need to stare at > this more. Fixed MTRRs are all below 1MB. So no, they can't cover a PMD. Juergen
On Tue, Feb 07, 2023 at 12:54:53PM +0100, Juergen Gross wrote:
> Fixed MTRRs are all below 1MB. So no, they can't cover a PMD.
Good, belongs in the commit message.
And we need more code staring like this to make sure nothing else
breaks. As said, upsetting the universe is not easy.
Thx.
On 07.02.23 12:42, Borislav Petkov wrote: > On Tue, Feb 07, 2023 at 08:29:01AM +0100, Juergen Gross wrote: > > Today pud_set_huge() and pmd_set_huge() test for the MTRR type to be > > WB or INVALID after calling mtrr_type_lookup(). Those tests can be > > dropped, as the only reason to not use a large mapping would be > > uniform being 0. Any MTRR type can be accepted as long as it applies > > to the whole memory range covered by the mapping, as the alternative > > would only be to map the same region with smaller pages instead using > > the same PAT type as for the large mapping. : > Lemme add Toshi who authored that code - he might have a comment or > two. The current mtrr_type_look() does not set 'uniform' for MTRR_TYPE_INVALID. Please also update it to set 'uniform', if not done in other patches. Toshi
diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c index e4f499eb0f29..7b9c5443d176 100644 --- a/arch/x86/mm/pgtable.c +++ b/arch/x86/mm/pgtable.c @@ -721,8 +721,7 @@ int pud_set_huge(pud_t *pud, phys_addr_t addr, pgprot_t prot) u8 mtrr, uniform; mtrr = mtrr_type_lookup(addr, addr + PUD_SIZE, &uniform); - if ((mtrr != MTRR_TYPE_INVALID) && (!uniform) && - (mtrr != MTRR_TYPE_WRBACK)) + if (!uniform) return 0; /* Bail out if we are we on a populated non-leaf entry: */ @@ -748,8 +747,7 @@ int pmd_set_huge(pmd_t *pmd, phys_addr_t addr, pgprot_t prot) u8 mtrr, uniform; mtrr = mtrr_type_lookup(addr, addr + PMD_SIZE, &uniform); - if ((mtrr != MTRR_TYPE_INVALID) && (!uniform) && - (mtrr != MTRR_TYPE_WRBACK)) { + if (!uniform) { pr_warn_once("%s: Cannot satisfy [mem %#010llx-%#010llx] with a huge-page mapping due to MTRR override.\n", __func__, addr, addr + PMD_SIZE); return 0;