All of lore.kernel.org
 help / color / mirror / Atom feed
From: steve.wahl@hpe.com
To: Steve Wahl <steve.wahl@hpe.com>, Jonathan Corbet <corbet@lwn.net>,
	Ard Biesheuvel <ardb@kernel.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>,
	Darren Hart <dvhart@infradead.org>,
	Andy Shevchenko <andy@infradead.org>,
	Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Juergen Gross <jgross@suse.com>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	Oliver Neukum <oneukum@suse.com>,
	Mike Travis <mike.travis@hpe.com>,
	Dimitri Sivanich <dimitri.sivanich@hpe.com>,
	Benjamin Thiel <b.thiel@posteo.de>,
	Andy Lutomirski <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	James Morris <jmorris@namei.org>,
	David Howells <dhowells@redhat.com>,
	Kees Cook <keescook@chromium.org>, Dave Young <dyoung@redhat.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Logan Gunthorpe <logang@deltatee.com>,
	Alexandre Chartre <alexandre.chartre@oracle.com>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Austin Kim <austindh.kim@gmail.com>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-efi@vger.kernel.org
Cc: Russ Anderson <rja@hpe.com>
Subject: [patch v3 11/13] x86: Remove references to no-longer-used efi_have_uv1_memmap()
Date: Mon, 13 Jul 2020 16:30:05 -0500	[thread overview]
Message-ID: <20200713212955.786177105@hpe.com> (raw)
In-Reply-To: 20200713212954.444086564@hpe.com

In removing UV1 support, efi_have_uv1_memmap is no longer used.

Signed-off-by: Steve Wahl <steve.wahl@hpe.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
---
 arch/x86/kernel/kexec-bzimage64.c |    9 ---------
 arch/x86/platform/efi/efi.c       |   14 +++-----------
 arch/x86/platform/efi/efi_64.c    |   38 +++-----------------------------------
 arch/x86/platform/efi/quirks.c    |    8 --------
 4 files changed, 6 insertions(+), 63 deletions(-)

--- linux.orig/arch/x86/kernel/kexec-bzimage64.c	2020-07-07 10:49:49.933510781 -0500
+++ linux/arch/x86/kernel/kexec-bzimage64.c	2020-07-07 10:56:15.393045519 -0500
@@ -170,15 +170,6 @@ setup_efi_state(struct boot_params *para
 	if (!current_ei->efi_memmap_size)
 		return 0;
 
-	/*
-	 * If 1:1 mapping is not enabled, second kernel can not setup EFI
-	 * and use EFI run time services. User space will have to pass
-	 * acpi_rsdp=<addr> on kernel command line to make second kernel boot
-	 * without efi.
-	 */
-	if (efi_have_uv1_memmap())
-		return 0;
-
 	params->secure_boot = boot_params.secure_boot;
 	ei->efi_loader_signature = current_ei->efi_loader_signature;
 	ei->efi_systab = current_ei->efi_systab;
--- linux.orig/arch/x86/platform/efi/efi.c	2020-07-07 10:49:49.933510781 -0500
+++ linux/arch/x86/platform/efi/efi.c	2020-07-07 10:56:15.401045510 -0500
@@ -648,7 +648,7 @@ static inline void *efi_map_next_entry_r
  */
 static void *efi_map_next_entry(void *entry)
 {
-	if (!efi_have_uv1_memmap() && efi_enabled(EFI_64BIT)) {
+	if (efi_enabled(EFI_64BIT)) {
 		/*
 		 * Starting in UEFI v2.5 the EFI_PROPERTIES_TABLE
 		 * config table feature requires us to map all entries
@@ -777,11 +777,9 @@ static void __init kexec_enter_virtual_m
 
 	/*
 	 * We don't do virtual mode, since we don't do runtime services, on
-	 * non-native EFI. With the UV1 memmap, we don't do runtime services in
-	 * kexec kernel because in the initial boot something else might
-	 * have been mapped at these virtual addresses.
+	 * non-native EFI.
 	 */
-	if (efi_is_mixed() || efi_have_uv1_memmap()) {
+	if (efi_is_mixed()) {
 		efi_memmap_unmap();
 		clear_bit(EFI_RUNTIME_SERVICES, &efi.flags);
 		return;
@@ -832,12 +830,6 @@ static void __init kexec_enter_virtual_m
  * has the runtime attribute bit set in its memory descriptor into the
  * efi_pgd page table.
  *
- * The old method which used to update that memory descriptor with the
- * virtual address obtained from ioremap() is still supported when the
- * kernel is booted on SG1 UV1 hardware. Same old method enabled the
- * runtime services to be called without having to thunk back into
- * physical mode for every invocation.
- *
  * The new method does a pagetable switch in a preemption-safe manner
  * so that we're in a different address space when calling a runtime
  * function. For function arguments passing we do copy the PUDs of the
--- linux.orig/arch/x86/platform/efi/efi_64.c	2020-07-07 10:49:49.933510781 -0500
+++ linux/arch/x86/platform/efi/efi_64.c	2020-07-07 10:56:15.405045505 -0500
@@ -74,9 +74,6 @@ int __init efi_alloc_page_tables(void)
 	pud_t *pud;
 	gfp_t gfp_mask;
 
-	if (efi_have_uv1_memmap())
-		return 0;
-
 	gfp_mask = GFP_KERNEL | __GFP_ZERO;
 	efi_pgd = (pgd_t *)__get_free_pages(gfp_mask, PGD_ALLOCATION_ORDER);
 	if (!efi_pgd)
@@ -115,9 +112,6 @@ void efi_sync_low_kernel_mappings(void)
 	pud_t *pud_k, *pud_efi;
 	pgd_t *efi_pgd = efi_mm.pgd;
 
-	if (efi_have_uv1_memmap())
-		return;
-
 	/*
 	 * We can share all PGD entries apart from the one entry that
 	 * covers the EFI runtime mapping space.
@@ -206,9 +200,6 @@ int __init efi_setup_page_tables(unsigne
 	unsigned npages;
 	pgd_t *pgd = efi_mm.pgd;
 
-	if (efi_have_uv1_memmap())
-		return 0;
-
 	/*
 	 * It can happen that the physical address of new_memmap lands in memory
 	 * which is not mapped in the EFI page table. Therefore we need to go
@@ -315,9 +306,6 @@ void __init efi_map_region(efi_memory_de
 	unsigned long size = md->num_pages << PAGE_SHIFT;
 	u64 pa = md->phys_addr;
 
-	if (efi_have_uv1_memmap())
-		return old_map_region(md);
-
 	/*
 	 * Make sure the 1:1 mappings are present as a catch-all for b0rked
 	 * firmware which doesn't update all internal pointers after switching
@@ -420,12 +408,6 @@ void __init efi_runtime_update_mappings(
 {
 	efi_memory_desc_t *md;
 
-	if (efi_have_uv1_memmap()) {
-		if (__supported_pte_mask & _PAGE_NX)
-			runtime_code_page_mkexec();
-		return;
-	}
-
 	/*
 	 * Use the EFI Memory Attribute Table for mapping permissions if it
 	 * exists, since it is intended to supersede EFI_PROPERTIES_TABLE.
@@ -474,10 +456,7 @@ void __init efi_runtime_update_mappings(
 void __init efi_dump_pagetable(void)
 {
 #ifdef CONFIG_EFI_PGT_DUMP
-	if (efi_have_uv1_memmap())
-		ptdump_walk_pgd_level(NULL, &init_mm);
-	else
-		ptdump_walk_pgd_level(NULL, &efi_mm);
+	ptdump_walk_pgd_level(NULL, &efi_mm);
 #endif
 }
 
@@ -849,21 +828,13 @@ efi_set_virtual_address_map(unsigned lon
 	const efi_system_table_t *systab = (efi_system_table_t *)systab_phys;
 	efi_status_t status;
 	unsigned long flags;
-	pgd_t *save_pgd = NULL;
 
 	if (efi_is_mixed())
 		return efi_thunk_set_virtual_address_map(memory_map_size,
 							 descriptor_size,
 							 descriptor_version,
 							 virtual_map);
-
-	if (efi_have_uv1_memmap()) {
-		save_pgd = efi_uv1_memmap_phys_prolog();
-		if (!save_pgd)
-			return EFI_ABORTED;
-	} else {
-		efi_switch_mm(&efi_mm);
-	}
+	efi_switch_mm(&efi_mm);
 
 	kernel_fpu_begin();
 
@@ -879,10 +850,7 @@ efi_set_virtual_address_map(unsigned lon
 	/* grab the virtually remapped EFI runtime services table pointer */
 	efi.runtime = READ_ONCE(systab->runtime);
 
-	if (save_pgd)
-		efi_uv1_memmap_phys_epilog(save_pgd);
-	else
-		efi_switch_mm(efi_scratch.prev_mm);
+	efi_switch_mm(efi_scratch.prev_mm);
 
 	return status;
 }
--- linux.orig/arch/x86/platform/efi/quirks.c	2020-07-07 10:56:15.209045740 -0500
+++ linux/arch/x86/platform/efi/quirks.c	2020-07-07 10:56:15.409045500 -0500
@@ -381,14 +381,6 @@ static void __init efi_unmap_pages(efi_m
 	u64 va = md->virt_addr;
 
 	/*
-	 * To Do: Remove this check after adding functionality to unmap EFI boot
-	 * services code/data regions from direct mapping area because the UV1
-	 * memory map maps EFI regions in swapper_pg_dir.
-	 */
-	if (efi_have_uv1_memmap())
-		return;
-
-	/*
 	 * EFI mixed mode has all RAM mapped to access arguments while making
 	 * EFI runtime calls, hence don't unmap EFI boot services code/data
 	 * regions.


  parent reply	other threads:[~2020-07-13 21:31 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-13 21:29 [patch v3 00/13] Remove UV1 platform support and associated efi=oldmap option steve.wahl
2020-07-13 21:29 ` [patch v3 01/13] x86: Remove support for UV1 platform from uv_time.c steve.wahl
2020-07-17 14:51   ` [tip: x86/platform] x86/platform/uv: Remove support for UV1 platform from uv_time tip-bot2 for steve.wahl@hpe.com
2020-07-13 21:29 ` [patch v3 02/13] x86: Remove support for UV1 platform from uv_tlb.c steve.wahl
2020-07-17 14:51   ` [tip: x86/platform] x86/platform/uv: Remove support for UV1 platform from uv_tlb tip-bot2 for steve.wahl@hpe.com
2020-07-13 21:29 ` [patch v3 03/13] x86: Remove support for UV1 platform from x2apic_uv_x.c steve.wahl
2020-07-17 14:51   ` [tip: x86/platform] x86/platform/uv: Remove support for UV1 platform from x2apic_uv_x tip-bot2 for steve.wahl@hpe.com
2020-07-13 21:29 ` [patch v3 04/13] x86: Remove support for UV1 platform from uv_mmrs.h steve.wahl
2020-07-17 14:51   ` [tip: x86/platform] x86/platform/uv: Remove support for UV1 platform from uv_mmrs tip-bot2 for steve.wahl@hpe.com
2020-07-13 21:29 ` [patch v3 05/13] x86: Remove support for UV1 platform from uv_bau.h steve.wahl
2020-07-17 14:51   ` [tip: x86/platform] x86/platform/uv: Remove support for UV1 platform from uv_bau tip-bot2 for steve.wahl@hpe.com
2020-07-13 21:30 ` [patch v3 06/13] x86: Remove support for uv1 platform from uv_hub.h steve.wahl
2020-07-17 14:51   ` [tip: x86/platform] x86/platform/uv: Remove support for uv1 platform from uv_hub tip-bot2 for steve.wahl@hpe.com
2020-07-13 21:30 ` [patch v3 07/13] x86: Remove support for UV1 platform from uv.h steve.wahl
2020-07-17 14:51   ` [tip: x86/platform] x86/platform/uv: Remove support for UV1 platform from uv tip-bot2 for steve.wahl@hpe.com
2020-07-13 21:30 ` [patch v3 08/13] x86: Remove vestigial mention of UV1 platform from arch/x86/include/asm/uv/bios.h steve.wahl
2020-07-17 14:51   ` [tip: x86/platform] x86/platform/uv: Remove vestigial mention of UV1 platform from bios header tip-bot2 for steve.wahl@hpe.com
2020-07-13 21:30 ` [patch v3 09/13] x86: Remove efi=old_map command line option steve.wahl
2020-07-17 14:51   ` [tip: x86/platform] x86/platform/uv: " tip-bot2 for steve.wahl@hpe.com
2020-07-13 21:30 ` [patch v3 10/13] x86: Delete SGI UV1 detection steve.wahl
2020-07-17 14:51   ` [tip: x86/platform] x86/efi: " tip-bot2 for steve.wahl@hpe.com
2020-07-13 21:30 ` steve.wahl [this message]
2020-07-17 14:51   ` [tip: x86/platform] x86/efi: Remove references to no-longer-used efi_have_uv1_memmap() tip-bot2 for steve.wahl@hpe.com
2020-07-13 21:30 ` [patch v3 12/13] x86: Remove uv bios and efi code related to (now unused) EFI_UV1_MEMMAP steve.wahl
2020-07-17 14:51   ` [tip: x86/platform] x86/platform/uv: Remove uv bios and efi code related to EFI_UV1_MEMMAP tip-bot2 for steve.wahl@hpe.com
2020-07-13 21:30 ` [patch v3 13/13] x86: Remove (now unused) EFI_UV1_MEMMAP from efi.h steve.wahl
2020-07-17 14:51   ` [tip: x86/platform] x86/efi: Remove unused EFI_UV1_MEMMAP code tip-bot2 for steve.wahl@hpe.com

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=20200713212955.786177105@hpe.com \
    --to=steve.wahl@hpe.com \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexandre.chartre@oracle.com \
    --cc=andy@infradead.org \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=austindh.kim@gmail.com \
    --cc=b.thiel@posteo.de \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=dan.j.williams@intel.com \
    --cc=dhowells@redhat.com \
    --cc=dimitri.sivanich@hpe.com \
    --cc=dvhart@infradead.org \
    --cc=dyoung@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=jgross@suse.com \
    --cc=jmorris@namei.org \
    --cc=keescook@chromium.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=logang@deltatee.com \
    --cc=luto@kernel.org \
    --cc=mchehab+huawei@kernel.org \
    --cc=mike.kravetz@oracle.com \
    --cc=mike.travis@hpe.com \
    --cc=mingo@redhat.com \
    --cc=oneukum@suse.com \
    --cc=paulmck@kernel.org \
    --cc=pawan.kumar.gupta@linux.intel.com \
    --cc=peterz@infradead.org \
    --cc=rja@hpe.com \
    --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 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.