[RFC/RFT PATCH 0/6] Switch GHES ioremap_page_range() to use fixmap

[RFC/RFT PATCH 0/6] Switch GHES ioremap_page_range() to use fixmap

[James Morse]

GHES is doing ioremap_page_range() in both NMI and irq context, neither
are safe as it may sleep to allocate intermediate levels of page table.

Replace the NMI/irq GHES_IOREMAP_PAGES to use a fixmap entry each.

After this nothing uses ghes_ioremap_area or arch_apei_flush_tlb_one(),
rip them out.

RFC as I've only build-tested this on x86. For arm64 I've tested it on a
software model. Any more testing would be welcome. These patches are based
on rc7.

Thanks,

James Morse (6):
  arm64: fixmap: Add GHES fixmap entries
  x86/mm/fixmap: Add GHES fixmap entries
  ACPI / APEI:  Replace ioremap_page_range() with fixmap
  ACPI / APEI: Remove ghes_ioremap_area
  arm64: mm: Remove arch_apei_flush_tlb_one()
  ACPI / APEI: Remove arch_apei_flush_tlb_one()

 arch/arm64/include/asm/acpi.h   | 12 ------
 arch/arm64/include/asm/fixmap.h |  5 +++
 arch/arm64/mm/mmu.c             |  4 ++
 arch/x86/include/asm/fixmap.h   |  4 ++
 arch/x86/kernel/acpi/apei.c     |  5 ---
 drivers/acpi/apei/ghes.c        | 84 +++++++++--------------------------------
 include/acpi/apei.h             |  1 -
 7 files changed, 30 insertions(+), 85 deletions(-)

-- 
2.15.0.rc2

[RFC/RFT PATCH 0/6] Switch GHES ioremap_page_range() to use fixmap

[James Morse]

GHES is doing ioremap_page_range() in both NMI and irq context, neither
are safe as it may sleep to allocate intermediate levels of page table.

Replace the NMI/irq GHES_IOREMAP_PAGES to use a fixmap entry each.

After this nothing uses ghes_ioremap_area or arch_apei_flush_tlb_one(),
rip them out.

RFC as I've only build-tested this on x86. For arm64 I've tested it on a
software model. Any more testing would be welcome. These patches are based
on rc7.

Thanks,

James Morse (6):
  arm64: fixmap: Add GHES fixmap entries
  x86/mm/fixmap: Add GHES fixmap entries
  ACPI / APEI:  Replace ioremap_page_range() with fixmap
  ACPI / APEI: Remove ghes_ioremap_area
  arm64: mm: Remove arch_apei_flush_tlb_one()
  ACPI / APEI: Remove arch_apei_flush_tlb_one()

 arch/arm64/include/asm/acpi.h   | 12 ------
 arch/arm64/include/asm/fixmap.h |  5 +++
 arch/arm64/mm/mmu.c             |  4 ++
 arch/x86/include/asm/fixmap.h   |  4 ++
 arch/x86/kernel/acpi/apei.c     |  5 ---
 drivers/acpi/apei/ghes.c        | 84 +++++++++--------------------------------
 include/acpi/apei.h             |  1 -
 7 files changed, 30 insertions(+), 85 deletions(-)

-- 
2.15.0.rc2

[RFC/RFT PATCH 1/6] arm64: fixmap: Add GHES fixmap entries

[James Morse]

GHES is switching to use fixmap for its dynamic mapping of CPER records,
to avoid using ioremap_page_range() in IRQ/NMI context.

Signed-off-by: James Morse <james.morse@arm.com>
---
 arch/arm64/include/asm/fixmap.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/include/asm/fixmap.h b/arch/arm64/include/asm/fixmap.h
index caf86be815ba..4edcdcb01a68 100644
--- a/arch/arm64/include/asm/fixmap.h
+++ b/arch/arm64/include/asm/fixmap.h
@@ -51,6 +51,11 @@ enum fixed_addresses {
 
 	FIX_EARLYCON_MEM_BASE,
 	FIX_TEXT_POKE0,
+
+	/* Used for GHES mapping from assorted contexts */
+	FIX_APEI_GHES_IRQ,
+	FIX_APEI_GHES_NMI,
+
 	__end_of_permanent_fixed_addresses,
 
 	/*
-- 
2.15.0.rc2

[RFC/RFT PATCH 1/6] arm64: fixmap: Add GHES fixmap entries

[James Morse]

GHES is switching to use fixmap for its dynamic mapping of CPER records,
to avoid using ioremap_page_range() in IRQ/NMI context.

Signed-off-by: James Morse <james.morse@arm.com>
---
 arch/arm64/include/asm/fixmap.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/include/asm/fixmap.h b/arch/arm64/include/asm/fixmap.h
index caf86be815ba..4edcdcb01a68 100644
--- a/arch/arm64/include/asm/fixmap.h
+++ b/arch/arm64/include/asm/fixmap.h
@@ -51,6 +51,11 @@ enum fixed_addresses {
 
 	FIX_EARLYCON_MEM_BASE,
 	FIX_TEXT_POKE0,
+
+	/* Used for GHES mapping from assorted contexts */
+	FIX_APEI_GHES_IRQ,
+	FIX_APEI_GHES_NMI,
+
 	__end_of_permanent_fixed_addresses,
 
 	/*
-- 
2.15.0.rc2

[RFC/RFT PATCH 2/6] x86/mm/fixmap: Add GHES fixmap entries

[James Morse]

GHES is switching to use fixmap for its dynamic mapping of CPER records,
to avoid using ioremap_page_range() in IRQ/NMI context.

Signed-off-by: James Morse <james.morse@arm.com>
---
 arch/x86/include/asm/fixmap.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
index dcd9fb55e679..be3cc32db7f0 100644
--- a/arch/x86/include/asm/fixmap.h
+++ b/arch/x86/include/asm/fixmap.h
@@ -104,6 +104,10 @@ enum fixed_addresses {
 	FIX_GDT_REMAP_BEGIN,
 	FIX_GDT_REMAP_END = FIX_GDT_REMAP_BEGIN + NR_CPUS - 1,
 
+	/* Used for GHES mapping from assorted contexts */
+	FIX_APEI_GHES_IRQ,
+	FIX_APEI_GHES_NMI,
+
 	__end_of_permanent_fixed_addresses,
 
 	/*
-- 
2.15.0.rc2

[RFC/RFT PATCH 2/6] x86/mm/fixmap: Add GHES fixmap entries

[James Morse]

GHES is switching to use fixmap for its dynamic mapping of CPER records,
to avoid using ioremap_page_range() in IRQ/NMI context.

Signed-off-by: James Morse <james.morse@arm.com>
---
 arch/x86/include/asm/fixmap.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
index dcd9fb55e679..be3cc32db7f0 100644
--- a/arch/x86/include/asm/fixmap.h
+++ b/arch/x86/include/asm/fixmap.h
@@ -104,6 +104,10 @@ enum fixed_addresses {
 	FIX_GDT_REMAP_BEGIN,
 	FIX_GDT_REMAP_END = FIX_GDT_REMAP_BEGIN + NR_CPUS - 1,
 
+	/* Used for GHES mapping from assorted contexts */
+	FIX_APEI_GHES_IRQ,
+	FIX_APEI_GHES_NMI,
+
 	__end_of_permanent_fixed_addresses,
 
 	/*
-- 
2.15.0.rc2

Re: [RFC/RFT PATCH 2/6] x86/mm/fixmap: Add GHES fixmap entries

[Ingo Molnar]

* James Morse <james.morse@arm.com> wrote:

> GHES is switching to use fixmap for its dynamic mapping of CPER records,
> to avoid using ioremap_page_range() in IRQ/NMI context.
> 
> Signed-off-by: James Morse <james.morse@arm.com>
> ---
>  arch/x86/include/asm/fixmap.h | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
> index dcd9fb55e679..be3cc32db7f0 100644
> --- a/arch/x86/include/asm/fixmap.h
> +++ b/arch/x86/include/asm/fixmap.h
> @@ -104,6 +104,10 @@ enum fixed_addresses {
>  	FIX_GDT_REMAP_BEGIN,
>  	FIX_GDT_REMAP_END = FIX_GDT_REMAP_BEGIN + NR_CPUS - 1,
>  
> +	/* Used for GHES mapping from assorted contexts */
> +	FIX_APEI_GHES_IRQ,
> +	FIX_APEI_GHES_NMI,
> +

Acked-by: Ingo Molnar <mingo@kernel.org>

Thanks,

	Ingo

[RFC/RFT PATCH 2/6] x86/mm/fixmap: Add GHES fixmap entries

[Ingo Molnar]

* James Morse <james.morse@arm.com> wrote:

> GHES is switching to use fixmap for its dynamic mapping of CPER records,
> to avoid using ioremap_page_range() in IRQ/NMI context.
> 
> Signed-off-by: James Morse <james.morse@arm.com>
> ---
>  arch/x86/include/asm/fixmap.h | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
> index dcd9fb55e679..be3cc32db7f0 100644
> --- a/arch/x86/include/asm/fixmap.h
> +++ b/arch/x86/include/asm/fixmap.h
> @@ -104,6 +104,10 @@ enum fixed_addresses {
>  	FIX_GDT_REMAP_BEGIN,
>  	FIX_GDT_REMAP_END = FIX_GDT_REMAP_BEGIN + NR_CPUS - 1,
>  
> +	/* Used for GHES mapping from assorted contexts */
> +	FIX_APEI_GHES_IRQ,
> +	FIX_APEI_GHES_NMI,
> +

Acked-by: Ingo Molnar <mingo@kernel.org>

Thanks,

	Ingo

Re: [RFC/RFT PATCH 2/6] x86/mm/fixmap: Add GHES fixmap entries

[Borislav Petkov]

On Tue, Oct 31, 2017 at 03:38:28PM +0000, James Morse wrote:
> GHES is switching to use fixmap for its dynamic mapping of CPER records,
> to avoid using ioremap_page_range() in IRQ/NMI context.
> 
> Signed-off-by: James Morse <james.morse@arm.com>
> ---
>  arch/x86/include/asm/fixmap.h | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
> index dcd9fb55e679..be3cc32db7f0 100644
> --- a/arch/x86/include/asm/fixmap.h
> +++ b/arch/x86/include/asm/fixmap.h
> @@ -104,6 +104,10 @@ enum fixed_addresses {
>  	FIX_GDT_REMAP_BEGIN,
>  	FIX_GDT_REMAP_END = FIX_GDT_REMAP_BEGIN + NR_CPUS - 1,
>  
> +	/* Used for GHES mapping from assorted contexts */
> +	FIX_APEI_GHES_IRQ,
> +	FIX_APEI_GHES_NMI,

Maybe I'm missing something but shouldn't those two be inside
CONFIG_ACPI_APEI_GHES ifdeffery?

Ditto for the ARM side.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[RFC/RFT PATCH 2/6] x86/mm/fixmap: Add GHES fixmap entries

[Borislav Petkov]

On Tue, Oct 31, 2017 at 03:38:28PM +0000, James Morse wrote:
> GHES is switching to use fixmap for its dynamic mapping of CPER records,
> to avoid using ioremap_page_range() in IRQ/NMI context.
> 
> Signed-off-by: James Morse <james.morse@arm.com>
> ---
>  arch/x86/include/asm/fixmap.h | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
> index dcd9fb55e679..be3cc32db7f0 100644
> --- a/arch/x86/include/asm/fixmap.h
> +++ b/arch/x86/include/asm/fixmap.h
> @@ -104,6 +104,10 @@ enum fixed_addresses {
>  	FIX_GDT_REMAP_BEGIN,
>  	FIX_GDT_REMAP_END = FIX_GDT_REMAP_BEGIN + NR_CPUS - 1,
>  
> +	/* Used for GHES mapping from assorted contexts */
> +	FIX_APEI_GHES_IRQ,
> +	FIX_APEI_GHES_NMI,

Maybe I'm missing something but shouldn't those two be inside
CONFIG_ACPI_APEI_GHES ifdeffery?

Ditto for the ARM side.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imend?rffer, Jane Smithard, Graham Norton, HRB 21284 (AG N?rnberg)
-- 

[RFC/RFT PATCH 3/6] ACPI / APEI: Replace ioremap_page_range() with fixmap

[James Morse]

Replace ghes_io{re,un}map_pfn_{nmi,irq}()s use of ioremap_page_range()
with __set_fixmap() as ioremap_page_range() may sleep to allocate a new
level of page-table, even if its passed an existing final-address to
use in the mapping.

clear_fixmap() does the TLB invalidation in __set_fixmap() for arm64
and __set_pte_vaddr() for x86. In each case its the same as the
respective arch_apei_flush_tlb_one().

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: James Morse <james.morse@arm.com>
CC: Tyler Baicar <tbaicar@codeaurora.org>
CC: Dongjiu Geng <gengdongjiu@huawei.com>
CC: Xie XiuQi <xiexiuqi@huawei.com>

---
CC'd people I've seen posting CPER log fragments, could you give this a
test on your platforms?

 drivers/acpi/apei/ghes.c | 45 +++++++++++++++------------------------------
 1 file changed, 15 insertions(+), 30 deletions(-)

diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 3c3a37b8503b..f3269816b997 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -51,6 +51,7 @@
 #include <acpi/actbl1.h>
 #include <acpi/ghes.h>
 #include <acpi/apei.h>
+#include <asm/fixmap.h>
 #include <asm/tlbflush.h>
 #include <ras/ras_event.h>
 
@@ -112,7 +113,7 @@ static DEFINE_MUTEX(ghes_list_mutex);
  * Because the memory area used to transfer hardware error information
  * from BIOS to Linux can be determined only in NMI, IRQ or timer
  * handler, but general ioremap can not be used in atomic context, so
- * a special version of atomic ioremap is implemented for that.
+ * the fixmap is used instead.
  */
 
 /*
@@ -126,8 +127,8 @@ static DEFINE_MUTEX(ghes_list_mutex);
 /* virtual memory area for atomic ioremap */
 static struct vm_struct *ghes_ioremap_area;
 /*
- * These 2 spinlock is used to prevent atomic ioremap virtual memory
- * area from being mapped simultaneously.
+ * These 2 spinlocks are used to prevent the fixmap entries from being used
+ * simultaneously.
  */
 static DEFINE_RAW_SPINLOCK(ghes_ioremap_lock_nmi);
 static DEFINE_SPINLOCK(ghes_ioremap_lock_irq);
@@ -159,52 +160,36 @@ static void ghes_ioremap_exit(void)
 
 static void __iomem *ghes_ioremap_pfn_nmi(u64 pfn)
 {
-	unsigned long vaddr;
 	phys_addr_t paddr;
 	pgprot_t prot;
 
-	vaddr = (unsigned long)GHES_IOREMAP_NMI_PAGE(ghes_ioremap_area->addr);
-
 	paddr = pfn << PAGE_SHIFT;
 	prot = arch_apei_get_mem_attribute(paddr);
-	ioremap_page_range(vaddr, vaddr + PAGE_SIZE, paddr, prot);
+	__set_fixmap(FIX_APEI_GHES_NMI, paddr, prot);
 
-	return (void __iomem *)vaddr;
+	return (void __iomem *) fix_to_virt(FIX_APEI_GHES_NMI);
 }
 
 static void __iomem *ghes_ioremap_pfn_irq(u64 pfn)
 {
-	unsigned long vaddr, paddr;
+	unsigned long paddr;
 	pgprot_t prot;
 
-	vaddr = (unsigned long)GHES_IOREMAP_IRQ_PAGE(ghes_ioremap_area->addr);
-
 	paddr = pfn << PAGE_SHIFT;
 	prot = arch_apei_get_mem_attribute(paddr);
+	__set_fixmap(FIX_APEI_GHES_IRQ, paddr, prot);
 
-	ioremap_page_range(vaddr, vaddr + PAGE_SIZE, paddr, prot);
-
-	return (void __iomem *)vaddr;
+	return (void __iomem *) fix_to_virt(FIX_APEI_GHES_IRQ);
 }
 
-static void ghes_iounmap_nmi(void __iomem *vaddr_ptr)
+static void ghes_iounmap_nmi(void)
 {
-	unsigned long vaddr = (unsigned long __force)vaddr_ptr;
-	void *base = ghes_ioremap_area->addr;
-
-	BUG_ON(vaddr != (unsigned long)GHES_IOREMAP_NMI_PAGE(base));
-	unmap_kernel_range_noflush(vaddr, PAGE_SIZE);
-	arch_apei_flush_tlb_one(vaddr);
+	clear_fixmap(FIX_APEI_GHES_NMI);
 }
 
-static void ghes_iounmap_irq(void __iomem *vaddr_ptr)
+static void ghes_iounmap_irq(void)
 {
-	unsigned long vaddr = (unsigned long __force)vaddr_ptr;
-	void *base = ghes_ioremap_area->addr;
-
-	BUG_ON(vaddr != (unsigned long)GHES_IOREMAP_IRQ_PAGE(base));
-	unmap_kernel_range_noflush(vaddr, PAGE_SIZE);
-	arch_apei_flush_tlb_one(vaddr);
+	clear_fixmap(FIX_APEI_GHES_IRQ);
 }
 
 static int ghes_estatus_pool_init(void)
@@ -360,10 +345,10 @@ static void ghes_copy_tofrom_phys(void *buffer, u64 paddr, u32 len,
 		paddr += trunk;
 		buffer += trunk;
 		if (in_nmi) {
-			ghes_iounmap_nmi(vaddr);
+			ghes_iounmap_nmi();
 			raw_spin_unlock(&ghes_ioremap_lock_nmi);
 		} else {
-			ghes_iounmap_irq(vaddr);
+			ghes_iounmap_irq();
 			spin_unlock_irqrestore(&ghes_ioremap_lock_irq, flags);
 		}
 	}
-- 
2.15.0.rc2

[RFC/RFT PATCH 3/6] ACPI / APEI: Replace ioremap_page_range() with fixmap

[James Morse]

Replace ghes_io{re,un}map_pfn_{nmi,irq}()s use of ioremap_page_range()
with __set_fixmap() as ioremap_page_range() may sleep to allocate a new
level of page-table, even if its passed an existing final-address to
use in the mapping.

clear_fixmap() does the TLB invalidation in __set_fixmap() for arm64
and __set_pte_vaddr() for x86. In each case its the same as the
respective arch_apei_flush_tlb_one().

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: James Morse <james.morse@arm.com>
CC: Tyler Baicar <tbaicar@codeaurora.org>
CC: Dongjiu Geng <gengdongjiu@huawei.com>
CC: Xie XiuQi <xiexiuqi@huawei.com>

---
CC'd people I've seen posting CPER log fragments, could you give this a
test on your platforms?

 drivers/acpi/apei/ghes.c | 45 +++++++++++++++------------------------------
 1 file changed, 15 insertions(+), 30 deletions(-)

diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 3c3a37b8503b..f3269816b997 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -51,6 +51,7 @@
 #include <acpi/actbl1.h>
 #include <acpi/ghes.h>
 #include <acpi/apei.h>
+#include <asm/fixmap.h>
 #include <asm/tlbflush.h>
 #include <ras/ras_event.h>
 
@@ -112,7 +113,7 @@ static DEFINE_MUTEX(ghes_list_mutex);
  * Because the memory area used to transfer hardware error information
  * from BIOS to Linux can be determined only in NMI, IRQ or timer
  * handler, but general ioremap can not be used in atomic context, so
- * a special version of atomic ioremap is implemented for that.
+ * the fixmap is used instead.
  */
 
 /*
@@ -126,8 +127,8 @@ static DEFINE_MUTEX(ghes_list_mutex);
 /* virtual memory area for atomic ioremap */
 static struct vm_struct *ghes_ioremap_area;
 /*
- * These 2 spinlock is used to prevent atomic ioremap virtual memory
- * area from being mapped simultaneously.
+ * These 2 spinlocks are used to prevent the fixmap entries from being used
+ * simultaneously.
  */
 static DEFINE_RAW_SPINLOCK(ghes_ioremap_lock_nmi);
 static DEFINE_SPINLOCK(ghes_ioremap_lock_irq);
@@ -159,52 +160,36 @@ static void ghes_ioremap_exit(void)
 
 static void __iomem *ghes_ioremap_pfn_nmi(u64 pfn)
 {
-	unsigned long vaddr;
 	phys_addr_t paddr;
 	pgprot_t prot;
 
-	vaddr = (unsigned long)GHES_IOREMAP_NMI_PAGE(ghes_ioremap_area->addr);
-
 	paddr = pfn << PAGE_SHIFT;
 	prot = arch_apei_get_mem_attribute(paddr);
-	ioremap_page_range(vaddr, vaddr + PAGE_SIZE, paddr, prot);
+	__set_fixmap(FIX_APEI_GHES_NMI, paddr, prot);
 
-	return (void __iomem *)vaddr;
+	return (void __iomem *) fix_to_virt(FIX_APEI_GHES_NMI);
 }
 
 static void __iomem *ghes_ioremap_pfn_irq(u64 pfn)
 {
-	unsigned long vaddr, paddr;
+	unsigned long paddr;
 	pgprot_t prot;
 
-	vaddr = (unsigned long)GHES_IOREMAP_IRQ_PAGE(ghes_ioremap_area->addr);
-
 	paddr = pfn << PAGE_SHIFT;
 	prot = arch_apei_get_mem_attribute(paddr);
+	__set_fixmap(FIX_APEI_GHES_IRQ, paddr, prot);
 
-	ioremap_page_range(vaddr, vaddr + PAGE_SIZE, paddr, prot);
-
-	return (void __iomem *)vaddr;
+	return (void __iomem *) fix_to_virt(FIX_APEI_GHES_IRQ);
 }
 
-static void ghes_iounmap_nmi(void __iomem *vaddr_ptr)
+static void ghes_iounmap_nmi(void)
 {
-	unsigned long vaddr = (unsigned long __force)vaddr_ptr;
-	void *base = ghes_ioremap_area->addr;
-
-	BUG_ON(vaddr != (unsigned long)GHES_IOREMAP_NMI_PAGE(base));
-	unmap_kernel_range_noflush(vaddr, PAGE_SIZE);
-	arch_apei_flush_tlb_one(vaddr);
+	clear_fixmap(FIX_APEI_GHES_NMI);
 }
 
-static void ghes_iounmap_irq(void __iomem *vaddr_ptr)
+static void ghes_iounmap_irq(void)
 {
-	unsigned long vaddr = (unsigned long __force)vaddr_ptr;
-	void *base = ghes_ioremap_area->addr;
-
-	BUG_ON(vaddr != (unsigned long)GHES_IOREMAP_IRQ_PAGE(base));
-	unmap_kernel_range_noflush(vaddr, PAGE_SIZE);
-	arch_apei_flush_tlb_one(vaddr);
+	clear_fixmap(FIX_APEI_GHES_IRQ);
 }
 
 static int ghes_estatus_pool_init(void)
@@ -360,10 +345,10 @@ static void ghes_copy_tofrom_phys(void *buffer, u64 paddr, u32 len,
 		paddr += trunk;
 		buffer += trunk;
 		if (in_nmi) {
-			ghes_iounmap_nmi(vaddr);
+			ghes_iounmap_nmi();
 			raw_spin_unlock(&ghes_ioremap_lock_nmi);
 		} else {
-			ghes_iounmap_irq(vaddr);
+			ghes_iounmap_irq();
 			spin_unlock_irqrestore(&ghes_ioremap_lock_irq, flags);
 		}
 	}
-- 
2.15.0.rc2

Re: [RFC/RFT PATCH 3/6] ACPI / APEI: Replace ioremap_page_range() with fixmap

[gengdongjiu]

On 2017/10/31 23:38, James Morse wrote:
> CC'd people I've seen posting CPER log fragments, could you give this a
> test on your platforms?
Thanks for the fixing, not found obviously issue.

[RFC/RFT PATCH 3/6] ACPI / APEI: Replace ioremap_page_range() with fixmap

[gengdongjiu]

On 2017/10/31 23:38, James Morse wrote:
> CC'd people I've seen posting CPER log fragments, could you give this a
> test on your platforms?
Thanks for the fixing, not found obviously issue.

Re: [RFC/RFT PATCH 3/6] ACPI / APEI: Replace ioremap_page_range() with fixmap

[gengdongjiu]

On 2017/10/31 23:38, James Morse wrote:
> CC'd people I've seen posting CPER log fragments, could you give this a
> test on your platforms?
Thanks for the fixing, not found obviously issue.

Re: [RFC/RFT PATCH 3/6] ACPI / APEI: Replace ioremap_page_range() with fixmap

[James Morse]

Hi gengdonjiu,

On 01/11/17 04:13, gengdongjiu wrote:
> On 2017/10/31 23:38, James Morse wrote:
>> CC'd people I've seen posting CPER log fragments, could you give this a
>> test on your platforms?

> Thanks for the fixing, not found obviously issue.

Can I take that as a 'Tested-by:'?

These tags also let us record who has a system that can test changes to this driver.


Thanks,

James

[RFC/RFT PATCH 3/6] ACPI / APEI: Replace ioremap_page_range() with fixmap

[James Morse]

Hi gengdonjiu,

On 01/11/17 04:13, gengdongjiu wrote:
> On 2017/10/31 23:38, James Morse wrote:
>> CC'd people I've seen posting CPER log fragments, could you give this a
>> test on your platforms?

> Thanks for the fixing, not found obviously issue.

Can I take that as a 'Tested-by:'?

These tags also let us record who has a system that can test changes to this driver.


Thanks,

James

Re: [RFC/RFT PATCH 3/6] ACPI / APEI: Replace ioremap_page_range() with fixmap

[gengdongjiu]

Hi James,

> 
> Can I take that as a 'Tested-by:'?
> 
> These tags also let us record who has a system that can test changes to this driver.

sure.
Thanks for the fixing.
Qiang Zheng who is my colleague have tested it.

CC  Qiang.

Tested-by:  Qiang Zheng <zhengqiang10@huawei.com>

> 
> 
> Thanks,
> 
> James
> 
> 
> 
> .
> 

[RFC/RFT PATCH 3/6] ACPI / APEI: Replace ioremap_page_range() with fixmap

[gengdongjiu]

Hi James,

> 
> Can I take that as a 'Tested-by:'?
> 
> These tags also let us record who has a system that can test changes to this driver.

sure.
Thanks for the fixing.
Qiang Zheng who is my colleague have tested it.

CC  Qiang.

Tested-by:  Qiang Zheng <zhengqiang10@huawei.com>

> 
> 
> Thanks,
> 
> James
> 
> 
> 
> .
> 

Re: [RFC/RFT PATCH 3/6] ACPI / APEI: Replace ioremap_page_range() with fixmap

[gengdongjiu]

Hi James,

> 
> Can I take that as a 'Tested-by:'?
> 
> These tags also let us record who has a system that can test changes to this driver.

sure.
Thanks for the fixing.
Qiang Zheng who is my colleague have tested it.

CC  Qiang.

Tested-by:  Qiang Zheng <zhengqiang10@huawei.com>

> 
> 
> Thanks,
> 
> James
> 
> 
> 
> .
> 

Re: [RFC/RFT PATCH 3/6] ACPI / APEI: Replace ioremap_page_range() with fixmap

[James Morse]

Hi gengdongjiu

On 02/11/17 12:01, gengdongjiu wrote:
> James Morse wrote:
>> Can I take that as a 'Tested-by:'?
>>
>> These tags also let us record who has a system that can test changes to this driver.
> 
> sure.
> Thanks for the fixing.
> Qiang Zheng who is my colleague have tested it.
> 
> CC  Qiang.
> 
> Tested-by:  Qiang Zheng <zhengqiang10@huawei.com>

I can't do anything with this unless Qiang posts it. (I'll add to the CC list in
the next version)

>From Documentation/process/5.Posting.rst:
> Be careful in the addition of tags to your patches: only Cc: is appropriate
> for addition without the explicit permission of the person named.



Thanks,

James

[RFC/RFT PATCH 3/6] ACPI / APEI: Replace ioremap_page_range() with fixmap

[James Morse]

Hi gengdongjiu

On 02/11/17 12:01, gengdongjiu wrote:
> James Morse wrote:
>> Can I take that as a 'Tested-by:'?
>>
>> These tags also let us record who has a system that can test changes to this driver.
> 
> sure.
> Thanks for the fixing.
> Qiang Zheng who is my colleague have tested it.
> 
> CC  Qiang.
> 
> Tested-by:  Qiang Zheng <zhengqiang10@huawei.com>

I can't do anything with this unless Qiang posts it. (I'll add to the CC list in
the next version)

>From Documentation/process/5.Posting.rst:
> Be careful in the addition of tags to your patches: only Cc: is appropriate
> for addition without the explicit permission of the person named.



Thanks,

James

Re: [RFC/RFT PATCH 3/6] ACPI / APEI: Replace ioremap_page_range() with fixmap

[Borislav Petkov]

On Tue, Oct 31, 2017 at 03:38:29PM +0000, James Morse wrote:
> Replace ghes_io{re,un}map_pfn_{nmi,irq}()s use of ioremap_page_range()
> with __set_fixmap() as ioremap_page_range() may sleep to allocate a new
> level of page-table, even if its passed an existing final-address to
> use in the mapping.
> 
> clear_fixmap() does the TLB invalidation in __set_fixmap() for arm64
> and __set_pte_vaddr() for x86. In each case its the same as the
> respective arch_apei_flush_tlb_one().
> 
> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: James Morse <james.morse@arm.com>
> CC: Tyler Baicar <tbaicar@codeaurora.org>
> CC: Dongjiu Geng <gengdongjiu@huawei.com>
> CC: Xie XiuQi <xiexiuqi@huawei.com>
> 
> ---
> CC'd people I've seen posting CPER log fragments, could you give this a
> test on your platforms?
> 
>  drivers/acpi/apei/ghes.c | 45 +++++++++++++++------------------------------
>  1 file changed, 15 insertions(+), 30 deletions(-)

Reviewed-by: Borislav Petkov <bp@suse.de>

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[RFC/RFT PATCH 3/6] ACPI / APEI: Replace ioremap_page_range() with fixmap

[Borislav Petkov]

On Tue, Oct 31, 2017 at 03:38:29PM +0000, James Morse wrote:
> Replace ghes_io{re,un}map_pfn_{nmi,irq}()s use of ioremap_page_range()
> with __set_fixmap() as ioremap_page_range() may sleep to allocate a new
> level of page-table, even if its passed an existing final-address to
> use in the mapping.
> 
> clear_fixmap() does the TLB invalidation in __set_fixmap() for arm64
> and __set_pte_vaddr() for x86. In each case its the same as the
> respective arch_apei_flush_tlb_one().
> 
> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: James Morse <james.morse@arm.com>
> CC: Tyler Baicar <tbaicar@codeaurora.org>
> CC: Dongjiu Geng <gengdongjiu@huawei.com>
> CC: Xie XiuQi <xiexiuqi@huawei.com>
> 
> ---
> CC'd people I've seen posting CPER log fragments, could you give this a
> test on your platforms?
> 
>  drivers/acpi/apei/ghes.c | 45 +++++++++++++++------------------------------
>  1 file changed, 15 insertions(+), 30 deletions(-)

Reviewed-by: Borislav Petkov <bp@suse.de>

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imend?rffer, Jane Smithard, Graham Norton, HRB 21284 (AG N?rnberg)
-- 

[RFC/RFT PATCH 4/6] ACPI / APEI: Remove ghes_ioremap_area

[James Morse]

Now that nothing is using the ghes_ioremap_area pages, rip them out.

Signed-off-by: James Morse <james.morse@arm.com>
---
 drivers/acpi/apei/ghes.c | 39 ++-------------------------------------
 1 file changed, 2 insertions(+), 37 deletions(-)

diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index f3269816b997..1a4f16b10052 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -114,19 +114,7 @@ static DEFINE_MUTEX(ghes_list_mutex);
  * from BIOS to Linux can be determined only in NMI, IRQ or timer
  * handler, but general ioremap can not be used in atomic context, so
  * the fixmap is used instead.
- */
-
-/*
- * Two virtual pages are used, one for IRQ/PROCESS context, the other for
- * NMI context (optionally).
- */
-#define GHES_IOREMAP_PAGES           2
-#define GHES_IOREMAP_IRQ_PAGE(base)	(base)
-#define GHES_IOREMAP_NMI_PAGE(base)	((base) + PAGE_SIZE)
-
-/* virtual memory area for atomic ioremap */
-static struct vm_struct *ghes_ioremap_area;
-/*
+ *
  * These 2 spinlocks are used to prevent the fixmap entries from being used
  * simultaneously.
  */
@@ -141,23 +129,6 @@ static atomic_t ghes_estatus_cache_alloced;
 
 static int ghes_panic_timeout __read_mostly = 30;
 
-static int ghes_ioremap_init(void)
-{
-	ghes_ioremap_area = __get_vm_area(PAGE_SIZE * GHES_IOREMAP_PAGES,
-		VM_IOREMAP, VMALLOC_START, VMALLOC_END);
-	if (!ghes_ioremap_area) {
-		pr_err(GHES_PFX "Failed to allocate virtual memory area for atomic ioremap.\n");
-		return -ENOMEM;
-	}
-
-	return 0;
-}
-
-static void ghes_ioremap_exit(void)
-{
-	free_vm_area(ghes_ioremap_area);
-}
-
 static void __iomem *ghes_ioremap_pfn_nmi(u64 pfn)
 {
 	phys_addr_t paddr;
@@ -1270,13 +1241,9 @@ static int __init ghes_init(void)
 
 	ghes_nmi_init_cxt();
 
-	rc = ghes_ioremap_init();
-	if (rc)
-		goto err;
-
 	rc = ghes_estatus_pool_init();
 	if (rc)
-		goto err_ioremap_exit;
+		goto err;
 
 	rc = ghes_estatus_pool_expand(GHES_ESTATUS_CACHE_AVG_SIZE *
 				      GHES_ESTATUS_CACHE_ALLOCED_MAX);
@@ -1300,8 +1267,6 @@ static int __init ghes_init(void)
 	return 0;
 err_pool_exit:
 	ghes_estatus_pool_exit();
-err_ioremap_exit:
-	ghes_ioremap_exit();
 err:
 	return rc;
 }
-- 
2.15.0.rc2

[RFC/RFT PATCH 4/6] ACPI / APEI: Remove ghes_ioremap_area

[James Morse]

Now that nothing is using the ghes_ioremap_area pages, rip them out.

Signed-off-by: James Morse <james.morse@arm.com>
---
 drivers/acpi/apei/ghes.c | 39 ++-------------------------------------
 1 file changed, 2 insertions(+), 37 deletions(-)

diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index f3269816b997..1a4f16b10052 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -114,19 +114,7 @@ static DEFINE_MUTEX(ghes_list_mutex);
  * from BIOS to Linux can be determined only in NMI, IRQ or timer
  * handler, but general ioremap can not be used in atomic context, so
  * the fixmap is used instead.
- */
-
-/*
- * Two virtual pages are used, one for IRQ/PROCESS context, the other for
- * NMI context (optionally).
- */
-#define GHES_IOREMAP_PAGES           2
-#define GHES_IOREMAP_IRQ_PAGE(base)	(base)
-#define GHES_IOREMAP_NMI_PAGE(base)	((base) + PAGE_SIZE)
-
-/* virtual memory area for atomic ioremap */
-static struct vm_struct *ghes_ioremap_area;
-/*
+ *
  * These 2 spinlocks are used to prevent the fixmap entries from being used
  * simultaneously.
  */
@@ -141,23 +129,6 @@ static atomic_t ghes_estatus_cache_alloced;
 
 static int ghes_panic_timeout __read_mostly = 30;
 
-static int ghes_ioremap_init(void)
-{
-	ghes_ioremap_area = __get_vm_area(PAGE_SIZE * GHES_IOREMAP_PAGES,
-		VM_IOREMAP, VMALLOC_START, VMALLOC_END);
-	if (!ghes_ioremap_area) {
-		pr_err(GHES_PFX "Failed to allocate virtual memory area for atomic ioremap.\n");
-		return -ENOMEM;
-	}
-
-	return 0;
-}
-
-static void ghes_ioremap_exit(void)
-{
-	free_vm_area(ghes_ioremap_area);
-}
-
 static void __iomem *ghes_ioremap_pfn_nmi(u64 pfn)
 {
 	phys_addr_t paddr;
@@ -1270,13 +1241,9 @@ static int __init ghes_init(void)
 
 	ghes_nmi_init_cxt();
 
-	rc = ghes_ioremap_init();
-	if (rc)
-		goto err;
-
 	rc = ghes_estatus_pool_init();
 	if (rc)
-		goto err_ioremap_exit;
+		goto err;
 
 	rc = ghes_estatus_pool_expand(GHES_ESTATUS_CACHE_AVG_SIZE *
 				      GHES_ESTATUS_CACHE_ALLOCED_MAX);
@@ -1300,8 +1267,6 @@ static int __init ghes_init(void)
 	return 0;
 err_pool_exit:
 	ghes_estatus_pool_exit();
-err_ioremap_exit:
-	ghes_ioremap_exit();
 err:
 	return rc;
 }
-- 
2.15.0.rc2

Re: [RFC/RFT PATCH 4/6] ACPI / APEI: Remove ghes_ioremap_area

[Borislav Petkov]

On Tue, Oct 31, 2017 at 03:38:30PM +0000, James Morse wrote:
> Now that nothing is using the ghes_ioremap_area pages, rip them out.
> 
> Signed-off-by: James Morse <james.morse@arm.com>
> ---
>  drivers/acpi/apei/ghes.c | 39 ++-------------------------------------
>  1 file changed, 2 insertions(+), 37 deletions(-)

Reviewed-by: Borislav Petkov <bp@suse.de>

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[RFC/RFT PATCH 4/6] ACPI / APEI: Remove ghes_ioremap_area

[Borislav Petkov]

On Tue, Oct 31, 2017 at 03:38:30PM +0000, James Morse wrote:
> Now that nothing is using the ghes_ioremap_area pages, rip them out.
> 
> Signed-off-by: James Morse <james.morse@arm.com>
> ---
>  drivers/acpi/apei/ghes.c | 39 ++-------------------------------------
>  1 file changed, 2 insertions(+), 37 deletions(-)

Reviewed-by: Borislav Petkov <bp@suse.de>

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imend?rffer, Jane Smithard, Graham Norton, HRB 21284 (AG N?rnberg)
-- 

[RFC/RFT PATCH 5/6] arm64: mm: Remove arch_apei_flush_tlb_one()

[James Morse]

Nothing calls arch_apei_flush_tlb_one() anymore, instead relying on
__set_fixmap() to do the invalidation. Remove it.

Move the IPI-considered-harmful comment to __set_fixmap().

Signed-off-by: James Morse <james.morse@arm.com>
---
 arch/arm64/include/asm/acpi.h | 12 ------------
 arch/arm64/mm/mmu.c           |  4 ++++
 2 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 59cca1d6ec54..32f465a80e4e 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -126,18 +126,6 @@ static inline const char *acpi_get_enable_method(int cpu)
  */
 #define acpi_disable_cmcff 1
 pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr);
-
-/*
- * Despite its name, this function must still broadcast the TLB
- * invalidation in order to ensure other CPUs don't end up with junk
- * entries as a result of speculation. Unusually, its also called in
- * IRQ context (ghes_iounmap_irq) so if we ever need to use IPIs for
- * TLB broadcasting, then we're in trouble here.
- */
-static inline void arch_apei_flush_tlb_one(unsigned long addr)
-{
-	flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
-}
 #endif /* CONFIG_ACPI_APEI */
 
 #ifdef CONFIG_ACPI_NUMA
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index f1eb15e0e864..267d2b79d52d 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -778,6 +778,10 @@ void __init early_fixmap_init(void)
 	}
 }
 
+/*
+ * Unusually, this is also called in IRQ context (ghes_iounmap_irq) so if we
+ * ever need to use IPIs for TLB broadcasting, then we're in trouble here.
+ */
 void __set_fixmap(enum fixed_addresses idx,
 			       phys_addr_t phys, pgprot_t flags)
 {
-- 
2.15.0.rc2

[RFC/RFT PATCH 5/6] arm64: mm: Remove arch_apei_flush_tlb_one()

[James Morse]

Nothing calls arch_apei_flush_tlb_one() anymore, instead relying on
__set_fixmap() to do the invalidation. Remove it.

Move the IPI-considered-harmful comment to __set_fixmap().

Signed-off-by: James Morse <james.morse@arm.com>
---
 arch/arm64/include/asm/acpi.h | 12 ------------
 arch/arm64/mm/mmu.c           |  4 ++++
 2 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 59cca1d6ec54..32f465a80e4e 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -126,18 +126,6 @@ static inline const char *acpi_get_enable_method(int cpu)
  */
 #define acpi_disable_cmcff 1
 pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr);
-
-/*
- * Despite its name, this function must still broadcast the TLB
- * invalidation in order to ensure other CPUs don't end up with junk
- * entries as a result of speculation. Unusually, its also called in
- * IRQ context (ghes_iounmap_irq) so if we ever need to use IPIs for
- * TLB broadcasting, then we're in trouble here.
- */
-static inline void arch_apei_flush_tlb_one(unsigned long addr)
-{
-	flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
-}
 #endif /* CONFIG_ACPI_APEI */
 
 #ifdef CONFIG_ACPI_NUMA
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index f1eb15e0e864..267d2b79d52d 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -778,6 +778,10 @@ void __init early_fixmap_init(void)
 	}
 }
 
+/*
+ * Unusually, this is also called in IRQ context (ghes_iounmap_irq) so if we
+ * ever need to use IPIs for TLB broadcasting, then we're in trouble here.
+ */
 void __set_fixmap(enum fixed_addresses idx,
 			       phys_addr_t phys, pgprot_t flags)
 {
-- 
2.15.0.rc2

[RFC/RFT PATCH 6/6] ACPI / APEI: Remove arch_apei_flush_tlb_one()

[James Morse]

Nothing calls arch_apei_flush_tlb_one() anymore, instead relying on
__set_pte_vaddr() to do the invalidation when called from clear_fixmap()
Remove arch_apei_flush_tlb_one().

Signed-off-by: James Morse <james.morse@arm.com>
---
 arch/x86/kernel/acpi/apei.c | 5 -----
 include/acpi/apei.h         | 1 -
 2 files changed, 6 deletions(-)

diff --git a/arch/x86/kernel/acpi/apei.c b/arch/x86/kernel/acpi/apei.c
index ea3046e0b0cf..bb8d300fecbd 100644
--- a/arch/x86/kernel/acpi/apei.c
+++ b/arch/x86/kernel/acpi/apei.c
@@ -52,8 +52,3 @@ void arch_apei_report_mem_error(int sev, struct cper_sec_mem_err *mem_err)
 	apei_mce_report_mem_error(sev, mem_err);
 #endif
 }
-
-void arch_apei_flush_tlb_one(unsigned long addr)
-{
-	__flush_tlb_one(addr);
-}
diff --git a/include/acpi/apei.h b/include/acpi/apei.h
index c46694abea28..82c451698c98 100644
--- a/include/acpi/apei.h
+++ b/include/acpi/apei.h
@@ -50,7 +50,6 @@ int erst_clear(u64 record_id);
 
 int arch_apei_enable_cmcff(struct acpi_hest_header *hest_hdr, void *data);
 void arch_apei_report_mem_error(int sev, struct cper_sec_mem_err *mem_err);
-void arch_apei_flush_tlb_one(unsigned long addr);
 
 #endif
 #endif
-- 
2.15.0.rc2

[RFC/RFT PATCH 6/6] ACPI / APEI: Remove arch_apei_flush_tlb_one()

[James Morse]

Nothing calls arch_apei_flush_tlb_one() anymore, instead relying on
__set_pte_vaddr() to do the invalidation when called from clear_fixmap()
Remove arch_apei_flush_tlb_one().

Signed-off-by: James Morse <james.morse@arm.com>
---
 arch/x86/kernel/acpi/apei.c | 5 -----
 include/acpi/apei.h         | 1 -
 2 files changed, 6 deletions(-)

diff --git a/arch/x86/kernel/acpi/apei.c b/arch/x86/kernel/acpi/apei.c
index ea3046e0b0cf..bb8d300fecbd 100644
--- a/arch/x86/kernel/acpi/apei.c
+++ b/arch/x86/kernel/acpi/apei.c
@@ -52,8 +52,3 @@ void arch_apei_report_mem_error(int sev, struct cper_sec_mem_err *mem_err)
 	apei_mce_report_mem_error(sev, mem_err);
 #endif
 }
-
-void arch_apei_flush_tlb_one(unsigned long addr)
-{
-	__flush_tlb_one(addr);
-}
diff --git a/include/acpi/apei.h b/include/acpi/apei.h
index c46694abea28..82c451698c98 100644
--- a/include/acpi/apei.h
+++ b/include/acpi/apei.h
@@ -50,7 +50,6 @@ int erst_clear(u64 record_id);
 
 int arch_apei_enable_cmcff(struct acpi_hest_header *hest_hdr, void *data);
 void arch_apei_report_mem_error(int sev, struct cper_sec_mem_err *mem_err);
-void arch_apei_flush_tlb_one(unsigned long addr);
 
 #endif
 #endif
-- 
2.15.0.rc2

Re: [RFC/RFT PATCH 6/6] ACPI / APEI: Remove arch_apei_flush_tlb_one()

[Borislav Petkov]

On Tue, Oct 31, 2017 at 03:38:32PM +0000, James Morse wrote:
> Nothing calls arch_apei_flush_tlb_one() anymore, instead relying on
> __set_pte_vaddr() to do the invalidation when called from clear_fixmap()
> Remove arch_apei_flush_tlb_one().
> 
> Signed-off-by: James Morse <james.morse@arm.com>
> ---
>  arch/x86/kernel/acpi/apei.c | 5 -----
>  include/acpi/apei.h         | 1 -
>  2 files changed, 6 deletions(-)

Reviewed-by: Borislav Petkov <bp@suse.de>

Very nice cleanup. Thanks for doing this!

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[RFC/RFT PATCH 6/6] ACPI / APEI: Remove arch_apei_flush_tlb_one()

[Borislav Petkov]

On Tue, Oct 31, 2017 at 03:38:32PM +0000, James Morse wrote:
> Nothing calls arch_apei_flush_tlb_one() anymore, instead relying on
> __set_pte_vaddr() to do the invalidation when called from clear_fixmap()
> Remove arch_apei_flush_tlb_one().
> 
> Signed-off-by: James Morse <james.morse@arm.com>
> ---
>  arch/x86/kernel/acpi/apei.c | 5 -----
>  include/acpi/apei.h         | 1 -
>  2 files changed, 6 deletions(-)

Reviewed-by: Borislav Petkov <bp@suse.de>

Very nice cleanup. Thanks for doing this!

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imend?rffer, Jane Smithard, Graham Norton, HRB 21284 (AG N?rnberg)
-- 

Re: [RFC/RFT PATCH 0/6] Switch GHES ioremap_page_range() to use fixmap

[Linus Torvalds]

On Tue, Oct 31, 2017 at 8:38 AM, James Morse <james.morse@arm.com> wrote:
>  7 files changed, 30 insertions(+), 85 deletions(-)

Lovely.

I obviously can't test it, but it looks fine. I *would* suggest just
making the "add fixmap entries" commits with the code that actually
uses them. There's no real reason to have two commits that just add
two entries that aren't used yet.

If it was some meaningful helper function where a split of the commits
makes each commit easier to read, that would be one thing.  As it is,
the split just makes it harder to look at the history of the code (ie
"I wonder where this was introduced - let's use 'git blame'. Oh,
that's not useful").

                  Linus

[RFC/RFT PATCH 0/6] Switch GHES ioremap_page_range() to use fixmap

[Linus Torvalds]

On Tue, Oct 31, 2017 at 8:38 AM, James Morse <james.morse@arm.com> wrote:
>  7 files changed, 30 insertions(+), 85 deletions(-)

Lovely.

I obviously can't test it, but it looks fine. I *would* suggest just
making the "add fixmap entries" commits with the code that actually
uses them. There's no real reason to have two commits that just add
two entries that aren't used yet.

If it was some meaningful helper function where a split of the commits
makes each commit easier to read, that would be one thing.  As it is,
the split just makes it harder to look at the history of the code (ie
"I wonder where this was introduced - let's use 'git blame'. Oh,
that's not useful").

                  Linus

Re: [RFC/RFT PATCH 0/6] Switch GHES ioremap_page_range() to use fixmap

[Linus Torvalds]

On Tue, Oct 31, 2017 at 8:38 AM, James Morse <james.morse@arm.com> wrote:
>  7 files changed, 30 insertions(+), 85 deletions(-)

Lovely.

I obviously can't test it, but it looks fine. I *would* suggest just
making the "add fixmap entries" commits with the code that actually
uses them. There's no real reason to have two commits that just add
two entries that aren't used yet.

If it was some meaningful helper function where a split of the commits
makes each commit easier to read, that would be one thing.  As it is,
the split just makes it harder to look at the history of the code (ie
"I wonder where this was introduced - let's use 'git blame'. Oh,
that's not useful").

                  Linus

Re: [RFC/RFT PATCH 0/6] Switch GHES ioremap_page_range() to use fixmap

[Linus Torvalds]

On Tue, Oct 31, 2017 at 8:52 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Tue, Oct 31, 2017 at 8:38 AM, James Morse <james.morse@arm.com> wrote:
>>  7 files changed, 30 insertions(+), 85 deletions(-)
>
> Lovely.

Side note: it wasn't entirely obvious what restricted the ghes driver
to only x86 and arm64. I had to look up the whole HAVE_ACPI_APEI
dependency.

So it might be worth mentioning in the commit message why it's ok to
only add the fixmap entries for those two architectures and why it's
not an issue for anything else.

           Linus

[RFC/RFT PATCH 0/6] Switch GHES ioremap_page_range() to use fixmap

[Linus Torvalds]

On Tue, Oct 31, 2017 at 8:52 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Tue, Oct 31, 2017 at 8:38 AM, James Morse <james.morse@arm.com> wrote:
>>  7 files changed, 30 insertions(+), 85 deletions(-)
>
> Lovely.

Side note: it wasn't entirely obvious what restricted the ghes driver
to only x86 and arm64. I had to look up the whole HAVE_ACPI_APEI
dependency.

So it might be worth mentioning in the commit message why it's ok to
only add the fixmap entries for those two architectures and why it's
not an issue for anything else.

           Linus

Re: [RFC/RFT PATCH 0/6] Switch GHES ioremap_page_range() to use fixmap

[Linus Torvalds]

On Tue, Oct 31, 2017 at 8:52 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Tue, Oct 31, 2017 at 8:38 AM, James Morse <james.morse@arm.com> wrote:
>>  7 files changed, 30 insertions(+), 85 deletions(-)
>
> Lovely.

Side note: it wasn't entirely obvious what restricted the ghes driver
to only x86 and arm64. I had to look up the whole HAVE_ACPI_APEI
dependency.

So it might be worth mentioning in the commit message why it's ok to
only add the fixmap entries for those two architectures and why it's
not an issue for anything else.

           Linus

Re: [RFC/RFT PATCH 0/6] Switch GHES ioremap_page_range() to use fixmap

[James Morse]

Hi Linus,

On 31/10/17 15:52, Linus Torvalds wrote:
> On Tue, Oct 31, 2017 at 8:38 AM, James Morse <james.morse@arm.com> wrote:
>>  7 files changed, 30 insertions(+), 85 deletions(-)
> 
> Lovely.
> 
> I obviously can't test it, but it looks fine. I *would* suggest just
> making the "add fixmap entries" commits with the code that actually
> uses them. There's no real reason to have two commits that just add
> two entries that aren't used yet.
> 
> If it was some meaningful helper function where a split of the commits
> makes each commit easier to read, that would be one thing.  As it is,
> the split just makes it harder to look at the history of the code (ie
> "I wonder where this was introduced - let's use 'git blame'. Oh,
> that's not useful").

I will squash the first three patches together to fix this, and add something
about HAVE_ACPI_APEI to the commit message.

(I'm still holding out for someone to test this on an x86 system with NOTIFY_NMI)


Thanks,

James

[RFC/RFT PATCH 0/6] Switch GHES ioremap_page_range() to use fixmap

[James Morse]

Hi Linus,

On 31/10/17 15:52, Linus Torvalds wrote:
> On Tue, Oct 31, 2017 at 8:38 AM, James Morse <james.morse@arm.com> wrote:
>>  7 files changed, 30 insertions(+), 85 deletions(-)
> 
> Lovely.
> 
> I obviously can't test it, but it looks fine. I *would* suggest just
> making the "add fixmap entries" commits with the code that actually
> uses them. There's no real reason to have two commits that just add
> two entries that aren't used yet.
> 
> If it was some meaningful helper function where a split of the commits
> makes each commit easier to read, that would be one thing.  As it is,
> the split just makes it harder to look at the history of the code (ie
> "I wonder where this was introduced - let's use 'git blame'. Oh,
> that's not useful").

I will squash the first three patches together to fix this, and add something
about HAVE_ACPI_APEI to the commit message.

(I'm still holding out for someone to test this on an x86 system with NOTIFY_NMI)


Thanks,

James

Re: [RFC/RFT PATCH 0/6] Switch GHES ioremap_page_range() to use fixmap

[James Morse]

Hi Linus,

On 31/10/17 15:52, Linus Torvalds wrote:
> On Tue, Oct 31, 2017 at 8:38 AM, James Morse <james.morse@arm.com> wrote:
>>  7 files changed, 30 insertions(+), 85 deletions(-)
> 
> Lovely.
> 
> I obviously can't test it, but it looks fine. I *would* suggest just
> making the "add fixmap entries" commits with the code that actually
> uses them. There's no real reason to have two commits that just add
> two entries that aren't used yet.
> 
> If it was some meaningful helper function where a split of the commits
> makes each commit easier to read, that would be one thing.  As it is,
> the split just makes it harder to look at the history of the code (ie
> "I wonder where this was introduced - let's use 'git blame'. Oh,
> that's not useful").

I will squash the first three patches together to fix this, and add something
about HAVE_ACPI_APEI to the commit message.

(I'm still holding out for someone to test this on an x86 system with NOTIFY_NMI)


Thanks,

James

Re: [RFC/RFT PATCH 0/6] Switch GHES ioremap_page_range() to use fixmap

[Tyler Baicar]

On 10/31/2017 11:38 AM, James Morse wrote:
> GHES is doing ioremap_page_range() in both NMI and irq context, neither
> are safe as it may sleep to allocate intermediate levels of page table.
>
> Replace the NMI/irq GHES_IOREMAP_PAGES to use a fixmap entry each.
>
> After this nothing uses ghes_ioremap_area or arch_apei_flush_tlb_one(),
> rip them out.
>
> RFC as I've only build-tested this on x86. For arm64 I've tested it on a
> software model. Any more testing would be welcome. These patches are based
> on rc7.
For the arm64 and APEI patches:
Tested-by: Tyler Baicar <tbaicar@codeaurora.org>

Verified on arm64. I no longer see the BUGs in the GHES code. Thanks!

Tyler

-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

[RFC/RFT PATCH 0/6] Switch GHES ioremap_page_range() to use fixmap

[Tyler Baicar]

On 10/31/2017 11:38 AM, James Morse wrote:
> GHES is doing ioremap_page_range() in both NMI and irq context, neither
> are safe as it may sleep to allocate intermediate levels of page table.
>
> Replace the NMI/irq GHES_IOREMAP_PAGES to use a fixmap entry each.
>
> After this nothing uses ghes_ioremap_area or arch_apei_flush_tlb_one(),
> rip them out.
>
> RFC as I've only build-tested this on x86. For arm64 I've tested it on a
> software model. Any more testing would be welcome. These patches are based
> on rc7.
For the arm64 and APEI patches:
Tested-by: Tyler Baicar <tbaicar@codeaurora.org>

Verified on arm64. I no longer see the BUGs in the GHES code. Thanks!

Tyler

-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

Re: [RFC/RFT PATCH 0/6] Switch GHES ioremap_page_range() to use fixmap

[James Morse]

Hi guys,

(+CC: Chen Gong and Huang Ying from the git log of [0])

On 31/10/17 15:38, James Morse wrote:
> RFC as I've only build-tested this on x86.

Does anyone have an x86 machine that does firmware-first using NOTIFY_NMI?


> Any more testing would be welcome.

('ls /sys/firmware/acpi/tables/', if you have a HEST and EINJ we should be able
to work something out)


Thanks,

James

[0] https://www.kernel.org/doc/Documentation/acpi/apei/einj.txt

[RFC/RFT PATCH 0/6] Switch GHES ioremap_page_range() to use fixmap

[James Morse]

Hi guys,

(+CC: Chen Gong and Huang Ying from the git log of [0])

On 31/10/17 15:38, James Morse wrote:
> RFC as I've only build-tested this on x86.

Does anyone have an x86 machine that does firmware-first using NOTIFY_NMI?


> Any more testing would be welcome.

('ls /sys/firmware/acpi/tables/', if you have a HEST and EINJ we should be able
to work something out)


Thanks,

James

[0] https://www.kernel.org/doc/Documentation/acpi/apei/einj.txt

Re: [RFC/RFT PATCH 0/6] Switch GHES ioremap_page_range() to use fixmap

[Borislav Petkov]

On Wed, Nov 01, 2017 at 02:58:33PM +0000, James Morse wrote:
> Does anyone have an x86 machine that does firmware-first using NOTIFY_NMI?

AFAIK, the only one who has access to a reportedly somewhat working GHES
implementation is Toshi. CCed.

> ('ls /sys/firmware/acpi/tables/', if you have a HEST and EINJ we should be able
> to work something out)

That's not enough. All the EINJ boxes I have would stop accepting EINJ
writes after a couple of injections, i.e., BIOS would get "stuffed". :-)))

Maybe Tony has something better. He's already on CC.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[RFC/RFT PATCH 0/6] Switch GHES ioremap_page_range() to use fixmap

[Borislav Petkov]

On Wed, Nov 01, 2017 at 02:58:33PM +0000, James Morse wrote:
> Does anyone have an x86 machine that does firmware-first using NOTIFY_NMI?

AFAIK, the only one who has access to a reportedly somewhat working GHES
implementation is Toshi. CCed.

> ('ls /sys/firmware/acpi/tables/', if you have a HEST and EINJ we should be able
> to work something out)

That's not enough. All the EINJ boxes I have would stop accepting EINJ
writes after a couple of injections, i.e., BIOS would get "stuffed". :-)))

Maybe Tony has something better. He's already on CC.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imend?rffer, Jane Smithard, Graham Norton, HRB 21284 (AG N?rnberg)
-- 

Re: [RFC/RFT PATCH 0/6] Switch GHES ioremap_page_range() to use fixmap

[Kani, Toshimitsu]

On Wed, 2017-11-01 at 16:30 +0100, Borislav Petkov wrote:
> On Wed, Nov 01, 2017 at 02:58:33PM +0000, James Morse wrote:
> > Does anyone have an x86 machine that does firmware-first using NOTIFY_NMI?
> 
> AFAIK, the only one who has access to a reportedly somewhat working GHES
> implementation is Toshi. CCed.

Thanks for the heads-up.  My x86 system only supports GHES with SCI
error sources.  It uses MCE for synchronous error events.

So, for x86 SCI error sources:

Tested-by: Toshi Kani <toshi.kani@hpe.com>

nit: I think ghes_ioremap_pfn_[nmi|irq] should be renamed since they no
longer use ioremap. 

-Toshi

[RFC/RFT PATCH 0/6] Switch GHES ioremap_page_range() to use fixmap

[Kani, Toshimitsu]

On Wed, 2017-11-01 at 16:30 +0100, Borislav Petkov wrote:
> On Wed, Nov 01, 2017 at 02:58:33PM +0000, James Morse wrote:
> > Does anyone have an x86 machine that does firmware-first using NOTIFY_NMI?
> 
> AFAIK, the only one who has access to a reportedly somewhat working GHES
> implementation is Toshi. CCed.

Thanks for the heads-up.  My x86 system only supports GHES with SCI
error sources.  It uses MCE for synchronous error events.

So, for x86 SCI error sources:

Tested-by: Toshi Kani <toshi.kani@hpe.com>

nit: I think ghes_ioremap_pfn_[nmi|irq] should be renamed since they no
longer use ioremap. 

-Toshi

Re: [RFC/RFT PATCH 0/6] Switch GHES ioremap_page_range() to use fixmap

[Kani, Toshimitsu]

On Wed, 2017-11-01 at 16:30 +0100, Borislav Petkov wrote:
> On Wed, Nov 01, 2017 at 02:58:33PM +0000, James Morse wrote:
> > Does anyone have an x86 machine that does firmware-first using NOTIFY_NMI?
> 
> AFAIK, the only one who has access to a reportedly somewhat working GHES
> implementation is Toshi. CCed.

Thanks for the heads-up.  My x86 system only supports GHES with SCI
error sources.  It uses MCE for synchronous error events.

So, for x86 SCI error sources:

Tested-by: Toshi Kani <toshi.kani@hpe.com>

nit: I think ghes_ioremap_pfn_[nmi|irq] should be renamed since they no
longer use ioremap. 

-Toshi

Re: [RFC/RFT PATCH 0/6] Switch GHES ioremap_page_range() to use fixmap

[James Morse]

On 01/11/17 18:20, Kani, Toshimitsu wrote:
> On Wed, 2017-11-01 at 16:30 +0100, Borislav Petkov wrote:
>> On Wed, Nov 01, 2017 at 02:58:33PM +0000, James Morse wrote:
>>> Does anyone have an x86 machine that does firmware-first using NOTIFY_NMI?

>> AFAIK, the only one who has access to a reportedly somewhat working GHES
>> implementation is Toshi. CCed.
> 
> Thanks for the heads-up.  My x86 system only supports GHES with SCI
> error sources.  It uses MCE for synchronous error events.
> 
> So, for x86 SCI error sources:
> 
> Tested-by: Toshi Kani <toshi.kani@hpe.com>

Thanks Toshi!


> nit: I think ghes_ioremap_pfn_[nmi|irq] should be renamed since they no
> longer use ioremap. 

I thought that would be too noisy...

I have some more rework to do in here before we can merge the other arm64 RAS
stuff, I can take that into account then.


Thanks,

James

[RFC/RFT PATCH 0/6] Switch GHES ioremap_page_range() to use fixmap

[James Morse]

On 01/11/17 18:20, Kani, Toshimitsu wrote:
> On Wed, 2017-11-01 at 16:30 +0100, Borislav Petkov wrote:
>> On Wed, Nov 01, 2017 at 02:58:33PM +0000, James Morse wrote:
>>> Does anyone have an x86 machine that does firmware-first using NOTIFY_NMI?

>> AFAIK, the only one who has access to a reportedly somewhat working GHES
>> implementation is Toshi. CCed.
> 
> Thanks for the heads-up.  My x86 system only supports GHES with SCI
> error sources.  It uses MCE for synchronous error events.
> 
> So, for x86 SCI error sources:
> 
> Tested-by: Toshi Kani <toshi.kani@hpe.com>

Thanks Toshi!


> nit: I think ghes_ioremap_pfn_[nmi|irq] should be renamed since they no
> longer use ioremap. 

I thought that would be too noisy...

I have some more rework to do in here before we can merge the other arm64 RAS
stuff, I can take that into account then.


Thanks,

James

Re: [RFC/RFT PATCH 0/6] Switch GHES ioremap_page_range() to use fixmap

[James Morse]

On 01/11/17 18:20, Kani, Toshimitsu wrote:
> On Wed, 2017-11-01 at 16:30 +0100, Borislav Petkov wrote:
>> On Wed, Nov 01, 2017 at 02:58:33PM +0000, James Morse wrote:
>>> Does anyone have an x86 machine that does firmware-first using NOTIFY_NMI?

>> AFAIK, the only one who has access to a reportedly somewhat working GHES
>> implementation is Toshi. CCed.
> 
> Thanks for the heads-up.  My x86 system only supports GHES with SCI
> error sources.  It uses MCE for synchronous error events.
> 
> So, for x86 SCI error sources:
> 
> Tested-by: Toshi Kani <toshi.kani@hpe.com>

Thanks Toshi!


> nit: I think ghes_ioremap_pfn_[nmi|irq] should be renamed since they no
> longer use ioremap. 

I thought that would be too noisy...

I have some more rework to do in here before we can merge the other arm64 RAS
stuff, I can take that into account then.


Thanks,

James

Re: [RFC/RFT PATCH 0/6] Switch GHES ioremap_page_range() to use fixmap

[Will Deacon]

On Tue, Oct 31, 2017 at 03:38:26PM +0000, James Morse wrote:
> GHES is doing ioremap_page_range() in both NMI and irq context, neither
> are safe as it may sleep to allocate intermediate levels of page table.
> 
> Replace the NMI/irq GHES_IOREMAP_PAGES to use a fixmap entry each.
> 
> After this nothing uses ghes_ioremap_area or arch_apei_flush_tlb_one(),
> rip them out.
> 
> RFC as I've only build-tested this on x86. For arm64 I've tested it on a
> software model. Any more testing would be welcome. These patches are based
> on rc7.
> 
> Thanks,
> 
> James Morse (6):
>   arm64: fixmap: Add GHES fixmap entries
>   x86/mm/fixmap: Add GHES fixmap entries
>   ACPI / APEI:  Replace ioremap_page_range() with fixmap
>   ACPI / APEI: Remove ghes_ioremap_area
>   arm64: mm: Remove arch_apei_flush_tlb_one()
>   ACPI / APEI: Remove arch_apei_flush_tlb_one()
> 
>  arch/arm64/include/asm/acpi.h   | 12 ------
>  arch/arm64/include/asm/fixmap.h |  5 +++
>  arch/arm64/mm/mmu.c             |  4 ++

If you need it:

Acked-by: Will Deacon <will.deacon@arm.com>

for the arm64 bits.

Will

[RFC/RFT PATCH 0/6] Switch GHES ioremap_page_range() to use fixmap

[Will Deacon]

On Tue, Oct 31, 2017 at 03:38:26PM +0000, James Morse wrote:
> GHES is doing ioremap_page_range() in both NMI and irq context, neither
> are safe as it may sleep to allocate intermediate levels of page table.
> 
> Replace the NMI/irq GHES_IOREMAP_PAGES to use a fixmap entry each.
> 
> After this nothing uses ghes_ioremap_area or arch_apei_flush_tlb_one(),
> rip them out.
> 
> RFC as I've only build-tested this on x86. For arm64 I've tested it on a
> software model. Any more testing would be welcome. These patches are based
> on rc7.
> 
> Thanks,
> 
> James Morse (6):
>   arm64: fixmap: Add GHES fixmap entries
>   x86/mm/fixmap: Add GHES fixmap entries
>   ACPI / APEI:  Replace ioremap_page_range() with fixmap
>   ACPI / APEI: Remove ghes_ioremap_area
>   arm64: mm: Remove arch_apei_flush_tlb_one()
>   ACPI / APEI: Remove arch_apei_flush_tlb_one()
> 
>  arch/arm64/include/asm/acpi.h   | 12 ------
>  arch/arm64/include/asm/fixmap.h |  5 +++
>  arch/arm64/mm/mmu.c             |  4 ++

If you need it:

Acked-by: Will Deacon <will.deacon@arm.com>

for the arm64 bits.

Will

Re: [RFC/RFT PATCH 0/6] Switch GHES ioremap_page_range() to use fixmap

[Zhengqiang]

On 2017/10/31 23:38, James Morse wrote:
> GHES is doing ioremap_page_range() in both NMI and irq context, neither
> are safe as it may sleep to allocate intermediate levels of page table.
> 
> Replace the NMI/irq GHES_IOREMAP_PAGES to use a fixmap entry each.
> 
> After this nothing uses ghes_ioremap_area or arch_apei_flush_tlb_one(),
> rip them out.
> 
> RFC as I've only build-tested this on x86. For arm64 I've tested it on a
> software model. Any more testing would be welcome. These patches are based
> on rc7.
> 


Tested-by:  Qiang Zheng <zhengqiang10@huawei.com>

Verified on our arm64, it work for me. Thanks.

Qiang

[RFC/RFT PATCH 0/6] Switch GHES ioremap_page_range() to use fixmap

[Zhengqiang]

On 2017/10/31 23:38, James Morse wrote:
> GHES is doing ioremap_page_range() in both NMI and irq context, neither
> are safe as it may sleep to allocate intermediate levels of page table.
> 
> Replace the NMI/irq GHES_IOREMAP_PAGES to use a fixmap entry each.
> 
> After this nothing uses ghes_ioremap_area or arch_apei_flush_tlb_one(),
> rip them out.
> 
> RFC as I've only build-tested this on x86. For arm64 I've tested it on a
> software model. Any more testing would be welcome. These patches are based
> on rc7.
> 


Tested-by:  Qiang Zheng <zhengqiang10@huawei.com>

Verified on our arm64, it work for me. Thanks.

Qiang

Re: [RFC/RFT PATCH 0/6] Switch GHES ioremap_page_range() to use fixmap

[Zhengqiang]

On 2017/10/31 23:38, James Morse wrote:
> GHES is doing ioremap_page_range() in both NMI and irq context, neither
> are safe as it may sleep to allocate intermediate levels of page table.
> 
> Replace the NMI/irq GHES_IOREMAP_PAGES to use a fixmap entry each.
> 
> After this nothing uses ghes_ioremap_area or arch_apei_flush_tlb_one(),
> rip them out.
> 
> RFC as I've only build-tested this on x86. For arm64 I've tested it on a
> software model. Any more testing would be welcome. These patches are based
> on rc7.
> 


Tested-by:  Qiang Zheng <zhengqiang10@huawei.com>

Verified on our arm64, it work for me. Thanks.

Qiang