From: Steve Wahl <steve.wahl@hpe.com>
To: Steve Wahl <steve.wahl@hpe.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>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
linux-kernel@vger.kernel.org,
Linux regressions mailing list <regressions@lists.linux.dev>,
Pavin Joseph <me@pavinjoseph.com>,
stable@vger.kernel.org, Eric Hagberg <ehagberg@gmail.com>
Cc: Simon Horman <horms@verge.net.au>,
Eric Biederman <ebiederm@xmission.com>,
Dave Young <dyoung@redhat.com>, Sarah Brofeldt <srhb@dbc.dk>,
Russ Anderson <rja@hpe.com>, Dimitri Sivanich <sivanich@hpe.com>,
Hou Wenlong <houwenlong.hwl@antgroup.com>,
Andrew Morton <akpm@linux-foundation.org>,
Baoquan He <bhe@redhat.com>, Yuntao Wang <ytcoode@gmail.com>,
Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH v4] x86/mm/ident_map: On UV systems, use gbpages only where full GB page should be mapped.
Date: Thu, 28 Mar 2024 11:17:03 -0500 [thread overview]
Message-ID: <ZgWX_x-CB7OjKAGD@swahl-home.5wahls.com> (raw)
In-Reply-To: <20240328160614.1838496-1-steve.wahl@hpe.com>
Note: I cc:'d stable in the email headers by mistake. NO CC: stable
tag, I don't want this to go into stable.
Thanks,
--> Steve
On Thu, Mar 28, 2024 at 11:06:14AM -0500, Steve Wahl wrote:
> When ident_pud_init() uses only gbpages to create identity maps, large
> ranges of addresses not actually requested can be included in the
> resulting table; a 4K request will map a full GB. On UV systems, this
> ends up including regions that will cause hardware to halt the system
> if accessed (these are marked "reserved" by BIOS). Even processor
> speculation into these regions is enough to trigger the system halt.
> And MTRRs cannot be used to restrict this speculation, there are not
> enough MTRRs to cover all the reserved regions.
>
> The fix for that would be to only use gbpages when map creation
> requests include the full GB page of space, and falling back to using
> smaller 2M pages when only portions of a GB page are included in the
> request.
>
> But on some other systems, possibly due to buggy bios, that solution
> leaves some areas out of the identity map that are needed for kexec to
> succeed. It is believed that these areas are not marked properly for
> map_acpi_tables() in arch/x86/kernel/machine_kexec_64.c to catch and
> map them. The nogbpages kernel command line option also causes these
> systems to fail even without these changes.
>
> So, create kexec identity maps using full GB pages on all platforms
> but UV; on UV, use narrower 2MB pages in the identity map where a full
> GB page would include areas outside the region requested.
>
> No attempt is made to coalesce mapping requests. If a request requires
> a map entry at the 2M (pmd) level, subsequent mapping requests within
> the same 1G region will also be at the pmd level, even if adjacent or
> overlapping such requests could have been combined to map a full
> gbpage. Existing usage starts with larger regions and then adds
> smaller regions, so this should not have any great consequence.
>
> Signed-off-by: Steve Wahl <steve.wahl@hpe.com>
>
> Fixes: d794734c9bbf ("x86/mm/ident_map: Use gbpages only where full GB page should be mapped.")
> Reported-by: Pavin Joseph <me@pavinjoseph.com>
> Closes: https://lore.kernel.org/all/3a1b9909-45ac-4f97-ad68-d16ef1ce99db@pavinjoseph.com/
> Link: https://lore.kernel.org/all/20240322162135.3984233-1-steve.wahl@hpe.com/
> Tested-by: Pavin Joseph <me@pavinjoseph.com>
> Tested-by: Eric Hagberg <ehagberg@gmail.com>
> Tested-by: Sarah Brofeldt <srhb@dbc.dk>
> ---
>
> v4: Incorporate fix for regression on systems relying on gbpages
> mapping more than the ranges actually requested for successful
> kexec, by limiting the effects of the change to UV systems.
> This patch based on tip/x86/urgent.
>
> v3: per Dave Hansen review, re-arrange changelog info,
> refactor code to use bool variable and split out conditions.
>
> v2: per Dave Hansen review: Additional changelog info,
> moved pud_large() check earlier in the code, and
> improved the comment describing the conditions
> that restrict gbpage usage.
>
>
> arch/x86/include/asm/init.h | 1 +
> arch/x86/kernel/machine_kexec_64.c | 10 ++++++++++
> arch/x86/mm/ident_map.c | 24 +++++++++++++++++++-----
> 3 files changed, 30 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/include/asm/init.h b/arch/x86/include/asm/init.h
> index cc9ccf61b6bd..371d9faea8bc 100644
> --- a/arch/x86/include/asm/init.h
> +++ b/arch/x86/include/asm/init.h
> @@ -10,6 +10,7 @@ struct x86_mapping_info {
> unsigned long page_flag; /* page flag for PMD or PUD entry */
> unsigned long offset; /* ident mapping offset */
> bool direct_gbpages; /* PUD level 1GB page support */
> + bool direct_gbpages_only; /* use 1GB pages exclusively */
> unsigned long kernpg_flag; /* kernel pagetable flag override */
> };
>
> diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
> index b180d8e497c3..3a2f5d291a88 100644
> --- a/arch/x86/kernel/machine_kexec_64.c
> +++ b/arch/x86/kernel/machine_kexec_64.c
> @@ -28,6 +28,7 @@
> #include <asm/setup.h>
> #include <asm/set_memory.h>
> #include <asm/cpu.h>
> +#include <asm/uv/uv.h>
>
> #ifdef CONFIG_ACPI
> /*
> @@ -212,6 +213,15 @@ static int init_pgtable(struct kimage *image, unsigned long start_pgtable)
>
> if (direct_gbpages)
> info.direct_gbpages = true;
> + /*
> + * UV systems need restrained use of gbpages in the identity
> + * maps to avoid system halts. But some other systems rely on
> + * using gbpages to expand mappings outside the regions
> + * actually listed, to include areas required for kexec but
> + * not explicitly named by the bios.
> + */
> + if (!is_uv_system())
> + info.direct_gbpages_only = true;
>
> for (i = 0; i < nr_pfn_mapped; i++) {
> mstart = pfn_mapped[i].start << PAGE_SHIFT;
> diff --git a/arch/x86/mm/ident_map.c b/arch/x86/mm/ident_map.c
> index 968d7005f4a7..a538a54aba5d 100644
> --- a/arch/x86/mm/ident_map.c
> +++ b/arch/x86/mm/ident_map.c
> @@ -26,18 +26,32 @@ static int ident_pud_init(struct x86_mapping_info *info, pud_t *pud_page,
> for (; addr < end; addr = next) {
> pud_t *pud = pud_page + pud_index(addr);
> pmd_t *pmd;
> + bool use_gbpage;
>
> next = (addr & PUD_MASK) + PUD_SIZE;
> if (next > end)
> next = end;
>
> - if (info->direct_gbpages) {
> - pud_t pudval;
> + /* if this is already a gbpage, this portion is already mapped */
> + if (pud_leaf(*pud))
> + continue;
> +
> + /* Is using a gbpage allowed? */
> + use_gbpage = info->direct_gbpages;
>
> - if (pud_present(*pud))
> - continue;
> + if (!info->direct_gbpages_only) {
> + /* Don't use gbpage if it maps more than the requested region. */
> + /* at the beginning: */
> + use_gbpage &= ((addr & ~PUD_MASK) == 0);
> + /* ... or at the end: */
> + use_gbpage &= ((next & ~PUD_MASK) == 0);
> + }
> + /* Never overwrite existing mappings */
> + use_gbpage &= !pud_present(*pud);
> +
> + if (use_gbpage) {
> + pud_t pudval;
>
> - addr &= PUD_MASK;
> pudval = __pud((addr - info->offset) | info->page_flag);
> set_pud(pud, pudval);
> continue;
>
> base-commit: b6540de9b5c867b4c8bc31225db181cc017d8cc7
> --
> 2.26.2
>
--
Steve Wahl, Hewlett Packard Enterprise
next prev parent reply other threads:[~2024-03-28 16:17 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-28 16:06 [PATCH v4] x86/mm/ident_map: On UV systems, use gbpages only where full GB page should be mapped Steve Wahl
2024-03-28 16:10 ` kernel test robot
2024-03-28 16:17 ` Steve Wahl [this message]
2024-03-29 7:15 ` Ingo Molnar
2024-03-29 8:01 ` Pavin Joseph
2024-03-29 8:15 ` Ingo Molnar
2024-03-29 8:56 ` Pavin Joseph
2024-03-29 13:30 ` Ingo Molnar
2024-03-31 3:55 ` Eric W. Biederman
2024-04-01 13:30 ` Pavin Joseph
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=ZgWX_x-CB7OjKAGD@swahl-home.5wahls.com \
--to=steve.wahl@hpe.com \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=bhelgaas@google.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=dyoung@redhat.com \
--cc=ebiederm@xmission.com \
--cc=ehagberg@gmail.com \
--cc=horms@verge.net.au \
--cc=houwenlong.hwl@antgroup.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=me@pavinjoseph.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=regressions@lists.linux.dev \
--cc=rja@hpe.com \
--cc=sivanich@hpe.com \
--cc=srhb@dbc.dk \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=ytcoode@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.