* [PATCH] x86: Make 64-bit efi_ioremap use ioremap on MMIO regions
@ 2009-08-03 12:38 Paul Mackerras
2009-08-03 17:12 ` [tip:x86/urgent] " tip-bot for Paul Mackerras
2009-08-03 21:47 ` tip-bot for Paul Mackerras
0 siblings, 2 replies; 6+ messages in thread
From: Paul Mackerras @ 2009-08-03 12:38 UTC (permalink / raw)
To: Ingo Molnar, H. Peter Anvin, Thomas Gleixner; +Cc: linux-kernel
Booting current 64-bit x86 kernels on the latest Apple MacBook
(MacBook5,2) via EFI gives the following warning:
[ 0.182209] ------------[ cut here ]------------
[ 0.182222] WARNING: at arch/x86/mm/pageattr.c:581 __cpa_process_fault+0x44/0xa0()
[ 0.182227] Hardware name: MacBook5,2
[ 0.182231] CPA: called for zero pte. vaddr = ffff8800ffe00000 cpa->vaddr = ffff8800ffe00000
[ 0.182236] Modules linked in:
[ 0.182242] Pid: 0, comm: swapper Not tainted 2.6.31-rc4 #6
[ 0.182246] Call Trace:
[ 0.182254] [<ffffffff8102c754>] ? __cpa_process_fault+0x44/0xa0
[ 0.182261] [<ffffffff81048668>] warn_slowpath_common+0x78/0xd0
[ 0.182266] [<ffffffff81048744>] warn_slowpath_fmt+0x64/0x70
[ 0.182272] [<ffffffff8102c7ec>] ? update_page_count+0x3c/0x50
[ 0.182280] [<ffffffff818d25c5>] ? phys_pmd_init+0x140/0x22e
[ 0.182286] [<ffffffff8102c754>] __cpa_process_fault+0x44/0xa0
[ 0.182292] [<ffffffff8102ce60>] __change_page_attr_set_clr+0x5f0/0xb40
[ 0.182301] [<ffffffff810d1035>] ? vm_unmap_aliases+0x175/0x190
[ 0.182307] [<ffffffff8102d4ae>] change_page_attr_set_clr+0xfe/0x3d0
[ 0.182314] [<ffffffff8102dcca>] _set_memory_uc+0x2a/0x30
[ 0.182319] [<ffffffff8102dd4b>] set_memory_uc+0x7b/0xb0
[ 0.182327] [<ffffffff818afe31>] efi_enter_virtual_mode+0x2ad/0x2c9
[ 0.182334] [<ffffffff818a1c66>] start_kernel+0x2db/0x3f4
[ 0.182340] [<ffffffff818a1289>] x86_64_start_reservations+0x99/0xb9
[ 0.182345] [<ffffffff818a1389>] x86_64_start_kernel+0xe0/0xf2
[ 0.182357] ---[ end trace 4eaa2a86a8e2da22 ]---
[ 0.182982] init_memory_mapping: 00000000ffffc000-0000000100000000
[ 0.182993] 00ffffc000 - 0100000000 page 4k
This happens because the 64-bit version of efi_ioremap calls
init_memory_mapping for all addresses, regardless of whether they are
RAM or MMIO. The EFI tables on this machine ask for runtime access to
some MMIO regions:
[ 0.000000] EFI: mem195: type=11, attr=0x8000000000000000, range=[0x0000000093400000-0x0000000093401000) (0MB)
[ 0.000000] EFI: mem196: type=11, attr=0x8000000000000000, range=[0x00000000ffc00000-0x00000000ffc40000) (0MB)
[ 0.000000] EFI: mem197: type=11, attr=0x8000000000000000, range=[0x00000000ffc40000-0x00000000ffc80000) (0MB)
[ 0.000000] EFI: mem198: type=11, attr=0x8000000000000000, range=[0x00000000ffc80000-0x00000000ffca4000) (0MB)
[ 0.000000] EFI: mem199: type=11, attr=0x8000000000000000, range=[0x00000000ffca4000-0x00000000ffcb4000) (0MB)
[ 0.000000] EFI: mem200: type=11, attr=0x8000000000000000, range=[0x00000000ffcb4000-0x00000000ffffc000) (3MB)
[ 0.000000] EFI: mem201: type=11, attr=0x8000000000000000, range=[0x00000000ffffc000-0x0000000100000000) (0MB)
This arranges to pass the EFI memory type through to efi_ioremap, and
makes efi_ioremap use ioremap rather than init_memory_mapping if the
type is EFI_MEMORY_MAPPED_IO. With this, the above warning goes away.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index edc90f2..8406ed7 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -33,7 +33,7 @@ extern unsigned long asmlinkage efi_call_phys(void *, ...);
#define efi_call_virt6(f, a1, a2, a3, a4, a5, a6) \
efi_call_virt(f, a1, a2, a3, a4, a5, a6)
-#define efi_ioremap(addr, size) ioremap_cache(addr, size)
+#define efi_ioremap(addr, size, type) ioremap_cache(addr, size)
#else /* !CONFIG_X86_32 */
@@ -84,7 +84,8 @@ extern u64 efi_call6(void *fp, u64 arg1, u64 arg2, u64 arg3,
efi_call6((void *)(efi.systab->runtime->f), (u64)(a1), (u64)(a2), \
(u64)(a3), (u64)(a4), (u64)(a5), (u64)(a6))
-extern void __iomem *efi_ioremap(unsigned long addr, unsigned long size);
+extern void __iomem *efi_ioremap(unsigned long addr, unsigned long size,
+ u32 type);
#endif /* CONFIG_X86_32 */
diff --git a/arch/x86/kernel/efi.c b/arch/x86/kernel/efi.c
index 96f7ac0..19ccf6d 100644
--- a/arch/x86/kernel/efi.c
+++ b/arch/x86/kernel/efi.c
@@ -512,7 +512,7 @@ void __init efi_enter_virtual_mode(void)
&& end_pfn <= max_pfn_mapped))
va = __va(md->phys_addr);
else
- va = efi_ioremap(md->phys_addr, size);
+ va = efi_ioremap(md->phys_addr, size, md->type);
md->virt_addr = (u64) (unsigned long) va;
diff --git a/arch/x86/kernel/efi_64.c b/arch/x86/kernel/efi_64.c
index 22c3b78..ac0621a 100644
--- a/arch/x86/kernel/efi_64.c
+++ b/arch/x86/kernel/efi_64.c
@@ -98,10 +98,14 @@ void __init efi_call_phys_epilog(void)
early_runtime_code_mapping_set_exec(0);
}
-void __iomem *__init efi_ioremap(unsigned long phys_addr, unsigned long size)
+void __iomem *__init efi_ioremap(unsigned long phys_addr, unsigned long size,
+ u32 type)
{
unsigned long last_map_pfn;
+ if (type == EFI_MEMORY_MAPPED_IO)
+ return ioremap(phys_addr, size);
+
last_map_pfn = init_memory_mapping(phys_addr, phys_addr + size);
if ((last_map_pfn << PAGE_SHIFT) < phys_addr + size)
return NULL;
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [tip:x86/urgent] x86: Make 64-bit efi_ioremap use ioremap on MMIO regions
2009-08-03 12:38 [PATCH] x86: Make 64-bit efi_ioremap use ioremap on MMIO regions Paul Mackerras
@ 2009-08-03 17:12 ` tip-bot for Paul Mackerras
2009-08-04 1:20 ` Huang Ying
2009-08-03 21:47 ` tip-bot for Paul Mackerras
1 sibling, 1 reply; 6+ messages in thread
From: tip-bot for Paul Mackerras @ 2009-08-03 17:12 UTC (permalink / raw)
To: linux-tip-commits; +Cc: ying.huang, linux-kernel, paulus, hpa, mingo, tglx
Commit-ID: 19157af82cf0575032386f60378527904dbb7b8f
Gitweb: http://git.kernel.org/tip/19157af82cf0575032386f60378527904dbb7b8f
Author: Paul Mackerras <paulus@samba.org>
AuthorDate: Mon, 3 Aug 2009 22:38:10 +1000
Committer: H. Peter Anvin <hpa@zytor.com>
CommitDate: Mon, 3 Aug 2009 08:09:59 -0700
x86: Make 64-bit efi_ioremap use ioremap on MMIO regions
Booting current 64-bit x86 kernels on the latest Apple MacBook
(MacBook5,2) via EFI gives the following warning:
[ 0.182209] ------------[ cut here ]------------
[ 0.182222] WARNING: at arch/x86/mm/pageattr.c:581 __cpa_process_fault+0x44/0xa0()
[ 0.182227] Hardware name: MacBook5,2
[ 0.182231] CPA: called for zero pte. vaddr = ffff8800ffe00000 cpa->vaddr = ffff8800ffe00000
[ 0.182236] Modules linked in:
[ 0.182242] Pid: 0, comm: swapper Not tainted 2.6.31-rc4 #6
[ 0.182246] Call Trace:
[ 0.182254] [<ffffffff8102c754>] ? __cpa_process_fault+0x44/0xa0
[ 0.182261] [<ffffffff81048668>] warn_slowpath_common+0x78/0xd0
[ 0.182266] [<ffffffff81048744>] warn_slowpath_fmt+0x64/0x70
[ 0.182272] [<ffffffff8102c7ec>] ? update_page_count+0x3c/0x50
[ 0.182280] [<ffffffff818d25c5>] ? phys_pmd_init+0x140/0x22e
[ 0.182286] [<ffffffff8102c754>] __cpa_process_fault+0x44/0xa0
[ 0.182292] [<ffffffff8102ce60>] __change_page_attr_set_clr+0x5f0/0xb40
[ 0.182301] [<ffffffff810d1035>] ? vm_unmap_aliases+0x175/0x190
[ 0.182307] [<ffffffff8102d4ae>] change_page_attr_set_clr+0xfe/0x3d0
[ 0.182314] [<ffffffff8102dcca>] _set_memory_uc+0x2a/0x30
[ 0.182319] [<ffffffff8102dd4b>] set_memory_uc+0x7b/0xb0
[ 0.182327] [<ffffffff818afe31>] efi_enter_virtual_mode+0x2ad/0x2c9
[ 0.182334] [<ffffffff818a1c66>] start_kernel+0x2db/0x3f4
[ 0.182340] [<ffffffff818a1289>] x86_64_start_reservations+0x99/0xb9
[ 0.182345] [<ffffffff818a1389>] x86_64_start_kernel+0xe0/0xf2
[ 0.182357] ---[ end trace 4eaa2a86a8e2da22 ]---
[ 0.182982] init_memory_mapping: 00000000ffffc000-0000000100000000
[ 0.182993] 00ffffc000 - 0100000000 page 4k
This happens because the 64-bit version of efi_ioremap calls
init_memory_mapping for all addresses, regardless of whether they are
RAM or MMIO. The EFI tables on this machine ask for runtime access to
some MMIO regions:
[ 0.000000] EFI: mem195: type=11, attr=0x8000000000000000, range=[0x0000000093400000-0x0000000093401000) (0MB)
[ 0.000000] EFI: mem196: type=11, attr=0x8000000000000000, range=[0x00000000ffc00000-0x00000000ffc40000) (0MB)
[ 0.000000] EFI: mem197: type=11, attr=0x8000000000000000, range=[0x00000000ffc40000-0x00000000ffc80000) (0MB)
[ 0.000000] EFI: mem198: type=11, attr=0x8000000000000000, range=[0x00000000ffc80000-0x00000000ffca4000) (0MB)
[ 0.000000] EFI: mem199: type=11, attr=0x8000000000000000, range=[0x00000000ffca4000-0x00000000ffcb4000) (0MB)
[ 0.000000] EFI: mem200: type=11, attr=0x8000000000000000, range=[0x00000000ffcb4000-0x00000000ffffc000) (3MB)
[ 0.000000] EFI: mem201: type=11, attr=0x8000000000000000, range=[0x00000000ffffc000-0x0000000100000000) (0MB)
This arranges to pass the EFI memory type through to efi_ioremap, and
makes efi_ioremap use ioremap rather than init_memory_mapping if the
type is EFI_MEMORY_MAPPED_IO. With this, the above warning goes away.
Signed-off-by: Paul Mackerras <paulus@samba.org>
LKML-Reference: <19062.55858.533494.471153@cargo.ozlabs.ibm.com>
Cc: Huang Ying <ying.huang@intel.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
---
arch/x86/include/asm/efi.h | 5 +++--
arch/x86/kernel/efi.c | 2 +-
arch/x86/kernel/efi_64.c | 6 +++++-
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index edc90f2..8406ed7 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -33,7 +33,7 @@ extern unsigned long asmlinkage efi_call_phys(void *, ...);
#define efi_call_virt6(f, a1, a2, a3, a4, a5, a6) \
efi_call_virt(f, a1, a2, a3, a4, a5, a6)
-#define efi_ioremap(addr, size) ioremap_cache(addr, size)
+#define efi_ioremap(addr, size, type) ioremap_cache(addr, size)
#else /* !CONFIG_X86_32 */
@@ -84,7 +84,8 @@ extern u64 efi_call6(void *fp, u64 arg1, u64 arg2, u64 arg3,
efi_call6((void *)(efi.systab->runtime->f), (u64)(a1), (u64)(a2), \
(u64)(a3), (u64)(a4), (u64)(a5), (u64)(a6))
-extern void __iomem *efi_ioremap(unsigned long addr, unsigned long size);
+extern void __iomem *efi_ioremap(unsigned long addr, unsigned long size,
+ u32 type);
#endif /* CONFIG_X86_32 */
diff --git a/arch/x86/kernel/efi.c b/arch/x86/kernel/efi.c
index 96f7ac0..19ccf6d 100644
--- a/arch/x86/kernel/efi.c
+++ b/arch/x86/kernel/efi.c
@@ -512,7 +512,7 @@ void __init efi_enter_virtual_mode(void)
&& end_pfn <= max_pfn_mapped))
va = __va(md->phys_addr);
else
- va = efi_ioremap(md->phys_addr, size);
+ va = efi_ioremap(md->phys_addr, size, md->type);
md->virt_addr = (u64) (unsigned long) va;
diff --git a/arch/x86/kernel/efi_64.c b/arch/x86/kernel/efi_64.c
index 22c3b78..ac0621a 100644
--- a/arch/x86/kernel/efi_64.c
+++ b/arch/x86/kernel/efi_64.c
@@ -98,10 +98,14 @@ void __init efi_call_phys_epilog(void)
early_runtime_code_mapping_set_exec(0);
}
-void __iomem *__init efi_ioremap(unsigned long phys_addr, unsigned long size)
+void __iomem *__init efi_ioremap(unsigned long phys_addr, unsigned long size,
+ u32 type)
{
unsigned long last_map_pfn;
+ if (type == EFI_MEMORY_MAPPED_IO)
+ return ioremap(phys_addr, size);
+
last_map_pfn = init_memory_mapping(phys_addr, phys_addr + size);
if ((last_map_pfn << PAGE_SHIFT) < phys_addr + size)
return NULL;
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [tip:x86/urgent] x86: Make 64-bit efi_ioremap use ioremap on MMIO regions
2009-08-03 12:38 [PATCH] x86: Make 64-bit efi_ioremap use ioremap on MMIO regions Paul Mackerras
2009-08-03 17:12 ` [tip:x86/urgent] " tip-bot for Paul Mackerras
@ 2009-08-03 21:47 ` tip-bot for Paul Mackerras
1 sibling, 0 replies; 6+ messages in thread
From: tip-bot for Paul Mackerras @ 2009-08-03 21:47 UTC (permalink / raw)
To: linux-tip-commits; +Cc: ying.huang, linux-kernel, paulus, hpa, mingo, tglx
Commit-ID: 6a7bbd57ed50bb62c9a81ae5f2e202ca689e5964
Gitweb: http://git.kernel.org/tip/6a7bbd57ed50bb62c9a81ae5f2e202ca689e5964
Author: Paul Mackerras <paulus@samba.org>
AuthorDate: Mon, 3 Aug 2009 22:38:10 +1000
Committer: H. Peter Anvin <hpa@zytor.com>
CommitDate: Mon, 3 Aug 2009 13:34:25 -0700
x86: Make 64-bit efi_ioremap use ioremap on MMIO regions
Booting current 64-bit x86 kernels on the latest Apple MacBook
(MacBook5,2) via EFI gives the following warning:
[ 0.182209] ------------[ cut here ]------------
[ 0.182222] WARNING: at arch/x86/mm/pageattr.c:581 __cpa_process_fault+0x44/0xa0()
[ 0.182227] Hardware name: MacBook5,2
[ 0.182231] CPA: called for zero pte. vaddr = ffff8800ffe00000 cpa->vaddr = ffff8800ffe00000
[ 0.182236] Modules linked in:
[ 0.182242] Pid: 0, comm: swapper Not tainted 2.6.31-rc4 #6
[ 0.182246] Call Trace:
[ 0.182254] [<ffffffff8102c754>] ? __cpa_process_fault+0x44/0xa0
[ 0.182261] [<ffffffff81048668>] warn_slowpath_common+0x78/0xd0
[ 0.182266] [<ffffffff81048744>] warn_slowpath_fmt+0x64/0x70
[ 0.182272] [<ffffffff8102c7ec>] ? update_page_count+0x3c/0x50
[ 0.182280] [<ffffffff818d25c5>] ? phys_pmd_init+0x140/0x22e
[ 0.182286] [<ffffffff8102c754>] __cpa_process_fault+0x44/0xa0
[ 0.182292] [<ffffffff8102ce60>] __change_page_attr_set_clr+0x5f0/0xb40
[ 0.182301] [<ffffffff810d1035>] ? vm_unmap_aliases+0x175/0x190
[ 0.182307] [<ffffffff8102d4ae>] change_page_attr_set_clr+0xfe/0x3d0
[ 0.182314] [<ffffffff8102dcca>] _set_memory_uc+0x2a/0x30
[ 0.182319] [<ffffffff8102dd4b>] set_memory_uc+0x7b/0xb0
[ 0.182327] [<ffffffff818afe31>] efi_enter_virtual_mode+0x2ad/0x2c9
[ 0.182334] [<ffffffff818a1c66>] start_kernel+0x2db/0x3f4
[ 0.182340] [<ffffffff818a1289>] x86_64_start_reservations+0x99/0xb9
[ 0.182345] [<ffffffff818a1389>] x86_64_start_kernel+0xe0/0xf2
[ 0.182357] ---[ end trace 4eaa2a86a8e2da22 ]---
[ 0.182982] init_memory_mapping: 00000000ffffc000-0000000100000000
[ 0.182993] 00ffffc000 - 0100000000 page 4k
This happens because the 64-bit version of efi_ioremap calls
init_memory_mapping for all addresses, regardless of whether they are
RAM or MMIO. The EFI tables on this machine ask for runtime access to
some MMIO regions:
[ 0.000000] EFI: mem195: type=11, attr=0x8000000000000000, range=[0x0000000093400000-0x0000000093401000) (0MB)
[ 0.000000] EFI: mem196: type=11, attr=0x8000000000000000, range=[0x00000000ffc00000-0x00000000ffc40000) (0MB)
[ 0.000000] EFI: mem197: type=11, attr=0x8000000000000000, range=[0x00000000ffc40000-0x00000000ffc80000) (0MB)
[ 0.000000] EFI: mem198: type=11, attr=0x8000000000000000, range=[0x00000000ffc80000-0x00000000ffca4000) (0MB)
[ 0.000000] EFI: mem199: type=11, attr=0x8000000000000000, range=[0x00000000ffca4000-0x00000000ffcb4000) (0MB)
[ 0.000000] EFI: mem200: type=11, attr=0x8000000000000000, range=[0x00000000ffcb4000-0x00000000ffffc000) (3MB)
[ 0.000000] EFI: mem201: type=11, attr=0x8000000000000000, range=[0x00000000ffffc000-0x0000000100000000) (0MB)
This arranges to pass the EFI memory type through to efi_ioremap, and
makes efi_ioremap use ioremap rather than init_memory_mapping if the
type is EFI_MEMORY_MAPPED_IO. With this, the above warning goes away.
Signed-off-by: Paul Mackerras <paulus@samba.org>
LKML-Reference: <19062.55858.533494.471153@cargo.ozlabs.ibm.com>
Cc: Huang Ying <ying.huang@intel.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
---
arch/x86/include/asm/efi.h | 5 +++--
arch/x86/kernel/efi.c | 2 +-
arch/x86/kernel/efi_64.c | 6 +++++-
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index edc90f2..8406ed7 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -33,7 +33,7 @@ extern unsigned long asmlinkage efi_call_phys(void *, ...);
#define efi_call_virt6(f, a1, a2, a3, a4, a5, a6) \
efi_call_virt(f, a1, a2, a3, a4, a5, a6)
-#define efi_ioremap(addr, size) ioremap_cache(addr, size)
+#define efi_ioremap(addr, size, type) ioremap_cache(addr, size)
#else /* !CONFIG_X86_32 */
@@ -84,7 +84,8 @@ extern u64 efi_call6(void *fp, u64 arg1, u64 arg2, u64 arg3,
efi_call6((void *)(efi.systab->runtime->f), (u64)(a1), (u64)(a2), \
(u64)(a3), (u64)(a4), (u64)(a5), (u64)(a6))
-extern void __iomem *efi_ioremap(unsigned long addr, unsigned long size);
+extern void __iomem *efi_ioremap(unsigned long addr, unsigned long size,
+ u32 type);
#endif /* CONFIG_X86_32 */
diff --git a/arch/x86/kernel/efi.c b/arch/x86/kernel/efi.c
index 96f7ac0..19ccf6d 100644
--- a/arch/x86/kernel/efi.c
+++ b/arch/x86/kernel/efi.c
@@ -512,7 +512,7 @@ void __init efi_enter_virtual_mode(void)
&& end_pfn <= max_pfn_mapped))
va = __va(md->phys_addr);
else
- va = efi_ioremap(md->phys_addr, size);
+ va = efi_ioremap(md->phys_addr, size, md->type);
md->virt_addr = (u64) (unsigned long) va;
diff --git a/arch/x86/kernel/efi_64.c b/arch/x86/kernel/efi_64.c
index 22c3b78..ac0621a 100644
--- a/arch/x86/kernel/efi_64.c
+++ b/arch/x86/kernel/efi_64.c
@@ -98,10 +98,14 @@ void __init efi_call_phys_epilog(void)
early_runtime_code_mapping_set_exec(0);
}
-void __iomem *__init efi_ioremap(unsigned long phys_addr, unsigned long size)
+void __iomem *__init efi_ioremap(unsigned long phys_addr, unsigned long size,
+ u32 type)
{
unsigned long last_map_pfn;
+ if (type == EFI_MEMORY_MAPPED_IO)
+ return ioremap(phys_addr, size);
+
last_map_pfn = init_memory_mapping(phys_addr, phys_addr + size);
if ((last_map_pfn << PAGE_SHIFT) < phys_addr + size)
return NULL;
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [tip:x86/urgent] x86: Make 64-bit efi_ioremap use ioremap on MMIO regions
2009-08-03 17:12 ` [tip:x86/urgent] " tip-bot for Paul Mackerras
@ 2009-08-04 1:20 ` Huang Ying
2009-08-04 1:51 ` Paul Mackerras
0 siblings, 1 reply; 6+ messages in thread
From: Huang Ying @ 2009-08-04 1:20 UTC (permalink / raw)
To: mingo, hpa, paulus, linux-kernel, tglx; +Cc: linux-tip-commits
On Tue, 2009-08-04 at 01:12 +0800, tip-bot for Paul Mackerras wrote:
> Commit-ID: 19157af82cf0575032386f60378527904dbb7b8f
> Gitweb: http://git.kernel.org/tip/19157af82cf0575032386f60378527904dbb7b8f
> Author: Paul Mackerras <paulus@samba.org>
> AuthorDate: Mon, 3 Aug 2009 22:38:10 +1000
> Committer: H. Peter Anvin <hpa@zytor.com>
> CommitDate: Mon, 3 Aug 2009 08:09:59 -0700
>
> x86: Make 64-bit efi_ioremap use ioremap on MMIO regions
>
> Booting current 64-bit x86 kernels on the latest Apple MacBook
> (MacBook5,2) via EFI gives the following warning:
>
> [ 0.182209] ------------[ cut here ]------------
> [ 0.182222] WARNING: at arch/x86/mm/pageattr.c:581 __cpa_process_fault+0x44/0xa0()
This patch does not really fix the issue. __cpa_process_fault will warn
if target memory area is beyond max_pfn_mapped. EFI runtime RAM area
beyond max_pfn_mapped will trigger the warning too.
To fix the issue. I think we can loose the restriction of
__cpa_process_fault a little. Add a global variable max_pfn, which is
max pfn of all memory type (including RAM, RESERVED, etc, mapped or
unmapped), and __cpa_process_fault warns for memory area beyond max_pfn
only.
Best Regards,
Huang Ying
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [tip:x86/urgent] x86: Make 64-bit efi_ioremap use ioremap on MMIO regions
2009-08-04 1:20 ` Huang Ying
@ 2009-08-04 1:51 ` Paul Mackerras
2009-08-04 2:04 ` Huang Ying
0 siblings, 1 reply; 6+ messages in thread
From: Paul Mackerras @ 2009-08-04 1:51 UTC (permalink / raw)
To: Huang Ying; +Cc: mingo, hpa, linux-kernel, tglx, linux-tip-commits
Huang Ying writes:
> This patch does not really fix the issue. __cpa_process_fault will warn
> if target memory area is beyond max_pfn_mapped. EFI runtime RAM area
> beyond max_pfn_mapped will trigger the warning too.
I think we already have that situation on that MacBook, and there is
no warning. From dmesg:
[ 0.000000] EFI: mem190: type=9, attr=0xf, range=[0x000000007fedf000-0x000000007feef000) (0MB)
[ 0.000000] EFI: mem191: type=7, attr=0xf, range=[0x000000007feef000-0x000000007fef9000) (0MB)
[ 0.000000] EFI: mem192: type=0, attr=0xf, range=[0x000000007fef9000-0x000000007feff000) (0MB)
[ 0.000000] EFI: mem193: type=6, attr=0x800000000000000f, range=[0x000000007feff000-0x000000007ff00000) (0MB)
...
[ 0.000000] last_pfn = 0x7fef9 max_arch_pfn = 0x400000000
...
[ 0.000000] initial memory mapped : 0 - 20000000
[ 0.000000] init_memory_mapping: 0000000000000000-000000007fef9000
[ 0.000000] 0000000000 - 007fe00000 page 2M
[ 0.000000] 007fe00000 - 007fef9000 page 4k
[ 0.000000] kernel direct mapping tables up to 7fef9000 @ 8000-c000
...
[ 0.001920] init_memory_mapping: 000000007feff000-000000007ff00000
[ 0.001926] 007feff000 - 007ff00000 page 4k
So the initial mapping ends at 0x7fef9000, and I believe that
max_pfn_mapped is 0x7fef9, and then EFI asks for pfn 0x7feff to be
mapped. But I freely admit this is not my area of expertise. This
machine has 2GB of RAM, by the way.
> To fix the issue. I think we can loose the restriction of
> __cpa_process_fault a little. Add a global variable max_pfn, which is
> max pfn of all memory type (including RAM, RESERVED, etc, mapped or
> unmapped), and __cpa_process_fault warns for memory area beyond max_pfn
> only.
It seemed cleaner to me to use ioremap() on areas that we are told are
MMIO. Why would it be better to use init_memory_mapping for those
areas?
Paul.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [tip:x86/urgent] x86: Make 64-bit efi_ioremap use ioremap on MMIO regions
2009-08-04 1:51 ` Paul Mackerras
@ 2009-08-04 2:04 ` Huang Ying
0 siblings, 0 replies; 6+ messages in thread
From: Huang Ying @ 2009-08-04 2:04 UTC (permalink / raw)
To: Paul Mackerras; +Cc: mingo, hpa, linux-kernel, tglx, linux-tip-commits
On Tue, 2009-08-04 at 09:51 +0800, Paul Mackerras wrote:
> Huang Ying writes:
>
> > This patch does not really fix the issue. __cpa_process_fault will warn
> > if target memory area is beyond max_pfn_mapped. EFI runtime RAM area
> > beyond max_pfn_mapped will trigger the warning too.
>
> I think we already have that situation on that MacBook, and there is
> no warning. From dmesg:
>
> [ 0.000000] EFI: mem190: type=9, attr=0xf, range=[0x000000007fedf000-0x000000007feef000) (0MB)
> [ 0.000000] EFI: mem191: type=7, attr=0xf, range=[0x000000007feef000-0x000000007fef9000) (0MB)
> [ 0.000000] EFI: mem192: type=0, attr=0xf, range=[0x000000007fef9000-0x000000007feff000) (0MB)
> [ 0.000000] EFI: mem193: type=6, attr=0x800000000000000f, range=[0x000000007feff000-0x000000007ff00000) (0MB)
> ...
> [ 0.000000] last_pfn = 0x7fef9 max_arch_pfn = 0x400000000
> ...
> [ 0.000000] initial memory mapped : 0 - 20000000
> [ 0.000000] init_memory_mapping: 0000000000000000-000000007fef9000
> [ 0.000000] 0000000000 - 007fe00000 page 2M
> [ 0.000000] 007fe00000 - 007fef9000 page 4k
> [ 0.000000] kernel direct mapping tables up to 7fef9000 @ 8000-c000
> ...
> [ 0.001920] init_memory_mapping: 000000007feff000-000000007ff00000
> [ 0.001926] 007feff000 - 007ff00000 page 4k
>
> So the initial mapping ends at 0x7fef9000, and I believe that
> max_pfn_mapped is 0x7fef9, and then EFI asks for pfn 0x7feff to be
> mapped. But I freely admit this is not my area of expertise. This
> machine has 2GB of RAM, by the way.
If you specify "mem=<xxx>m" to a small value in kernel command line, I
think the kernel warning will appear again. Because some EFI runtime
memory area may be beyond max_pfn_mapped.
> > To fix the issue. I think we can loose the restriction of
> > __cpa_process_fault a little. Add a global variable max_pfn, which is
> > max pfn of all memory type (including RAM, RESERVED, etc, mapped or
> > unmapped), and __cpa_process_fault warns for memory area beyond max_pfn
> > only.
>
> It seemed cleaner to me to use ioremap() on areas that we are told are
> MMIO. Why would it be better to use init_memory_mapping for those
> areas?
I prefer init_memory_mapping because it is more compatible with KEXEC
support (not done yet). Because EFI runtime memory area should be mapped
in exactly same position in original and kexeced kernel.
Best Regards,
Huang Ying
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-08-04 2:04 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-08-03 12:38 [PATCH] x86: Make 64-bit efi_ioremap use ioremap on MMIO regions Paul Mackerras
2009-08-03 17:12 ` [tip:x86/urgent] " tip-bot for Paul Mackerras
2009-08-04 1:20 ` Huang Ying
2009-08-04 1:51 ` Paul Mackerras
2009-08-04 2:04 ` Huang Ying
2009-08-03 21:47 ` tip-bot for Paul Mackerras
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.