From: Toshi Kani <toshi.kani@hp.com>
To: Borislav Petkov <bp@alien8.de>
Cc: akpm@linux-foundation.org, hpa@zytor.com, tglx@linutronix.de,
mingo@redhat.com, linux-mm@kvack.org, x86@kernel.org,
linux-kernel@vger.kernel.org, dave.hansen@intel.com,
Elliott@hp.com, pebolle@tiscali.nl, mcgrof@suse.com
Subject: Re: [PATCH v5 6/6] mtrr, mm, x86: Enhance MTRR checks for KVA huge page mapping
Date: Mon, 18 May 2015 11:22:39 -0600 [thread overview]
Message-ID: <1431969759.19889.5.camel@misato.fc.hp.com> (raw)
In-Reply-To: <20150518133348.GA23618@pd.tnic>
On Mon, 2015-05-18 at 15:33 +0200, Borislav Petkov wrote:
> On Fri, May 15, 2015 at 12:23:57PM -0600, Toshi Kani wrote:
> > This patch adds an additional argument, 'uniform', to
> > mtrr_type_lookup(), which returns 1 when a given range is
> > covered uniformly by MTRRs, i.e. the range is fully covered
> > by a single MTRR entry or the default type.
> >
> > pud_set_huge() and pmd_set_huge() are changed to check the
> > new 'uniform' flag to see if it is safe to create a huge page
> > mapping to the range. This allows them to create a huge page
> > mapping to a range covered by a single MTRR entry of any
> > memory type. It also detects a non-optimal request properly.
> > They continue to check with the WB type since the WB type has
> > no effect even if a request spans multiple MTRR entries.
> >
> > pmd_set_huge() logs a warning message to a non-optimal request
> > so that driver writers will be aware of such a case. Drivers
> > should make a mapping request aligned to a single MTRR entry
> > when the range is covered by MTRRs.
> >
> > Signed-off-by: Toshi Kani <toshi.kani@hp.com>
> > ---
> > arch/x86/include/asm/mtrr.h | 4 ++--
> > arch/x86/kernel/cpu/mtrr/generic.c | 37 ++++++++++++++++++++++++++----------
> > arch/x86/mm/pat.c | 4 ++--
> > arch/x86/mm/pgtable.c | 33 ++++++++++++++++++++------------
> > 4 files changed, 52 insertions(+), 26 deletions(-)
:
>
> All applied,
Great!
> I reformatted the comments in this last one a bit and made
> the warning message hopefully a bit more descriptive:
I have a few comments below.
> diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
> index c30f9819786b..f1894daa79ee 100644
> --- a/arch/x86/mm/pgtable.c
> +++ b/arch/x86/mm/pgtable.c
> @@ -566,19 +566,24 @@ void native_set_fixmap(enum fixed_addresses idx, phys_addr_t phys,
> /**
> * pud_set_huge - setup kernel PUD mapping
> *
> - * MTRR can override PAT memory types with 4KiB granularity. Therefore,
> - * this function does not set up a huge page when the range is covered
> - * by a non-WB type of MTRR. MTRR_TYPE_INVALID indicates that MTRR are
> - * disabled.
> + * MTRRs can override PAT memory types with 4KiB granularity. Therefore,
> + * this function sets up a huge page only if all of the following
> + * conditions are met:
It should be "if any of the following condition is met". Or, does NOT
setup if all of ...
> + *
> + * - MTRRs are disabled.
> + * - The range is mapped uniformly by an MTRR, i.e. the range is
> + * fully covered by a single MTRR entry or the default type.
> + * - The MTRR memory type is WB.
> *
> * Returns 1 on success and 0 on failure.
> */
> int pud_set_huge(pud_t *pud, phys_addr_t addr, pgprot_t prot)
> {
> - u8 mtrr;
> + u8 mtrr, uniform;
>
> - mtrr = mtrr_type_lookup(addr, addr + PUD_SIZE);
> - if ((mtrr != MTRR_TYPE_WRBACK) && (mtrr != MTRR_TYPE_INVALID))
> + mtrr = mtrr_type_lookup(addr, addr + PUD_SIZE, &uniform);
> + if ((mtrr != MTRR_TYPE_INVALID) && (!uniform) &&
> + (mtrr != MTRR_TYPE_WRBACK))
> return 0;
>
> prot = pgprot_4k_2_large(prot);
> @@ -593,20 +598,28 @@ int pud_set_huge(pud_t *pud, phys_addr_t addr, pgprot_t prot)
> /**
> * pmd_set_huge - setup kernel PMD mapping
> *
> - * MTRR can override PAT memory types with 4KiB granularity. Therefore,
> - * this function does not set up a huge page when the range is covered
> - * by a non-WB type of MTRR. MTRR_TYPE_INVALID indicates that MTRR are
> - * disabled.
> + * MTRRs can override PAT memory types with 4KiB granularity. Therefore,
> + * this function sets up a huge page only if all of the following
> + * conditions are met:
Ditto.
> + *
> + * - MTRR is disabled.
> + * - The range is mapped uniformly by an MTRR, i.e. the range is
> + * fully covered by a single MTRR entry or the default type.
> + * - The MTRR memory type is WB.
> *
> * Returns 1 on success and 0 on failure.
> */
> int pmd_set_huge(pmd_t *pmd, phys_addr_t addr, pgprot_t prot)
> {
> - u8 mtrr;
> + u8 mtrr, uniform;
>
> - mtrr = mtrr_type_lookup(addr, addr + PMD_SIZE);
> - if ((mtrr != MTRR_TYPE_WRBACK) && (mtrr != MTRR_TYPE_INVALID))
> + mtrr = mtrr_type_lookup(addr, addr + PMD_SIZE, &uniform);
> + if ((mtrr != MTRR_TYPE_INVALID) && (!uniform) &&
> + (mtrr != MTRR_TYPE_WRBACK)) {
> + pr_warn_once("%s: Cannot satisfy [mem %#010llx-%#010llx] with a huge-page mapping due to MTRR override.\n",
> + __func__, addr, addr + PMD_SIZE);
This new message looks good.
Thanks,
-Toshi
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2015-05-18 17:42 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-15 18:23 [PATCH v5 0/6] mtrr, mm, x86: Enhance MTRR checks for huge I/O mapping Toshi Kani
2015-05-15 18:23 ` [PATCH v5 1/6] mm, x86: Simplify conditions of HAVE_ARCH_HUGE_VMAP Toshi Kani
2015-05-17 8:30 ` Borislav Petkov
[not found] ` <1432628901-18044-2-git-send-email-bp@alien8.de>
2015-05-27 14:17 ` [tip:x86/mm] x86/mm/kconfig: Simplify conditions for HAVE_ARCH_HUGE_VMAP tip-bot for Toshi Kani
2015-05-15 18:23 ` [PATCH v5 2/6] mtrr, x86: Fix MTRR lookup to handle inclusive entry Toshi Kani
[not found] ` <1432628901-18044-3-git-send-email-bp@alien8.de>
2015-05-27 14:18 ` [tip:x86/mm] x86/mm/mtrr: Fix MTRR lookup to handle an " tip-bot for Toshi Kani
2015-05-15 18:23 ` [PATCH v5 3/6] mtrr, x86: Fix MTRR state checks in mtrr_type_lookup() Toshi Kani
[not found] ` <1432628901-18044-4-git-send-email-bp@alien8.de>
2015-05-27 14:18 ` [tip:x86/mm] x86/mm/mtrr: " tip-bot for Toshi Kani
2015-05-15 18:23 ` [PATCH v5 4/6] mtrr, x86: Define MTRR_TYPE_INVALID for mtrr_type_lookup() Toshi Kani
[not found] ` <1432628901-18044-5-git-send-email-bp@alien8.de>
2015-05-27 14:18 ` [tip:x86/mm] x86/mm/mtrr: Use symbolic define as a retval for disabled MTRRs tip-bot for Toshi Kani
2015-05-15 18:23 ` [PATCH v5 5/6] mtrr, x86: Clean up mtrr_type_lookup() Toshi Kani
[not found] ` <1432628901-18044-6-git-send-email-bp@alien8.de>
2015-05-27 14:19 ` [tip:x86/mm] x86/mm/mtrr: " tip-bot for Toshi Kani
2015-07-31 13:18 ` Peter Zijlstra
2015-07-31 14:44 ` Borislav Petkov
2015-07-31 15:08 ` Peter Zijlstra
2015-07-31 15:27 ` Borislav Petkov
2015-08-01 14:28 ` Luis R. Rodriguez
2015-08-01 16:33 ` Borislav Petkov
2015-08-01 16:39 ` Linus Torvalds
2015-08-01 16:49 ` Borislav Petkov
2015-08-01 17:03 ` Linus Torvalds
2015-05-15 18:23 ` [PATCH v5 6/6] mtrr, mm, x86: Enhance MTRR checks for KVA huge page mapping Toshi Kani
2015-05-18 13:33 ` Borislav Petkov
2015-05-18 17:22 ` Toshi Kani [this message]
2015-05-18 19:01 ` Borislav Petkov
2015-05-18 19:31 ` Toshi Kani
2015-05-18 20:01 ` Borislav Petkov
2015-05-18 20:21 ` Toshi Kani
2015-05-18 20:51 ` Borislav Petkov
2015-05-18 21:53 ` Toshi Kani
2015-05-19 11:44 ` Borislav Petkov
2015-05-19 13:23 ` Borislav Petkov
2015-05-19 13:47 ` Toshi Kani
2015-05-20 11:55 ` Ingo Molnar
2015-05-20 14:34 ` Toshi Kani
2015-05-20 15:01 ` Ingo Molnar
2015-05-20 15:02 ` Toshi Kani
2015-05-20 16:04 ` Borislav Petkov
2015-05-20 15:46 ` Toshi Kani
[not found] ` <1432628901-18044-8-git-send-email-bp@alien8.de>
2015-05-27 14:19 ` [tip:x86/mm] x86/mm/mtrr: Enhance MTRR checks in kernel mapping helpers tip-bot for Toshi Kani
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1431969759.19889.5.camel@misato.fc.hp.com \
--to=toshi.kani@hp.com \
--cc=Elliott@hp.com \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mcgrof@suse.com \
--cc=mingo@redhat.com \
--cc=pebolle@tiscali.nl \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox