* [PATCH v3 2/2] ARM : change fixmap mapping region to support 32 CPUs
@ 2014-04-15 11:06 ` Liu Hua
0 siblings, 0 replies; 38+ messages in thread
From: Liu Hua @ 2014-04-15 11:06 UTC (permalink / raw)
To: nicolas.pitre, linux
Cc: will.deacon, vitalya, cyril, santosh.shilimkar, lauraa,
linux-arm-kernel, linux-kernel, wangnan0, peifeiyue, liusdu,
Liu Hua
In 32-bit ARM systems, the fixmap mapping region can support
no more than 14 CPUs(total: 896k; one CPU: 64K). And we can
configure NR_CPUS up to 32. So there is a mismatch.
This patch moves fixmapping region downwards to region
0xffc00000-0xffe00000. Then the fixmap mapping region can
support up to 32 CPUs
Signed-off-by: Liu Hua <sdu.liu@huawei.com>
---
Documentation/arm/memory.txt | 2 +-
arch/arm/include/asm/fixmap.h | 16 ++--------------
arch/arm/include/asm/highmem.h | 1 +
arch/arm/mm/highmem.c | 27 +++++++++++++++++++++------
arch/arm/mm/mmu.c | 4 ++++
5 files changed, 29 insertions(+), 21 deletions(-)
diff --git a/Documentation/arm/memory.txt b/Documentation/arm/memory.txt
index 4bfb9ff..a9fc59b 100644
--- a/Documentation/arm/memory.txt
+++ b/Documentation/arm/memory.txt
@@ -41,7 +41,7 @@ fffe8000 fffeffff DTCM mapping area for platforms with
fffe0000 fffe7fff ITCM mapping area for platforms with
ITCM mounted inside the CPU.
-fff00000 fffdffff Fixmap mapping region. Addresses provided
+fffc0000 ffdfffff Fixmap mapping region. Addresses provided
by fix_to_virt() will be located here.
ffc00000 ffefffff DMA memory mapping region. Memory returned
diff --git a/arch/arm/include/asm/fixmap.h b/arch/arm/include/asm/fixmap.h
index be55ebc..74124b0 100644
--- a/arch/arm/include/asm/fixmap.h
+++ b/arch/arm/include/asm/fixmap.h
@@ -1,20 +1,8 @@
#ifndef _ASM_FIXMAP_H
#define _ASM_FIXMAP_H
-/*
- * Nothing too fancy for now.
- *
- * On ARM we already have well known fixed virtual addresses imposed by
- * the architecture such as the vector page which is located at 0xffff0000,
- * therefore a second level page table is already allocated covering
- * 0xfff00000 upwards.
- *
- * The cache flushing code in proc-xscale.S uses the virtual area between
- * 0xfffe0000 and 0xfffeffff.
- */
-
-#define FIXADDR_START 0xfff00000UL
-#define FIXADDR_TOP 0xfffe0000UL
+#define FIXADDR_START 0xffc00000UL
+#define FIXADDR_TOP 0xffe00000UL
#define FIXADDR_SIZE (FIXADDR_TOP - FIXADDR_START)
#define FIX_KMAP_NR_PTES (FIXADDR_SIZE >> PAGE_SHIFT)
diff --git a/arch/arm/include/asm/highmem.h b/arch/arm/include/asm/highmem.h
index 91b99ab..5355795 100644
--- a/arch/arm/include/asm/highmem.h
+++ b/arch/arm/include/asm/highmem.h
@@ -18,6 +18,7 @@
} while (0)
extern pte_t *pkmap_page_table;
+extern pte_t *fixmap_page_table;
extern void *kmap_high(struct page *page);
extern void kunmap_high(struct page *page);
diff --git a/arch/arm/mm/highmem.c b/arch/arm/mm/highmem.c
index e05e8ad..45aeaac 100644
--- a/arch/arm/mm/highmem.c
+++ b/arch/arm/mm/highmem.c
@@ -18,6 +18,21 @@
#include <asm/tlbflush.h>
#include "mm.h"
+pte_t *fixmap_page_table;
+
+static inline void set_fixmap_pte(int idx, pte_t pte)
+{
+ unsigned long vaddr = __fix_to_virt(idx);
+ set_pte_ext(fixmap_page_table + idx, pte, 0);
+ local_flush_tlb_kernel_page(vaddr);
+}
+
+static inline pte_t get_fixmap_pte(unsigned long vaddr)
+{
+ unsigned long idx = __virt_to_fix(vaddr);
+ return *(fixmap_page_table + idx);
+}
+
void *kmap(struct page *page)
{
might_sleep();
@@ -69,14 +84,14 @@ void *kmap_atomic(struct page *page)
* With debugging enabled, kunmap_atomic forces that entry to 0.
* Make sure it was indeed properly unmapped.
*/
- BUG_ON(!pte_none(get_top_pte(vaddr)));
+ BUG_ON(!pte_none(*(fixmap_page_table + idx)));
#endif
/*
* When debugging is off, kunmap_atomic leaves the previous mapping
* in place, so the contained TLB flush ensures the TLB is updated
* with the new mapping.
*/
- set_top_pte(vaddr, mk_pte(page, kmap_prot));
+ set_fixmap_pte(idx, mk_pte(page, kmap_prot));
return (void *)vaddr;
}
@@ -95,7 +110,7 @@ void __kunmap_atomic(void *kvaddr)
__cpuc_flush_dcache_area((void *)vaddr, PAGE_SIZE);
#ifdef CONFIG_DEBUG_HIGHMEM
BUG_ON(vaddr != __fix_to_virt(idx));
- set_top_pte(vaddr, __pte(0));
+ set_fixmap_pte(idx, __pte(0));
#else
(void) idx; /* to kill a warning */
#endif
@@ -119,9 +134,9 @@ void *kmap_atomic_pfn(unsigned long pfn)
idx = type + KM_TYPE_NR * smp_processor_id();
vaddr = __fix_to_virt(idx);
#ifdef CONFIG_DEBUG_HIGHMEM
- BUG_ON(!pte_none(get_top_pte(vaddr)));
+ BUG_ON(!pte_none(*(fixmap_page_table + idx)));
#endif
- set_top_pte(vaddr, pfn_pte(pfn, kmap_prot));
+ set_fixmap_pte(idx, pfn_pte(pfn, kmap_prot));
return (void *)vaddr;
}
@@ -133,5 +148,5 @@ struct page *kmap_atomic_to_page(const void *ptr)
if (vaddr < FIXADDR_START)
return virt_to_page(ptr);
- return pte_page(get_top_pte(vaddr));
+ return pte_page(get_fixmap_pte(vaddr));
}
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index b68c6b2..09c0a16 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -35,6 +35,7 @@
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
#include <asm/mach/pci.h>
+#include <asm/fixmap.h>
#include "mm.h"
#include "tcm.h"
@@ -1359,6 +1360,9 @@ static void __init kmap_init(void)
#ifdef CONFIG_HIGHMEM
pkmap_page_table = early_pte_alloc(pmd_off_k(PKMAP_BASE),
PKMAP_BASE, _PAGE_KERNEL_TABLE);
+
+ fixmap_page_table = early_pte_alloc(pmd_off_k(FIXADDR_START),
+ FIXADDR_START, _PAGE_KERNEL_TABLE);
#endif
}
--
1.9.0
^ permalink raw reply related [flat|nested] 38+ messages in thread* [PATCH v3 2/2] ARM : change fixmap mapping region to support 32 CPUs
2014-04-15 11:06 ` Liu Hua
@ 2014-04-15 15:06 ` Nicolas Pitre
-1 siblings, 0 replies; 38+ messages in thread
From: Nicolas Pitre @ 2014-04-15 15:06 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 15 Apr 2014, Liu Hua wrote:
> In 32-bit ARM systems, the fixmap mapping region can support
> no more than 14 CPUs(total: 896k; one CPU: 64K). And we can
> configure NR_CPUS up to 32. So there is a mismatch.
>
> This patch moves fixmapping region downwards to region
> 0xffc00000-0xffe00000. Then the fixmap mapping region can
> support up to 32 CPUs
>
> Signed-off-by: Liu Hua <sdu.liu@huawei.com>
Reviewed-by: Nicolas Pitre <nico@linaro.org>
> ---
> Documentation/arm/memory.txt | 2 +-
> arch/arm/include/asm/fixmap.h | 16 ++--------------
> arch/arm/include/asm/highmem.h | 1 +
> arch/arm/mm/highmem.c | 27 +++++++++++++++++++++------
> arch/arm/mm/mmu.c | 4 ++++
> 5 files changed, 29 insertions(+), 21 deletions(-)
>
> diff --git a/Documentation/arm/memory.txt b/Documentation/arm/memory.txt
> index 4bfb9ff..a9fc59b 100644
> --- a/Documentation/arm/memory.txt
> +++ b/Documentation/arm/memory.txt
> @@ -41,7 +41,7 @@ fffe8000 fffeffff DTCM mapping area for platforms with
> fffe0000 fffe7fff ITCM mapping area for platforms with
> ITCM mounted inside the CPU.
>
> -fff00000 fffdffff Fixmap mapping region. Addresses provided
> +fffc0000 ffdfffff Fixmap mapping region. Addresses provided
> by fix_to_virt() will be located here.
>
> ffc00000 ffefffff DMA memory mapping region. Memory returned
> diff --git a/arch/arm/include/asm/fixmap.h b/arch/arm/include/asm/fixmap.h
> index be55ebc..74124b0 100644
> --- a/arch/arm/include/asm/fixmap.h
> +++ b/arch/arm/include/asm/fixmap.h
> @@ -1,20 +1,8 @@
> #ifndef _ASM_FIXMAP_H
> #define _ASM_FIXMAP_H
>
> -/*
> - * Nothing too fancy for now.
> - *
> - * On ARM we already have well known fixed virtual addresses imposed by
> - * the architecture such as the vector page which is located at 0xffff0000,
> - * therefore a second level page table is already allocated covering
> - * 0xfff00000 upwards.
> - *
> - * The cache flushing code in proc-xscale.S uses the virtual area between
> - * 0xfffe0000 and 0xfffeffff.
> - */
> -
> -#define FIXADDR_START 0xfff00000UL
> -#define FIXADDR_TOP 0xfffe0000UL
> +#define FIXADDR_START 0xffc00000UL
> +#define FIXADDR_TOP 0xffe00000UL
> #define FIXADDR_SIZE (FIXADDR_TOP - FIXADDR_START)
>
> #define FIX_KMAP_NR_PTES (FIXADDR_SIZE >> PAGE_SHIFT)
> diff --git a/arch/arm/include/asm/highmem.h b/arch/arm/include/asm/highmem.h
> index 91b99ab..5355795 100644
> --- a/arch/arm/include/asm/highmem.h
> +++ b/arch/arm/include/asm/highmem.h
> @@ -18,6 +18,7 @@
> } while (0)
>
> extern pte_t *pkmap_page_table;
> +extern pte_t *fixmap_page_table;
>
> extern void *kmap_high(struct page *page);
> extern void kunmap_high(struct page *page);
> diff --git a/arch/arm/mm/highmem.c b/arch/arm/mm/highmem.c
> index e05e8ad..45aeaac 100644
> --- a/arch/arm/mm/highmem.c
> +++ b/arch/arm/mm/highmem.c
> @@ -18,6 +18,21 @@
> #include <asm/tlbflush.h>
> #include "mm.h"
>
> +pte_t *fixmap_page_table;
> +
> +static inline void set_fixmap_pte(int idx, pte_t pte)
> +{
> + unsigned long vaddr = __fix_to_virt(idx);
> + set_pte_ext(fixmap_page_table + idx, pte, 0);
> + local_flush_tlb_kernel_page(vaddr);
> +}
> +
> +static inline pte_t get_fixmap_pte(unsigned long vaddr)
> +{
> + unsigned long idx = __virt_to_fix(vaddr);
> + return *(fixmap_page_table + idx);
> +}
> +
> void *kmap(struct page *page)
> {
> might_sleep();
> @@ -69,14 +84,14 @@ void *kmap_atomic(struct page *page)
> * With debugging enabled, kunmap_atomic forces that entry to 0.
> * Make sure it was indeed properly unmapped.
> */
> - BUG_ON(!pte_none(get_top_pte(vaddr)));
> + BUG_ON(!pte_none(*(fixmap_page_table + idx)));
> #endif
> /*
> * When debugging is off, kunmap_atomic leaves the previous mapping
> * in place, so the contained TLB flush ensures the TLB is updated
> * with the new mapping.
> */
> - set_top_pte(vaddr, mk_pte(page, kmap_prot));
> + set_fixmap_pte(idx, mk_pte(page, kmap_prot));
>
> return (void *)vaddr;
> }
> @@ -95,7 +110,7 @@ void __kunmap_atomic(void *kvaddr)
> __cpuc_flush_dcache_area((void *)vaddr, PAGE_SIZE);
> #ifdef CONFIG_DEBUG_HIGHMEM
> BUG_ON(vaddr != __fix_to_virt(idx));
> - set_top_pte(vaddr, __pte(0));
> + set_fixmap_pte(idx, __pte(0));
> #else
> (void) idx; /* to kill a warning */
> #endif
> @@ -119,9 +134,9 @@ void *kmap_atomic_pfn(unsigned long pfn)
> idx = type + KM_TYPE_NR * smp_processor_id();
> vaddr = __fix_to_virt(idx);
> #ifdef CONFIG_DEBUG_HIGHMEM
> - BUG_ON(!pte_none(get_top_pte(vaddr)));
> + BUG_ON(!pte_none(*(fixmap_page_table + idx)));
> #endif
> - set_top_pte(vaddr, pfn_pte(pfn, kmap_prot));
> + set_fixmap_pte(idx, pfn_pte(pfn, kmap_prot));
>
> return (void *)vaddr;
> }
> @@ -133,5 +148,5 @@ struct page *kmap_atomic_to_page(const void *ptr)
> if (vaddr < FIXADDR_START)
> return virt_to_page(ptr);
>
> - return pte_page(get_top_pte(vaddr));
> + return pte_page(get_fixmap_pte(vaddr));
> }
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index b68c6b2..09c0a16 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -35,6 +35,7 @@
> #include <asm/mach/arch.h>
> #include <asm/mach/map.h>
> #include <asm/mach/pci.h>
> +#include <asm/fixmap.h>
>
> #include "mm.h"
> #include "tcm.h"
> @@ -1359,6 +1360,9 @@ static void __init kmap_init(void)
> #ifdef CONFIG_HIGHMEM
> pkmap_page_table = early_pte_alloc(pmd_off_k(PKMAP_BASE),
> PKMAP_BASE, _PAGE_KERNEL_TABLE);
> +
> + fixmap_page_table = early_pte_alloc(pmd_off_k(FIXADDR_START),
> + FIXADDR_START, _PAGE_KERNEL_TABLE);
> #endif
> }
>
> --
> 1.9.0
>
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: [PATCH v3 2/2] ARM : change fixmap mapping region to support 32 CPUs
@ 2014-04-15 15:06 ` Nicolas Pitre
0 siblings, 0 replies; 38+ messages in thread
From: Nicolas Pitre @ 2014-04-15 15:06 UTC (permalink / raw)
To: Liu Hua
Cc: Russell King - ARM Linux, Will Deacon, vitalya, cyril,
santosh.shilimkar, lauraa, linux-arm-kernel, linux-kernel,
wangnan0, peifeiyue, liusdu
On Tue, 15 Apr 2014, Liu Hua wrote:
> In 32-bit ARM systems, the fixmap mapping region can support
> no more than 14 CPUs(total: 896k; one CPU: 64K). And we can
> configure NR_CPUS up to 32. So there is a mismatch.
>
> This patch moves fixmapping region downwards to region
> 0xffc00000-0xffe00000. Then the fixmap mapping region can
> support up to 32 CPUs
>
> Signed-off-by: Liu Hua <sdu.liu@huawei.com>
Reviewed-by: Nicolas Pitre <nico@linaro.org>
> ---
> Documentation/arm/memory.txt | 2 +-
> arch/arm/include/asm/fixmap.h | 16 ++--------------
> arch/arm/include/asm/highmem.h | 1 +
> arch/arm/mm/highmem.c | 27 +++++++++++++++++++++------
> arch/arm/mm/mmu.c | 4 ++++
> 5 files changed, 29 insertions(+), 21 deletions(-)
>
> diff --git a/Documentation/arm/memory.txt b/Documentation/arm/memory.txt
> index 4bfb9ff..a9fc59b 100644
> --- a/Documentation/arm/memory.txt
> +++ b/Documentation/arm/memory.txt
> @@ -41,7 +41,7 @@ fffe8000 fffeffff DTCM mapping area for platforms with
> fffe0000 fffe7fff ITCM mapping area for platforms with
> ITCM mounted inside the CPU.
>
> -fff00000 fffdffff Fixmap mapping region. Addresses provided
> +fffc0000 ffdfffff Fixmap mapping region. Addresses provided
> by fix_to_virt() will be located here.
>
> ffc00000 ffefffff DMA memory mapping region. Memory returned
> diff --git a/arch/arm/include/asm/fixmap.h b/arch/arm/include/asm/fixmap.h
> index be55ebc..74124b0 100644
> --- a/arch/arm/include/asm/fixmap.h
> +++ b/arch/arm/include/asm/fixmap.h
> @@ -1,20 +1,8 @@
> #ifndef _ASM_FIXMAP_H
> #define _ASM_FIXMAP_H
>
> -/*
> - * Nothing too fancy for now.
> - *
> - * On ARM we already have well known fixed virtual addresses imposed by
> - * the architecture such as the vector page which is located at 0xffff0000,
> - * therefore a second level page table is already allocated covering
> - * 0xfff00000 upwards.
> - *
> - * The cache flushing code in proc-xscale.S uses the virtual area between
> - * 0xfffe0000 and 0xfffeffff.
> - */
> -
> -#define FIXADDR_START 0xfff00000UL
> -#define FIXADDR_TOP 0xfffe0000UL
> +#define FIXADDR_START 0xffc00000UL
> +#define FIXADDR_TOP 0xffe00000UL
> #define FIXADDR_SIZE (FIXADDR_TOP - FIXADDR_START)
>
> #define FIX_KMAP_NR_PTES (FIXADDR_SIZE >> PAGE_SHIFT)
> diff --git a/arch/arm/include/asm/highmem.h b/arch/arm/include/asm/highmem.h
> index 91b99ab..5355795 100644
> --- a/arch/arm/include/asm/highmem.h
> +++ b/arch/arm/include/asm/highmem.h
> @@ -18,6 +18,7 @@
> } while (0)
>
> extern pte_t *pkmap_page_table;
> +extern pte_t *fixmap_page_table;
>
> extern void *kmap_high(struct page *page);
> extern void kunmap_high(struct page *page);
> diff --git a/arch/arm/mm/highmem.c b/arch/arm/mm/highmem.c
> index e05e8ad..45aeaac 100644
> --- a/arch/arm/mm/highmem.c
> +++ b/arch/arm/mm/highmem.c
> @@ -18,6 +18,21 @@
> #include <asm/tlbflush.h>
> #include "mm.h"
>
> +pte_t *fixmap_page_table;
> +
> +static inline void set_fixmap_pte(int idx, pte_t pte)
> +{
> + unsigned long vaddr = __fix_to_virt(idx);
> + set_pte_ext(fixmap_page_table + idx, pte, 0);
> + local_flush_tlb_kernel_page(vaddr);
> +}
> +
> +static inline pte_t get_fixmap_pte(unsigned long vaddr)
> +{
> + unsigned long idx = __virt_to_fix(vaddr);
> + return *(fixmap_page_table + idx);
> +}
> +
> void *kmap(struct page *page)
> {
> might_sleep();
> @@ -69,14 +84,14 @@ void *kmap_atomic(struct page *page)
> * With debugging enabled, kunmap_atomic forces that entry to 0.
> * Make sure it was indeed properly unmapped.
> */
> - BUG_ON(!pte_none(get_top_pte(vaddr)));
> + BUG_ON(!pte_none(*(fixmap_page_table + idx)));
> #endif
> /*
> * When debugging is off, kunmap_atomic leaves the previous mapping
> * in place, so the contained TLB flush ensures the TLB is updated
> * with the new mapping.
> */
> - set_top_pte(vaddr, mk_pte(page, kmap_prot));
> + set_fixmap_pte(idx, mk_pte(page, kmap_prot));
>
> return (void *)vaddr;
> }
> @@ -95,7 +110,7 @@ void __kunmap_atomic(void *kvaddr)
> __cpuc_flush_dcache_area((void *)vaddr, PAGE_SIZE);
> #ifdef CONFIG_DEBUG_HIGHMEM
> BUG_ON(vaddr != __fix_to_virt(idx));
> - set_top_pte(vaddr, __pte(0));
> + set_fixmap_pte(idx, __pte(0));
> #else
> (void) idx; /* to kill a warning */
> #endif
> @@ -119,9 +134,9 @@ void *kmap_atomic_pfn(unsigned long pfn)
> idx = type + KM_TYPE_NR * smp_processor_id();
> vaddr = __fix_to_virt(idx);
> #ifdef CONFIG_DEBUG_HIGHMEM
> - BUG_ON(!pte_none(get_top_pte(vaddr)));
> + BUG_ON(!pte_none(*(fixmap_page_table + idx)));
> #endif
> - set_top_pte(vaddr, pfn_pte(pfn, kmap_prot));
> + set_fixmap_pte(idx, pfn_pte(pfn, kmap_prot));
>
> return (void *)vaddr;
> }
> @@ -133,5 +148,5 @@ struct page *kmap_atomic_to_page(const void *ptr)
> if (vaddr < FIXADDR_START)
> return virt_to_page(ptr);
>
> - return pte_page(get_top_pte(vaddr));
> + return pte_page(get_fixmap_pte(vaddr));
> }
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index b68c6b2..09c0a16 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -35,6 +35,7 @@
> #include <asm/mach/arch.h>
> #include <asm/mach/map.h>
> #include <asm/mach/pci.h>
> +#include <asm/fixmap.h>
>
> #include "mm.h"
> #include "tcm.h"
> @@ -1359,6 +1360,9 @@ static void __init kmap_init(void)
> #ifdef CONFIG_HIGHMEM
> pkmap_page_table = early_pte_alloc(pmd_off_k(PKMAP_BASE),
> PKMAP_BASE, _PAGE_KERNEL_TABLE);
> +
> + fixmap_page_table = early_pte_alloc(pmd_off_k(FIXADDR_START),
> + FIXADDR_START, _PAGE_KERNEL_TABLE);
> #endif
> }
>
> --
> 1.9.0
>
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH v3 2/2] ARM : change fixmap mapping region to support 32 CPUs
2014-04-15 11:06 ` Liu Hua
@ 2014-05-30 15:33 ` Rob Herring
-1 siblings, 0 replies; 38+ messages in thread
From: Rob Herring @ 2014-05-30 15:33 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Apr 15, 2014 at 6:06 AM, Liu Hua <sdu.liu@huawei.com> wrote:
> In 32-bit ARM systems, the fixmap mapping region can support
> no more than 14 CPUs(total: 896k; one CPU: 64K). And we can
> configure NR_CPUS up to 32. So there is a mismatch.
>
> This patch moves fixmapping region downwards to region
> 0xffc00000-0xffe00000. Then the fixmap mapping region can
> support up to 32 CPUs
Ugg, this series breaks using fixmap for anything other than kmap
since 32 cpus requires all 2MB of the region and nothing is left.
There's work in flight to support early_ioremap, early console, and RO
text patching which all use the fixmap region.
There's a couple of options to solve this:
- Only support up to 16 cpus. It could be anywhere between 17-31, but
that seems somewhat unlikely. Are we really ever going to see 32-bit
32 core systems?
- Reduce KM_TYPE_NR from 16 to 15. Based on the comment for it, we
probably don't want to do that. Is increasing it to the default of 20
worthwhile? Some of the options here would allow doing that.
- Add 0xffe00000-0xfff00000 to the fixmap region. This would make
fixmap span 2 PMDs with the top PMD having a mixture of uses like we
had before.
- push the PCI i/o space down to 0xfec00000 and make fixmap 4MB. This
is a cleaner solution as the 2 PMDs are only used for fixmap. This may
require some static mapping adjustments on some platforms.
- Same as previous option, but convert the PCI i/o space to fixmap
entries. We don't really need all 2MB for PCI.
Opinions on the best solution?
Also, there is an error in the documentation below:
>
> Signed-off-by: Liu Hua <sdu.liu@huawei.com>
> ---
> Documentation/arm/memory.txt | 2 +-
> arch/arm/include/asm/fixmap.h | 16 ++--------------
> arch/arm/include/asm/highmem.h | 1 +
> arch/arm/mm/highmem.c | 27 +++++++++++++++++++++------
> arch/arm/mm/mmu.c | 4 ++++
> 5 files changed, 29 insertions(+), 21 deletions(-)
>
> diff --git a/Documentation/arm/memory.txt b/Documentation/arm/memory.txt
> index 4bfb9ff..a9fc59b 100644
> --- a/Documentation/arm/memory.txt
> +++ b/Documentation/arm/memory.txt
> @@ -41,7 +41,7 @@ fffe8000 fffeffff DTCM mapping area for platforms with
> fffe0000 fffe7fff ITCM mapping area for platforms with
> ITCM mounted inside the CPU.
>
> -fff00000 fffdffff Fixmap mapping region. Addresses provided
> +fffc0000 ffdfffff Fixmap mapping region. Addresses provided
s/fffc0000/ffc00000/
Rob
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] ARM : change fixmap mapping region to support 32 CPUs
@ 2014-05-30 15:33 ` Rob Herring
0 siblings, 0 replies; 38+ messages in thread
From: Rob Herring @ 2014-05-30 15:33 UTC (permalink / raw)
To: Liu Hua, Russell King - ARM Linux, Nicolas Pitre
Cc: wangnan0, Laura Abbott, peifeiyue, Will Deacon,
linux-kernel@vger.kernel.org, vitalya, Santosh Shilimkar, liusdu,
cyril, linux-arm-kernel@lists.infradead.org, Rabin Vincent
On Tue, Apr 15, 2014 at 6:06 AM, Liu Hua <sdu.liu@huawei.com> wrote:
> In 32-bit ARM systems, the fixmap mapping region can support
> no more than 14 CPUs(total: 896k; one CPU: 64K). And we can
> configure NR_CPUS up to 32. So there is a mismatch.
>
> This patch moves fixmapping region downwards to region
> 0xffc00000-0xffe00000. Then the fixmap mapping region can
> support up to 32 CPUs
Ugg, this series breaks using fixmap for anything other than kmap
since 32 cpus requires all 2MB of the region and nothing is left.
There's work in flight to support early_ioremap, early console, and RO
text patching which all use the fixmap region.
There's a couple of options to solve this:
- Only support up to 16 cpus. It could be anywhere between 17-31, but
that seems somewhat unlikely. Are we really ever going to see 32-bit
32 core systems?
- Reduce KM_TYPE_NR from 16 to 15. Based on the comment for it, we
probably don't want to do that. Is increasing it to the default of 20
worthwhile? Some of the options here would allow doing that.
- Add 0xffe00000-0xfff00000 to the fixmap region. This would make
fixmap span 2 PMDs with the top PMD having a mixture of uses like we
had before.
- push the PCI i/o space down to 0xfec00000 and make fixmap 4MB. This
is a cleaner solution as the 2 PMDs are only used for fixmap. This may
require some static mapping adjustments on some platforms.
- Same as previous option, but convert the PCI i/o space to fixmap
entries. We don't really need all 2MB for PCI.
Opinions on the best solution?
Also, there is an error in the documentation below:
>
> Signed-off-by: Liu Hua <sdu.liu@huawei.com>
> ---
> Documentation/arm/memory.txt | 2 +-
> arch/arm/include/asm/fixmap.h | 16 ++--------------
> arch/arm/include/asm/highmem.h | 1 +
> arch/arm/mm/highmem.c | 27 +++++++++++++++++++++------
> arch/arm/mm/mmu.c | 4 ++++
> 5 files changed, 29 insertions(+), 21 deletions(-)
>
> diff --git a/Documentation/arm/memory.txt b/Documentation/arm/memory.txt
> index 4bfb9ff..a9fc59b 100644
> --- a/Documentation/arm/memory.txt
> +++ b/Documentation/arm/memory.txt
> @@ -41,7 +41,7 @@ fffe8000 fffeffff DTCM mapping area for platforms with
> fffe0000 fffe7fff ITCM mapping area for platforms with
> ITCM mounted inside the CPU.
>
> -fff00000 fffdffff Fixmap mapping region. Addresses provided
> +fffc0000 ffdfffff Fixmap mapping region. Addresses provided
s/fffc0000/ffc00000/
Rob
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH v3 2/2] ARM : change fixmap mapping region to support 32 CPUs
2014-05-30 15:33 ` Rob Herring
@ 2014-05-30 18:02 ` Will Deacon
-1 siblings, 0 replies; 38+ messages in thread
From: Will Deacon @ 2014-05-30 18:02 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, May 30, 2014 at 04:33:46PM +0100, Rob Herring wrote:
> On Tue, Apr 15, 2014 at 6:06 AM, Liu Hua <sdu.liu@huawei.com> wrote:
> > In 32-bit ARM systems, the fixmap mapping region can support
> > no more than 14 CPUs(total: 896k; one CPU: 64K). And we can
> > configure NR_CPUS up to 32. So there is a mismatch.
> >
> > This patch moves fixmapping region downwards to region
> > 0xffc00000-0xffe00000. Then the fixmap mapping region can
> > support up to 32 CPUs
>
> Ugg, this series breaks using fixmap for anything other than kmap
> since 32 cpus requires all 2MB of the region and nothing is left.
> There's work in flight to support early_ioremap, early console, and RO
> text patching which all use the fixmap region.
>
> There's a couple of options to solve this:
>
> - Only support up to 16 cpus. It could be anywhere between 17-31, but
> that seems somewhat unlikely. Are we really ever going to see 32-bit
> 32 core systems?
I'd be fine with restricting the limit to 16 CPUs.
Will
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] ARM : change fixmap mapping region to support 32 CPUs
@ 2014-05-30 18:02 ` Will Deacon
0 siblings, 0 replies; 38+ messages in thread
From: Will Deacon @ 2014-05-30 18:02 UTC (permalink / raw)
To: Rob Herring
Cc: Liu Hua, Russell King - ARM Linux, Nicolas Pitre,
wangnan0@huawei.com, Laura Abbott, peifeiyue@huawei.com,
linux-kernel@vger.kernel.org, vitalya@ti.com, Santosh Shilimkar,
liusdu@126.co, cyril@ti.com, linux-arm-kernel@lists.infradead.org,
Rabin Vincent
On Fri, May 30, 2014 at 04:33:46PM +0100, Rob Herring wrote:
> On Tue, Apr 15, 2014 at 6:06 AM, Liu Hua <sdu.liu@huawei.com> wrote:
> > In 32-bit ARM systems, the fixmap mapping region can support
> > no more than 14 CPUs(total: 896k; one CPU: 64K). And we can
> > configure NR_CPUS up to 32. So there is a mismatch.
> >
> > This patch moves fixmapping region downwards to region
> > 0xffc00000-0xffe00000. Then the fixmap mapping region can
> > support up to 32 CPUs
>
> Ugg, this series breaks using fixmap for anything other than kmap
> since 32 cpus requires all 2MB of the region and nothing is left.
> There's work in flight to support early_ioremap, early console, and RO
> text patching which all use the fixmap region.
>
> There's a couple of options to solve this:
>
> - Only support up to 16 cpus. It could be anywhere between 17-31, but
> that seems somewhat unlikely. Are we really ever going to see 32-bit
> 32 core systems?
I'd be fine with restricting the limit to 16 CPUs.
Will
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH v3 2/2] ARM : change fixmap mapping region to support 32 CPUs
2014-05-30 15:33 ` Rob Herring
@ 2014-05-30 19:25 ` Nicolas Pitre
-1 siblings, 0 replies; 38+ messages in thread
From: Nicolas Pitre @ 2014-05-30 19:25 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 30 May 2014, Rob Herring wrote:
> There's work in flight to support early_ioremap, early console, and RO
> text patching which all use the fixmap region.
>
> There's a couple of options to solve this:
>
> - Only support up to 16 cpus. It could be anywhere between 17-31, but
> that seems somewhat unlikely. Are we really ever going to see 32-bit
> 32 core systems?
I wouldn't rule that out. I've seen 16-core ARM chips in 2008 (although
they didn't go into production). Silly limitations like that always
come back to bite you. And we have better alternatives.
> - Reduce KM_TYPE_NR from 16 to 15. Based on the comment for it, we
> probably don't want to do that. Is increasing it to the default of 20
> worthwhile? Some of the options here would allow doing that.
> - Add 0xffe00000-0xfff00000 to the fixmap region. This would make
> fixmap span 2 PMDs with the top PMD having a mixture of uses like we
> had before.
That would be my preferred approach. Note here it could be
0xffe00000-0xfffe0000 to include the whole of the previous fixmap area
curently unused.
> - push the PCI i/o space down to 0xfec00000 and make fixmap 4MB. This
> is a cleaner solution as the 2 PMDs are only used for fixmap. This may
> require some static mapping adjustments on some platforms.
No need. With the latest changes, the fixmap area is between 0xffc00000
and 0xffe00000 (there is apparently a mistake in
Documentation/arm/memory.txt). So currently 0xff000000-0xffc00000 is
free, which makes the fixmap area far away from the PCI i/o area with
plenti of space in between.
> - Same as previous option, but convert the PCI i/o space to fixmap
> entries. We don't really need all 2MB for PCI.
See above.
> Also, there is an error in the documentation below:
>
> >
> > Signed-off-by: Liu Hua <sdu.liu@huawei.com>
> > ---
> > Documentation/arm/memory.txt | 2 +-
Yep, good that you spotted it as well. I failed to catch it during my
review so I'll send a patch.
Nicolas
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] ARM : change fixmap mapping region to support 32 CPUs
@ 2014-05-30 19:25 ` Nicolas Pitre
0 siblings, 0 replies; 38+ messages in thread
From: Nicolas Pitre @ 2014-05-30 19:25 UTC (permalink / raw)
To: Rob Herring
Cc: Liu Hua, Russell King - ARM Linux, wangnan0, Laura Abbott,
peifeiyue, Will Deacon, linux-kernel@vger.kernel.org, vitalya,
Santosh Shilimkar, liusdu, cyril,
linux-arm-kernel@lists.infradead.org, Rabin Vincent
On Fri, 30 May 2014, Rob Herring wrote:
> There's work in flight to support early_ioremap, early console, and RO
> text patching which all use the fixmap region.
>
> There's a couple of options to solve this:
>
> - Only support up to 16 cpus. It could be anywhere between 17-31, but
> that seems somewhat unlikely. Are we really ever going to see 32-bit
> 32 core systems?
I wouldn't rule that out. I've seen 16-core ARM chips in 2008 (although
they didn't go into production). Silly limitations like that always
come back to bite you. And we have better alternatives.
> - Reduce KM_TYPE_NR from 16 to 15. Based on the comment for it, we
> probably don't want to do that. Is increasing it to the default of 20
> worthwhile? Some of the options here would allow doing that.
> - Add 0xffe00000-0xfff00000 to the fixmap region. This would make
> fixmap span 2 PMDs with the top PMD having a mixture of uses like we
> had before.
That would be my preferred approach. Note here it could be
0xffe00000-0xfffe0000 to include the whole of the previous fixmap area
curently unused.
> - push the PCI i/o space down to 0xfec00000 and make fixmap 4MB. This
> is a cleaner solution as the 2 PMDs are only used for fixmap. This may
> require some static mapping adjustments on some platforms.
No need. With the latest changes, the fixmap area is between 0xffc00000
and 0xffe00000 (there is apparently a mistake in
Documentation/arm/memory.txt). So currently 0xff000000-0xffc00000 is
free, which makes the fixmap area far away from the PCI i/o area with
plenti of space in between.
> - Same as previous option, but convert the PCI i/o space to fixmap
> entries. We don't really need all 2MB for PCI.
See above.
> Also, there is an error in the documentation below:
>
> >
> > Signed-off-by: Liu Hua <sdu.liu@huawei.com>
> > ---
> > Documentation/arm/memory.txt | 2 +-
Yep, good that you spotted it as well. I failed to catch it during my
review so I'll send a patch.
Nicolas
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH v3 2/2] ARM : change fixmap mapping region to support 32 CPUs
2014-05-30 19:25 ` Nicolas Pitre
@ 2014-06-10 6:52 ` Liu hua
-1 siblings, 0 replies; 38+ messages in thread
From: Liu hua @ 2014-06-10 6:52 UTC (permalink / raw)
To: linux-arm-kernel
On 2014/5/31 3:25, Nicolas Pitre Wrote:
> On Fri, 30 May 2014, Rob Herring wrote:
>
>> There's work in flight to support early_ioremap, early console, and RO
>> text patching which all use the fixmap region.
>>
>> There's a couple of options to solve this:
>>
>> - Only support up to 16 cpus. It could be anywhere between 17-31, but
>> that seems somewhat unlikely. Are we really ever going to see 32-bit
>> 32 core systems?
>
> I wouldn't rule that out. I've seen 16-core ARM chips in 2008 (although
> they didn't go into production). Silly limitations like that always
> come back to bite you. And we have better alternatives.New
Now our team is woring on arma15 with 16 CPUs.
>
>> - Reduce KM_TYPE_NR from 16 to 15. Based on the comment for it, we
>> probably don't want to do that. Is increasing it to the default of 20
>> worthwhile? Some of the options here would allow doing that.
>> - Add 0xffe00000-0xfff00000 to the fixmap region. This would make
>> fixmap span 2 PMDs with the top PMD having a mixture of uses like we
>> had before.
>
> That would be my preferred approach. Note here it could be
> 0xffe00000-0xfffe0000 to include the whole of the previous fixmap area
> curently unused.
>
>> - push the PCI i/o space down to 0xfec00000 and make fixmap 4MB. This
>> is a cleaner solution as the 2 PMDs are only used for fixmap. This may
>> require some static mapping adjustments on some platforms.
>
> No need. With the latest changes, the fixmap area is between 0xffc00000
> and 0xffe00000 (there is apparently a mistake in
> Documentation/arm/memory.txt). So currently 0xff000000-0xffc00000 is
> free, which makes the fixmap area far away from the PCI i/o area with
> plenti of space in between.
>
>> - Same as previous option, but convert the PCI i/o space to fixmap
>> entries. We don't really need all 2MB for PCI.
>
> See above.
>
>> Also, there is an error in the documentation below:
>>
>>>
>>> Signed-off-by: Liu Hua <sdu.liu@huawei.com>
>>> ---
>>> Documentation/arm/memory.txt | 2 +-
>
> Yep, good that you spotted it as well. I failed to catch it during my
> review so I'll send a patch.
>
Very sorry for the mistake and ignoreing this mail. Maybe I should imporve
my email client!
Thanks again for Nicolas.
Thanks,
Liu Hua
>
> Nicolas
>
> .
>
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] ARM : change fixmap mapping region to support 32 CPUs
@ 2014-06-10 6:52 ` Liu hua
0 siblings, 0 replies; 38+ messages in thread
From: Liu hua @ 2014-06-10 6:52 UTC (permalink / raw)
To: Nicolas Pitre, Rob Herring
Cc: Russell King - ARM Linux, wangnan0, Laura Abbott, peifeiyue,
Will Deacon, linux-kernel@vger.kernel.org, vitalya,
Santosh Shilimkar, liusdu, cyril,
linux-arm-kernel@lists.infradead.org, Rabin Vincent
On 2014/5/31 3:25, Nicolas Pitre Wrote:
> On Fri, 30 May 2014, Rob Herring wrote:
>
>> There's work in flight to support early_ioremap, early console, and RO
>> text patching which all use the fixmap region.
>>
>> There's a couple of options to solve this:
>>
>> - Only support up to 16 cpus. It could be anywhere between 17-31, but
>> that seems somewhat unlikely. Are we really ever going to see 32-bit
>> 32 core systems?
>
> I wouldn't rule that out. I've seen 16-core ARM chips in 2008 (although
> they didn't go into production). Silly limitations like that always
> come back to bite you. And we have better alternatives.New
Now our team is woring on arma15 with 16 CPUs.
>
>> - Reduce KM_TYPE_NR from 16 to 15. Based on the comment for it, we
>> probably don't want to do that. Is increasing it to the default of 20
>> worthwhile? Some of the options here would allow doing that.
>> - Add 0xffe00000-0xfff00000 to the fixmap region. This would make
>> fixmap span 2 PMDs with the top PMD having a mixture of uses like we
>> had before.
>
> That would be my preferred approach. Note here it could be
> 0xffe00000-0xfffe0000 to include the whole of the previous fixmap area
> curently unused.
>
>> - push the PCI i/o space down to 0xfec00000 and make fixmap 4MB. This
>> is a cleaner solution as the 2 PMDs are only used for fixmap. This may
>> require some static mapping adjustments on some platforms.
>
> No need. With the latest changes, the fixmap area is between 0xffc00000
> and 0xffe00000 (there is apparently a mistake in
> Documentation/arm/memory.txt). So currently 0xff000000-0xffc00000 is
> free, which makes the fixmap area far away from the PCI i/o area with
> plenti of space in between.
>
>> - Same as previous option, but convert the PCI i/o space to fixmap
>> entries. We don't really need all 2MB for PCI.
>
> See above.
>
>> Also, there is an error in the documentation below:
>>
>>>
>>> Signed-off-by: Liu Hua <sdu.liu@huawei.com>
>>> ---
>>> Documentation/arm/memory.txt | 2 +-
>
> Yep, good that you spotted it as well. I failed to catch it during my
> review so I'll send a patch.
>
Very sorry for the mistake and ignoreing this mail. Maybe I should imporve
my email client!
Thanks again for Nicolas.
Thanks,
Liu Hua
>
> Nicolas
>
> .
>
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH v3 2/2] ARM : change fixmap mapping region to support 32 CPUs
2014-05-30 19:25 ` Nicolas Pitre
@ 2014-08-06 2:51 ` Kees Cook
-1 siblings, 0 replies; 38+ messages in thread
From: Kees Cook @ 2014-08-06 2:51 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, May 30, 2014 at 12:25 PM, Nicolas Pitre
<nicolas.pitre@linaro.org> wrote:
> On Fri, 30 May 2014, Rob Herring wrote:
>
>> There's work in flight to support early_ioremap, early console, and RO
>> text patching which all use the fixmap region.
>>
>> There's a couple of options to solve this:
>>
>> - Only support up to 16 cpus. It could be anywhere between 17-31, but
>> that seems somewhat unlikely. Are we really ever going to see 32-bit
>> 32 core systems?
>
> I wouldn't rule that out. I've seen 16-core ARM chips in 2008 (although
> they didn't go into production). Silly limitations like that always
> come back to bite you. And we have better alternatives.
>
>> - Reduce KM_TYPE_NR from 16 to 15. Based on the comment for it, we
>> probably don't want to do that. Is increasing it to the default of 20
>> worthwhile? Some of the options here would allow doing that.
>> - Add 0xffe00000-0xfff00000 to the fixmap region. This would make
>> fixmap span 2 PMDs with the top PMD having a mixture of uses like we
>> had before.
>
> That would be my preferred approach. Note here it could be
> 0xffe00000-0xfffe0000 to include the whole of the previous fixmap area
> curently unused.
>
>> - push the PCI i/o space down to 0xfec00000 and make fixmap 4MB. This
>> is a cleaner solution as the 2 PMDs are only used for fixmap. This may
>> require some static mapping adjustments on some platforms.
>
> No need. With the latest changes, the fixmap area is between 0xffc00000
> and 0xffe00000 (there is apparently a mistake in
> Documentation/arm/memory.txt). So currently 0xff000000-0xffc00000 is
> free, which makes the fixmap area far away from the PCI i/o area with
> plenti of space in between.
So, it seems there is something wrong with this patch series. I had to
revert "ARM: 8031/2: change fixmap mapping region to support 32 CPUs"
to make other fixmap changes work correctly. I think this is due to
the non-highmem config case moving the fixmap to a location where
there is to page table entry...
-Kees
>
>> - Same as previous option, but convert the PCI i/o space to fixmap
>> entries. We don't really need all 2MB for PCI.
>
> See above.
>
>> Also, there is an error in the documentation below:
>>
>> >
>> > Signed-off-by: Liu Hua <sdu.liu@huawei.com>
>> > ---
>> > Documentation/arm/memory.txt | 2 +-
>
> Yep, good that you spotted it as well. I failed to catch it during my
> review so I'll send a patch.
>
>
> Nicolas
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Kees Cook
Chrome OS Security
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] ARM : change fixmap mapping region to support 32 CPUs
@ 2014-08-06 2:51 ` Kees Cook
0 siblings, 0 replies; 38+ messages in thread
From: Kees Cook @ 2014-08-06 2:51 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Rob Herring, wangnan0, Laura Abbott, peifeiyue, Liu Hua,
Will Deacon, linux-kernel@vger.kernel.org, Vitaly Andrianov,
Rabin Vincent, Santosh Shilimkar, liusdu, Cyril Chemparathy,
Russell King - ARM Linux, linux-arm-kernel@lists.infradead.org
On Fri, May 30, 2014 at 12:25 PM, Nicolas Pitre
<nicolas.pitre@linaro.org> wrote:
> On Fri, 30 May 2014, Rob Herring wrote:
>
>> There's work in flight to support early_ioremap, early console, and RO
>> text patching which all use the fixmap region.
>>
>> There's a couple of options to solve this:
>>
>> - Only support up to 16 cpus. It could be anywhere between 17-31, but
>> that seems somewhat unlikely. Are we really ever going to see 32-bit
>> 32 core systems?
>
> I wouldn't rule that out. I've seen 16-core ARM chips in 2008 (although
> they didn't go into production). Silly limitations like that always
> come back to bite you. And we have better alternatives.
>
>> - Reduce KM_TYPE_NR from 16 to 15. Based on the comment for it, we
>> probably don't want to do that. Is increasing it to the default of 20
>> worthwhile? Some of the options here would allow doing that.
>> - Add 0xffe00000-0xfff00000 to the fixmap region. This would make
>> fixmap span 2 PMDs with the top PMD having a mixture of uses like we
>> had before.
>
> That would be my preferred approach. Note here it could be
> 0xffe00000-0xfffe0000 to include the whole of the previous fixmap area
> curently unused.
>
>> - push the PCI i/o space down to 0xfec00000 and make fixmap 4MB. This
>> is a cleaner solution as the 2 PMDs are only used for fixmap. This may
>> require some static mapping adjustments on some platforms.
>
> No need. With the latest changes, the fixmap area is between 0xffc00000
> and 0xffe00000 (there is apparently a mistake in
> Documentation/arm/memory.txt). So currently 0xff000000-0xffc00000 is
> free, which makes the fixmap area far away from the PCI i/o area with
> plenti of space in between.
So, it seems there is something wrong with this patch series. I had to
revert "ARM: 8031/2: change fixmap mapping region to support 32 CPUs"
to make other fixmap changes work correctly. I think this is due to
the non-highmem config case moving the fixmap to a location where
there is to page table entry...
-Kees
>
>> - Same as previous option, but convert the PCI i/o space to fixmap
>> entries. We don't really need all 2MB for PCI.
>
> See above.
>
>> Also, there is an error in the documentation below:
>>
>> >
>> > Signed-off-by: Liu Hua <sdu.liu@huawei.com>
>> > ---
>> > Documentation/arm/memory.txt | 2 +-
>
> Yep, good that you spotted it as well. I failed to catch it during my
> review so I'll send a patch.
>
>
> Nicolas
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Kees Cook
Chrome OS Security
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH v3 2/2] ARM : change fixmap mapping region to support 32 CPUs
2014-08-06 2:51 ` Kees Cook
@ 2014-08-06 3:11 ` Nicolas Pitre
-1 siblings, 0 replies; 38+ messages in thread
From: Nicolas Pitre @ 2014-08-06 3:11 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 5 Aug 2014, Kees Cook wrote:
> On Fri, May 30, 2014 at 12:25 PM, Nicolas Pitre
> <nicolas.pitre@linaro.org> wrote:
> > On Fri, 30 May 2014, Rob Herring wrote:
> >
> >> There's work in flight to support early_ioremap, early console, and RO
> >> text patching which all use the fixmap region.
> >>
> >> There's a couple of options to solve this:
> >>
> >> - Only support up to 16 cpus. It could be anywhere between 17-31, but
> >> that seems somewhat unlikely. Are we really ever going to see 32-bit
> >> 32 core systems?
> >
> > I wouldn't rule that out. I've seen 16-core ARM chips in 2008 (although
> > they didn't go into production). Silly limitations like that always
> > come back to bite you. And we have better alternatives.
> >
> >> - Reduce KM_TYPE_NR from 16 to 15. Based on the comment for it, we
> >> probably don't want to do that. Is increasing it to the default of 20
> >> worthwhile? Some of the options here would allow doing that.
> >> - Add 0xffe00000-0xfff00000 to the fixmap region. This would make
> >> fixmap span 2 PMDs with the top PMD having a mixture of uses like we
> >> had before.
> >
> > That would be my preferred approach. Note here it could be
> > 0xffe00000-0xfffe0000 to include the whole of the previous fixmap area
> > curently unused.
> >
> >> - push the PCI i/o space down to 0xfec00000 and make fixmap 4MB. This
> >> is a cleaner solution as the 2 PMDs are only used for fixmap. This may
> >> require some static mapping adjustments on some platforms.
> >
> > No need. With the latest changes, the fixmap area is between 0xffc00000
> > and 0xffe00000 (there is apparently a mistake in
> > Documentation/arm/memory.txt). So currently 0xff000000-0xffc00000 is
> > free, which makes the fixmap area far away from the PCI i/o area with
> > plenti of space in between.
>
> So, it seems there is something wrong with this patch series. I had to
> revert "ARM: 8031/2: change fixmap mapping region to support 32 CPUs"
> to make other fixmap changes work correctly. I think this is due to
> the non-highmem config case moving the fixmap to a location where
> there is to page table entry...
Could you elaborate please? How can the non-highmem config move the
fixmap area? And what are those other fixmap changes?
Nicolas
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] ARM : change fixmap mapping region to support 32 CPUs
@ 2014-08-06 3:11 ` Nicolas Pitre
0 siblings, 0 replies; 38+ messages in thread
From: Nicolas Pitre @ 2014-08-06 3:11 UTC (permalink / raw)
To: Kees Cook
Cc: Rob Herring, wangnan0, Laura Abbott, peifeiyue, Liu Hua,
Will Deacon, linux-kernel@vger.kernel.org, Vitaly Andrianov,
Rabin Vincent, Santosh Shilimkar, liusdu, Cyril Chemparathy,
Russell King - ARM Linux, linux-arm-kernel@lists.infradead.org
On Tue, 5 Aug 2014, Kees Cook wrote:
> On Fri, May 30, 2014 at 12:25 PM, Nicolas Pitre
> <nicolas.pitre@linaro.org> wrote:
> > On Fri, 30 May 2014, Rob Herring wrote:
> >
> >> There's work in flight to support early_ioremap, early console, and RO
> >> text patching which all use the fixmap region.
> >>
> >> There's a couple of options to solve this:
> >>
> >> - Only support up to 16 cpus. It could be anywhere between 17-31, but
> >> that seems somewhat unlikely. Are we really ever going to see 32-bit
> >> 32 core systems?
> >
> > I wouldn't rule that out. I've seen 16-core ARM chips in 2008 (although
> > they didn't go into production). Silly limitations like that always
> > come back to bite you. And we have better alternatives.
> >
> >> - Reduce KM_TYPE_NR from 16 to 15. Based on the comment for it, we
> >> probably don't want to do that. Is increasing it to the default of 20
> >> worthwhile? Some of the options here would allow doing that.
> >> - Add 0xffe00000-0xfff00000 to the fixmap region. This would make
> >> fixmap span 2 PMDs with the top PMD having a mixture of uses like we
> >> had before.
> >
> > That would be my preferred approach. Note here it could be
> > 0xffe00000-0xfffe0000 to include the whole of the previous fixmap area
> > curently unused.
> >
> >> - push the PCI i/o space down to 0xfec00000 and make fixmap 4MB. This
> >> is a cleaner solution as the 2 PMDs are only used for fixmap. This may
> >> require some static mapping adjustments on some platforms.
> >
> > No need. With the latest changes, the fixmap area is between 0xffc00000
> > and 0xffe00000 (there is apparently a mistake in
> > Documentation/arm/memory.txt). So currently 0xff000000-0xffc00000 is
> > free, which makes the fixmap area far away from the PCI i/o area with
> > plenti of space in between.
>
> So, it seems there is something wrong with this patch series. I had to
> revert "ARM: 8031/2: change fixmap mapping region to support 32 CPUs"
> to make other fixmap changes work correctly. I think this is due to
> the non-highmem config case moving the fixmap to a location where
> there is to page table entry...
Could you elaborate please? How can the non-highmem config move the
fixmap area? And what are those other fixmap changes?
Nicolas
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH v3 2/2] ARM : change fixmap mapping region to support 32 CPUs
2014-08-06 2:51 ` Kees Cook
@ 2014-08-06 3:40 ` Liu hua
-1 siblings, 0 replies; 38+ messages in thread
From: Liu hua @ 2014-08-06 3:40 UTC (permalink / raw)
To: linux-arm-kernel
? 2014/8/6 10:51, Kees Cook ??:
> On Fri, May 30, 2014 at 12:25 PM, Nicolas Pitre
> <nicolas.pitre@linaro.org> wrote:
>> On Fri, 30 May 2014, Rob Herring wrote:
>>
>>> There's work in flight to support early_ioremap, early console, and RO
>>> text patching which all use the fixmap region.
>>>
>>> There's a couple of options to solve this:
>>>
>>> - Only support up to 16 cpus. It could be anywhere between 17-31, but
>>> that seems somewhat unlikely. Are we really ever going to see 32-bit
>>> 32 core systems?
>>
>> I wouldn't rule that out. I've seen 16-core ARM chips in 2008 (although
>> they didn't go into production). Silly limitations like that always
>> come back to bite you. And we have better alternatives.
>>
>>> - Reduce KM_TYPE_NR from 16 to 15. Based on the comment for it, we
>>> probably don't want to do that. Is increasing it to the default of 20
>>> worthwhile? Some of the options here would allow doing that.
>>> - Add 0xffe00000-0xfff00000 to the fixmap region. This would make
>>> fixmap span 2 PMDs with the top PMD having a mixture of uses like we
>>> had before.
>>
>> That would be my preferred approach. Note here it could be
>> 0xffe00000-0xfffe0000 to include the whole of the previous fixmap area
>> curently unused.
>>
>>> - push the PCI i/o space down to 0xfec00000 and make fixmap 4MB. This
>>> is a cleaner solution as the 2 PMDs are only used for fixmap. This may
>>> require some static mapping adjustments on some platforms.
>>
>> No need. With the latest changes, the fixmap area is between 0xffc00000
>> and 0xffe00000 (there is apparently a mistake in
>> Documentation/arm/memory.txt). So currently 0xff000000-0xffc00000 is
>> free, which makes the fixmap area far away from the PCI i/o area with
>> plenti of space in between.
>
> So, it seems there is something wrong with this patch series. I had to
> revert "ARM: 8031/2: change fixmap mapping region to support 32 CPUs"
> to make other fixmap changes work correctly. I think this is due to
> the non-highmem config case moving the fixmap to a location where
> there is to page table entry...
Hi Kees,
Did this patch conflict with others, or it will at the future?
As Rob said "There's work in flight to support early_ioremap, early console, and RO
text patching which all use the fixmap region." So if this patch will block kernel's
new feature, Should we makes new patch to changes it, not revert it. Because there are
arm platforms with more than 14 CPUs.
Thanks,
Liu Hua
>
> -Kees
>
>>
>>> - Same as previous option, but convert the PCI i/o space to fixmap
>>> entries. We don't really need all 2MB for PCI.
>>
>> See above.
>>
>>> Also, there is an error in the documentation below:
>>>
>>>>
>>>> Signed-off-by: Liu Hua <sdu.liu@huawei.com>
>>>> ---
>>>> Documentation/arm/memory.txt | 2 +-
>>
>> Yep, good that you spotted it as well. I failed to catch it during my
>> review so I'll send a patch.
>>
>>
>> Nicolas
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
>
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] ARM : change fixmap mapping region to support 32 CPUs
@ 2014-08-06 3:40 ` Liu hua
0 siblings, 0 replies; 38+ messages in thread
From: Liu hua @ 2014-08-06 3:40 UTC (permalink / raw)
To: Kees Cook, Nicolas Pitre, Rob Herring
Cc: wangnan0, Laura Abbott, peifeiyue, Will Deacon,
linux-kernel@vger.kernel.org, Vitaly Andrianov, Rabin Vincent,
Santosh Shilimkar, liusdu@126.com, Cyril Chemparathy,
Russell King - ARM Linux, linux-arm-kernel@lists.infradead.org
于 2014/8/6 10:51, Kees Cook 写道:
> On Fri, May 30, 2014 at 12:25 PM, Nicolas Pitre
> <nicolas.pitre@linaro.org> wrote:
>> On Fri, 30 May 2014, Rob Herring wrote:
>>
>>> There's work in flight to support early_ioremap, early console, and RO
>>> text patching which all use the fixmap region.
>>>
>>> There's a couple of options to solve this:
>>>
>>> - Only support up to 16 cpus. It could be anywhere between 17-31, but
>>> that seems somewhat unlikely. Are we really ever going to see 32-bit
>>> 32 core systems?
>>
>> I wouldn't rule that out. I've seen 16-core ARM chips in 2008 (although
>> they didn't go into production). Silly limitations like that always
>> come back to bite you. And we have better alternatives.
>>
>>> - Reduce KM_TYPE_NR from 16 to 15. Based on the comment for it, we
>>> probably don't want to do that. Is increasing it to the default of 20
>>> worthwhile? Some of the options here would allow doing that.
>>> - Add 0xffe00000-0xfff00000 to the fixmap region. This would make
>>> fixmap span 2 PMDs with the top PMD having a mixture of uses like we
>>> had before.
>>
>> That would be my preferred approach. Note here it could be
>> 0xffe00000-0xfffe0000 to include the whole of the previous fixmap area
>> curently unused.
>>
>>> - push the PCI i/o space down to 0xfec00000 and make fixmap 4MB. This
>>> is a cleaner solution as the 2 PMDs are only used for fixmap. This may
>>> require some static mapping adjustments on some platforms.
>>
>> No need. With the latest changes, the fixmap area is between 0xffc00000
>> and 0xffe00000 (there is apparently a mistake in
>> Documentation/arm/memory.txt). So currently 0xff000000-0xffc00000 is
>> free, which makes the fixmap area far away from the PCI i/o area with
>> plenti of space in between.
>
> So, it seems there is something wrong with this patch series. I had to
> revert "ARM: 8031/2: change fixmap mapping region to support 32 CPUs"
> to make other fixmap changes work correctly. I think this is due to
> the non-highmem config case moving the fixmap to a location where
> there is to page table entry...
Hi Kees,
Did this patch conflict with others, or it will at the future?
As Rob said "There's work in flight to support early_ioremap, early console, and RO
text patching which all use the fixmap region." So if this patch will block kernel's
new feature, Should we makes new patch to changes it, not revert it. Because there are
arm platforms with more than 14 CPUs.
Thanks,
Liu Hua
>
> -Kees
>
>>
>>> - Same as previous option, but convert the PCI i/o space to fixmap
>>> entries. We don't really need all 2MB for PCI.
>>
>> See above.
>>
>>> Also, there is an error in the documentation below:
>>>
>>>>
>>>> Signed-off-by: Liu Hua <sdu.liu@huawei.com>
>>>> ---
>>>> Documentation/arm/memory.txt | 2 +-
>>
>> Yep, good that you spotted it as well. I failed to catch it during my
>> review so I'll send a patch.
>>
>>
>> Nicolas
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
>
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH v3 2/2] ARM : change fixmap mapping region to support 32 CPUs
2014-08-06 3:40 ` Liu hua
@ 2014-08-06 16:37 ` Kees Cook
-1 siblings, 0 replies; 38+ messages in thread
From: Kees Cook @ 2014-08-06 16:37 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Aug 5, 2014 at 8:40 PM, Liu hua <sdu.liu@huawei.com> wrote:
> ? 2014/8/6 10:51, Kees Cook ??:
>> On Fri, May 30, 2014 at 12:25 PM, Nicolas Pitre
>> <nicolas.pitre@linaro.org> wrote:
>>> On Fri, 30 May 2014, Rob Herring wrote:
>>>
>>>> There's work in flight to support early_ioremap, early console, and RO
>>>> text patching which all use the fixmap region.
>>>>
>>>> There's a couple of options to solve this:
>>>>
>>>> - Only support up to 16 cpus. It could be anywhere between 17-31, but
>>>> that seems somewhat unlikely. Are we really ever going to see 32-bit
>>>> 32 core systems?
>>>
>>> I wouldn't rule that out. I've seen 16-core ARM chips in 2008 (although
>>> they didn't go into production). Silly limitations like that always
>>> come back to bite you. And we have better alternatives.
>>>
>>>> - Reduce KM_TYPE_NR from 16 to 15. Based on the comment for it, we
>>>> probably don't want to do that. Is increasing it to the default of 20
>>>> worthwhile? Some of the options here would allow doing that.
>>>> - Add 0xffe00000-0xfff00000 to the fixmap region. This would make
>>>> fixmap span 2 PMDs with the top PMD having a mixture of uses like we
>>>> had before.
>>>
>>> That would be my preferred approach. Note here it could be
>>> 0xffe00000-0xfffe0000 to include the whole of the previous fixmap area
>>> curently unused.
>>>
>>>> - push the PCI i/o space down to 0xfec00000 and make fixmap 4MB. This
>>>> is a cleaner solution as the 2 PMDs are only used for fixmap. This may
>>>> require some static mapping adjustments on some platforms.
>>>
>>> No need. With the latest changes, the fixmap area is between 0xffc00000
>>> and 0xffe00000 (there is apparently a mistake in
>>> Documentation/arm/memory.txt). So currently 0xff000000-0xffc00000 is
>>> free, which makes the fixmap area far away from the PCI i/o area with
>>> plenti of space in between.
>>
>> So, it seems there is something wrong with this patch series. I had to
>> revert "ARM: 8031/2: change fixmap mapping region to support 32 CPUs"
>> to make other fixmap changes work correctly. I think this is due to
>> the non-highmem config case moving the fixmap to a location where
>> there is to page table entry...
> Hi Kees,
>
> Did this patch conflict with others, or it will at the future?
Strictly from the perspective of upstream, it conflicts with future
patches (I'm working on the RO text patching bit currently). There was
a fixmap series before (from Mark Salter and Rabin Vincent) that
worked, but after rebasing to the current tree, this 32-cpu support
patch appears to break it.
> As Rob said "There's work in flight to support early_ioremap, early console, and RO
> text patching which all use the fixmap region." So if this patch will block kernel's
> new feature, Should we makes new patch to changes it, not revert it. Because there are
> arm platforms with more than 14 CPUs.
Right -- it seems like for kmap stuff, 64k is needed per CPU? I
thought there was agreement to do 16 CPUs, rather than 32. But let me
merge threads, and add Nicolas's question...
Nicolas Pitre said:
> Could you elaborate please? How can the non-highmem config move the
> fixmap area? And what are those other fixmap changes?
The comment and code that existed before the patch said this:
/*
* Nothing too fancy for now.
*
* On ARM we already have well known fixed virtual addresses imposed by
* the architecture such as the vector page which is located at 0xffff0000,
* therefore a second level page table is already allocated covering
* 0xfff00000 upwards.
*
* The cache flushing code in proc-xscale.S uses the virtual area between
* 0xfffe0000 and 0xfffeffff.
*/
#define FIXADDR_START 0xfff00000UL
#define FIXADDR_END 0xfffe0000UL
After the patch:
#define FIXADDR_START 0xffc00000UL
#define FIXADDR_TOP 0xffe00000UL
With the original code, there is (I think) a page table entry for the
fixmap range. For the latter, there isn't. I see a NULL pgd entry
fault when trying to use it, and noticed that this only exists under
highmem:
static void __init kmap_init(void)
{
#ifdef CONFIG_HIGHMEM
pkmap_page_table = early_pte_alloc(pmd_off_k(PKMAP_BASE),
PKMAP_BASE, _PAGE_KERNEL_TABLE);
fixmap_page_table = early_pte_alloc(pmd_off_k(FIXADDR_START),
FIXADDR_START, _PAGE_KERNEL_TABLE);
#endif
}
My initial attempts at using HIGHMEM failed, but I think that's
because it the entire fixmap area was taken by the kmap 32-cpu stuff.
I'm going to continue playing with it, but if anyone sees a trivial
solution, I'd love to know. :) It's not clear to me what's needed to
get the page table initialized for the whole region (with or without
HIGHMEM).
Thanks!
-Kees
>
> Thanks,
> Liu Hua
>>
>> -Kees
>>
>>>
>>>> - Same as previous option, but convert the PCI i/o space to fixmap
>>>> entries. We don't really need all 2MB for PCI.
>>>
>>> See above.
>>>
>>>> Also, there is an error in the documentation below:
>>>>
>>>>>
>>>>> Signed-off-by: Liu Hua <sdu.liu@huawei.com>
>>>>> ---
>>>>> Documentation/arm/memory.txt | 2 +-
>>>
>>> Yep, good that you spotted it as well. I failed to catch it during my
>>> review so I'll send a patch.
>>>
>>>
>>> Nicolas
>>>
>>> _______________________________________________
>>> linux-arm-kernel mailing list
>>> linux-arm-kernel at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>>
>>
>
>
--
Kees Cook
Chrome OS Security
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: [PATCH v3 2/2] ARM : change fixmap mapping region to support 32 CPUs
@ 2014-08-06 16:37 ` Kees Cook
0 siblings, 0 replies; 38+ messages in thread
From: Kees Cook @ 2014-08-06 16:37 UTC (permalink / raw)
To: Liu hua
Cc: Nicolas Pitre, Rob Herring, wangnan0, Laura Abbott, peifeiyue,
Will Deacon, linux-kernel@vger.kernel.org, Vitaly Andrianov,
Rabin Vincent, Santosh Shilimkar, liusdu@126.com,
Russell King - ARM Linux, linux-arm-kernel@lists.infradead.org,
Mark Salter
On Tue, Aug 5, 2014 at 8:40 PM, Liu hua <sdu.liu@huawei.com> wrote:
> 于 2014/8/6 10:51, Kees Cook 写道:
>> On Fri, May 30, 2014 at 12:25 PM, Nicolas Pitre
>> <nicolas.pitre@linaro.org> wrote:
>>> On Fri, 30 May 2014, Rob Herring wrote:
>>>
>>>> There's work in flight to support early_ioremap, early console, and RO
>>>> text patching which all use the fixmap region.
>>>>
>>>> There's a couple of options to solve this:
>>>>
>>>> - Only support up to 16 cpus. It could be anywhere between 17-31, but
>>>> that seems somewhat unlikely. Are we really ever going to see 32-bit
>>>> 32 core systems?
>>>
>>> I wouldn't rule that out. I've seen 16-core ARM chips in 2008 (although
>>> they didn't go into production). Silly limitations like that always
>>> come back to bite you. And we have better alternatives.
>>>
>>>> - Reduce KM_TYPE_NR from 16 to 15. Based on the comment for it, we
>>>> probably don't want to do that. Is increasing it to the default of 20
>>>> worthwhile? Some of the options here would allow doing that.
>>>> - Add 0xffe00000-0xfff00000 to the fixmap region. This would make
>>>> fixmap span 2 PMDs with the top PMD having a mixture of uses like we
>>>> had before.
>>>
>>> That would be my preferred approach. Note here it could be
>>> 0xffe00000-0xfffe0000 to include the whole of the previous fixmap area
>>> curently unused.
>>>
>>>> - push the PCI i/o space down to 0xfec00000 and make fixmap 4MB. This
>>>> is a cleaner solution as the 2 PMDs are only used for fixmap. This may
>>>> require some static mapping adjustments on some platforms.
>>>
>>> No need. With the latest changes, the fixmap area is between 0xffc00000
>>> and 0xffe00000 (there is apparently a mistake in
>>> Documentation/arm/memory.txt). So currently 0xff000000-0xffc00000 is
>>> free, which makes the fixmap area far away from the PCI i/o area with
>>> plenti of space in between.
>>
>> So, it seems there is something wrong with this patch series. I had to
>> revert "ARM: 8031/2: change fixmap mapping region to support 32 CPUs"
>> to make other fixmap changes work correctly. I think this is due to
>> the non-highmem config case moving the fixmap to a location where
>> there is to page table entry...
> Hi Kees,
>
> Did this patch conflict with others, or it will at the future?
Strictly from the perspective of upstream, it conflicts with future
patches (I'm working on the RO text patching bit currently). There was
a fixmap series before (from Mark Salter and Rabin Vincent) that
worked, but after rebasing to the current tree, this 32-cpu support
patch appears to break it.
> As Rob said "There's work in flight to support early_ioremap, early console, and RO
> text patching which all use the fixmap region." So if this patch will block kernel's
> new feature, Should we makes new patch to changes it, not revert it. Because there are
> arm platforms with more than 14 CPUs.
Right -- it seems like for kmap stuff, 64k is needed per CPU? I
thought there was agreement to do 16 CPUs, rather than 32. But let me
merge threads, and add Nicolas's question...
Nicolas Pitre said:
> Could you elaborate please? How can the non-highmem config move the
> fixmap area? And what are those other fixmap changes?
The comment and code that existed before the patch said this:
/*
* Nothing too fancy for now.
*
* On ARM we already have well known fixed virtual addresses imposed by
* the architecture such as the vector page which is located at 0xffff0000,
* therefore a second level page table is already allocated covering
* 0xfff00000 upwards.
*
* The cache flushing code in proc-xscale.S uses the virtual area between
* 0xfffe0000 and 0xfffeffff.
*/
#define FIXADDR_START 0xfff00000UL
#define FIXADDR_END 0xfffe0000UL
After the patch:
#define FIXADDR_START 0xffc00000UL
#define FIXADDR_TOP 0xffe00000UL
With the original code, there is (I think) a page table entry for the
fixmap range. For the latter, there isn't. I see a NULL pgd entry
fault when trying to use it, and noticed that this only exists under
highmem:
static void __init kmap_init(void)
{
#ifdef CONFIG_HIGHMEM
pkmap_page_table = early_pte_alloc(pmd_off_k(PKMAP_BASE),
PKMAP_BASE, _PAGE_KERNEL_TABLE);
fixmap_page_table = early_pte_alloc(pmd_off_k(FIXADDR_START),
FIXADDR_START, _PAGE_KERNEL_TABLE);
#endif
}
My initial attempts at using HIGHMEM failed, but I think that's
because it the entire fixmap area was taken by the kmap 32-cpu stuff.
I'm going to continue playing with it, but if anyone sees a trivial
solution, I'd love to know. :) It's not clear to me what's needed to
get the page table initialized for the whole region (with or without
HIGHMEM).
Thanks!
-Kees
>
> Thanks,
> Liu Hua
>>
>> -Kees
>>
>>>
>>>> - Same as previous option, but convert the PCI i/o space to fixmap
>>>> entries. We don't really need all 2MB for PCI.
>>>
>>> See above.
>>>
>>>> Also, there is an error in the documentation below:
>>>>
>>>>>
>>>>> Signed-off-by: Liu Hua <sdu.liu@huawei.com>
>>>>> ---
>>>>> Documentation/arm/memory.txt | 2 +-
>>>
>>> Yep, good that you spotted it as well. I failed to catch it during my
>>> review so I'll send a patch.
>>>
>>>
>>> Nicolas
>>>
>>> _______________________________________________
>>> linux-arm-kernel mailing list
>>> linux-arm-kernel@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>>
>>
>
>
--
Kees Cook
Chrome OS Security
^ permalink raw reply [flat|nested] 38+ messages in thread* [PATCH v3 2/2] ARM : change fixmap mapping region to support 32 CPUs
2014-08-06 16:37 ` Kees Cook
@ 2014-08-06 17:21 ` Nicolas Pitre
-1 siblings, 0 replies; 38+ messages in thread
From: Nicolas Pitre @ 2014-08-06 17:21 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, 6 Aug 2014, Kees Cook wrote:
> With the original code, there is (I think) a page table entry for the
> fixmap range. For the latter, there isn't. I see a NULL pgd entry
> fault when trying to use it, and noticed that this only exists under
> highmem:
>
> static void __init kmap_init(void)
> {
> #ifdef CONFIG_HIGHMEM
> pkmap_page_table = early_pte_alloc(pmd_off_k(PKMAP_BASE),
> PKMAP_BASE, _PAGE_KERNEL_TABLE);
>
> fixmap_page_table = early_pte_alloc(pmd_off_k(FIXADDR_START),
> FIXADDR_START, _PAGE_KERNEL_TABLE);
> #endif
> }
The above is wrong. The fixmap PTEs must be allocated unconditionally
irrespective of highmem. So the #endif should be moved up by 3 lines.
Nicolas
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: [PATCH v3 2/2] ARM : change fixmap mapping region to support 32 CPUs
@ 2014-08-06 17:21 ` Nicolas Pitre
0 siblings, 0 replies; 38+ messages in thread
From: Nicolas Pitre @ 2014-08-06 17:21 UTC (permalink / raw)
To: Kees Cook
Cc: Liu hua, Rob Herring, wangnan0, Laura Abbott, peifeiyue,
Will Deacon, linux-kernel@vger.kernel.org, Vitaly Andrianov,
Rabin Vincent, Santosh Shilimkar, liusdu@126.com,
Russell King - ARM Linux, linux-arm-kernel@lists.infradead.org,
Mark Salter
On Wed, 6 Aug 2014, Kees Cook wrote:
> With the original code, there is (I think) a page table entry for the
> fixmap range. For the latter, there isn't. I see a NULL pgd entry
> fault when trying to use it, and noticed that this only exists under
> highmem:
>
> static void __init kmap_init(void)
> {
> #ifdef CONFIG_HIGHMEM
> pkmap_page_table = early_pte_alloc(pmd_off_k(PKMAP_BASE),
> PKMAP_BASE, _PAGE_KERNEL_TABLE);
>
> fixmap_page_table = early_pte_alloc(pmd_off_k(FIXADDR_START),
> FIXADDR_START, _PAGE_KERNEL_TABLE);
> #endif
> }
The above is wrong. The fixmap PTEs must be allocated unconditionally
irrespective of highmem. So the #endif should be moved up by 3 lines.
Nicolas
^ permalink raw reply [flat|nested] 38+ messages in thread* [PATCH v3 2/2] ARM : change fixmap mapping region to support 32 CPUs
2014-08-06 17:21 ` Nicolas Pitre
@ 2014-08-06 17:28 ` Kees Cook
-1 siblings, 0 replies; 38+ messages in thread
From: Kees Cook @ 2014-08-06 17:28 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Aug 6, 2014 at 10:21 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Wed, 6 Aug 2014, Kees Cook wrote:
>
>> With the original code, there is (I think) a page table entry for the
>> fixmap range. For the latter, there isn't. I see a NULL pgd entry
>> fault when trying to use it, and noticed that this only exists under
>> highmem:
>>
>> static void __init kmap_init(void)
>> {
>> #ifdef CONFIG_HIGHMEM
>> pkmap_page_table = early_pte_alloc(pmd_off_k(PKMAP_BASE),
>> PKMAP_BASE, _PAGE_KERNEL_TABLE);
>>
>> fixmap_page_table = early_pte_alloc(pmd_off_k(FIXADDR_START),
>> FIXADDR_START, _PAGE_KERNEL_TABLE);
>> #endif
>> }
>
> The above is wrong. The fixmap PTEs must be allocated unconditionally
> irrespective of highmem. So the #endif should be moved up by 3 lines.
That's what I was thinking. I tried this, and things are still weird,
though I think I'm narrowing it down. I made the early_pte_alloc
happen, but after boot it doesn't show up in
/sys/kernel/debug/kernel_page_tables. When I attempt a fixmap text
poke, I get this out of dmesg (lkdtm is reporting the address returned
from the patch mapping):
lkdtm: 80421ac0 mapped RW via ffdefac0
Unable to handle kernel paging request at virtual address ffdefac0
pgd = 9e888000
[ffdefac0] *pgd=9fffc811, *pte=00000000, *ppte=00000000
Internal error: Oops: 807 [#1] SMP ARM
The target address (0xffdefac0) is correct; it's in the range set aside:
#define FIXADDR_START 0xffc00000UL
#define FIXADDR_END 0xffe00000UL
#define FIXADDR_TOP (FIXADDR_END - PAGE_SIZE)
enum fixed_addresses {
/* Support 16 CPUs for kmap as the first region of fixmap entries. */
FIX_KMAP_BEGIN,
FIX_KMAP_END = 15,
/* Support writing RO kernel text via kprobes, jump labels, etc. */
FIX_TEXT_POKE0,
FIX_TEXT_POKE1,
__end_of_fixed_addresses
};
But the resulting PTE is in totally the wrong location as reported by
/sys/kernel/debug/kernel_page_tables:
---[ Fixmap Area ]---
0xfffef000-0xffff0000 4K RW NX SHD MEM/CACHED/WBWA
I continue to dig...
-Kees
--
Kees Cook
Chrome OS Security
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: [PATCH v3 2/2] ARM : change fixmap mapping region to support 32 CPUs
@ 2014-08-06 17:28 ` Kees Cook
0 siblings, 0 replies; 38+ messages in thread
From: Kees Cook @ 2014-08-06 17:28 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Liu hua, Rob Herring, wangnan0, Laura Abbott, peifeiyue,
Will Deacon, linux-kernel@vger.kernel.org, Vitaly Andrianov,
Rabin Vincent, Santosh Shilimkar, liusdu@126.com,
Russell King - ARM Linux, linux-arm-kernel@lists.infradead.org,
Mark Salter
On Wed, Aug 6, 2014 at 10:21 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Wed, 6 Aug 2014, Kees Cook wrote:
>
>> With the original code, there is (I think) a page table entry for the
>> fixmap range. For the latter, there isn't. I see a NULL pgd entry
>> fault when trying to use it, and noticed that this only exists under
>> highmem:
>>
>> static void __init kmap_init(void)
>> {
>> #ifdef CONFIG_HIGHMEM
>> pkmap_page_table = early_pte_alloc(pmd_off_k(PKMAP_BASE),
>> PKMAP_BASE, _PAGE_KERNEL_TABLE);
>>
>> fixmap_page_table = early_pte_alloc(pmd_off_k(FIXADDR_START),
>> FIXADDR_START, _PAGE_KERNEL_TABLE);
>> #endif
>> }
>
> The above is wrong. The fixmap PTEs must be allocated unconditionally
> irrespective of highmem. So the #endif should be moved up by 3 lines.
That's what I was thinking. I tried this, and things are still weird,
though I think I'm narrowing it down. I made the early_pte_alloc
happen, but after boot it doesn't show up in
/sys/kernel/debug/kernel_page_tables. When I attempt a fixmap text
poke, I get this out of dmesg (lkdtm is reporting the address returned
from the patch mapping):
lkdtm: 80421ac0 mapped RW via ffdefac0
Unable to handle kernel paging request at virtual address ffdefac0
pgd = 9e888000
[ffdefac0] *pgd=9fffc811, *pte=00000000, *ppte=00000000
Internal error: Oops: 807 [#1] SMP ARM
The target address (0xffdefac0) is correct; it's in the range set aside:
#define FIXADDR_START 0xffc00000UL
#define FIXADDR_END 0xffe00000UL
#define FIXADDR_TOP (FIXADDR_END - PAGE_SIZE)
enum fixed_addresses {
/* Support 16 CPUs for kmap as the first region of fixmap entries. */
FIX_KMAP_BEGIN,
FIX_KMAP_END = 15,
/* Support writing RO kernel text via kprobes, jump labels, etc. */
FIX_TEXT_POKE0,
FIX_TEXT_POKE1,
__end_of_fixed_addresses
};
But the resulting PTE is in totally the wrong location as reported by
/sys/kernel/debug/kernel_page_tables:
---[ Fixmap Area ]---
0xfffef000-0xffff0000 4K RW NX SHD MEM/CACHED/WBWA
I continue to dig...
-Kees
--
Kees Cook
Chrome OS Security
^ permalink raw reply [flat|nested] 38+ messages in thread* [PATCH v3 2/2] ARM : change fixmap mapping region to support 32 CPUs
2014-08-06 17:28 ` Kees Cook
@ 2014-08-06 22:16 ` Russell King - ARM Linux
-1 siblings, 0 replies; 38+ messages in thread
From: Russell King - ARM Linux @ 2014-08-06 22:16 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Aug 06, 2014 at 10:28:37AM -0700, Kees Cook wrote:
> That's what I was thinking. I tried this, and things are still weird,
> though I think I'm narrowing it down. I made the early_pte_alloc
> happen, but after boot it doesn't show up in
> /sys/kernel/debug/kernel_page_tables. When I attempt a fixmap text
> poke, I get this out of dmesg (lkdtm is reporting the address returned
> from the patch mapping):
>
> lkdtm: 80421ac0 mapped RW via ffdefac0
> Unable to handle kernel paging request at virtual address ffdefac0
> pgd = 9e888000
> [ffdefac0] *pgd=9fffc811, *pte=00000000, *ppte=00000000
> Internal error: Oops: 807 [#1] SMP ARM
>
> The target address (0xffdefac0) is correct; it's in the range set aside:
>
> #define FIXADDR_START 0xffc00000UL
> #define FIXADDR_END 0xffe00000UL
> #define FIXADDR_TOP (FIXADDR_END - PAGE_SIZE)
>
> enum fixed_addresses {
> /* Support 16 CPUs for kmap as the first region of fixmap entries. */
> FIX_KMAP_BEGIN,
> FIX_KMAP_END = 15,
>
> /* Support writing RO kernel text via kprobes, jump labels, etc. */
> FIX_TEXT_POKE0,
> FIX_TEXT_POKE1,
>
> __end_of_fixed_addresses
> };
>
> But the resulting PTE is in totally the wrong location as reported by
> /sys/kernel/debug/kernel_page_tables:
>
> ---[ Fixmap Area ]---
> 0xfffef000-0xffff0000 4K RW NX SHD MEM/CACHED/WBWA
>
> I continue to dig...
This sounds like you have an erroneous merge conflict resolution. You
seem to be poking into TOP_PTE rather than fixmap_page_table.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: [PATCH v3 2/2] ARM : change fixmap mapping region to support 32 CPUs
@ 2014-08-06 22:16 ` Russell King - ARM Linux
0 siblings, 0 replies; 38+ messages in thread
From: Russell King - ARM Linux @ 2014-08-06 22:16 UTC (permalink / raw)
To: Kees Cook
Cc: Nicolas Pitre, Liu hua, Rob Herring, wangnan0, Laura Abbott,
peifeiyue, Will Deacon, linux-kernel@vger.kernel.org,
Vitaly Andrianov, Rabin Vincent, Santosh Shilimkar,
liusdu@126.com, linux-arm-kernel@lists.infradead.org, Mark Salter
On Wed, Aug 06, 2014 at 10:28:37AM -0700, Kees Cook wrote:
> That's what I was thinking. I tried this, and things are still weird,
> though I think I'm narrowing it down. I made the early_pte_alloc
> happen, but after boot it doesn't show up in
> /sys/kernel/debug/kernel_page_tables. When I attempt a fixmap text
> poke, I get this out of dmesg (lkdtm is reporting the address returned
> from the patch mapping):
>
> lkdtm: 80421ac0 mapped RW via ffdefac0
> Unable to handle kernel paging request at virtual address ffdefac0
> pgd = 9e888000
> [ffdefac0] *pgd=9fffc811, *pte=00000000, *ppte=00000000
> Internal error: Oops: 807 [#1] SMP ARM
>
> The target address (0xffdefac0) is correct; it's in the range set aside:
>
> #define FIXADDR_START 0xffc00000UL
> #define FIXADDR_END 0xffe00000UL
> #define FIXADDR_TOP (FIXADDR_END - PAGE_SIZE)
>
> enum fixed_addresses {
> /* Support 16 CPUs for kmap as the first region of fixmap entries. */
> FIX_KMAP_BEGIN,
> FIX_KMAP_END = 15,
>
> /* Support writing RO kernel text via kprobes, jump labels, etc. */
> FIX_TEXT_POKE0,
> FIX_TEXT_POKE1,
>
> __end_of_fixed_addresses
> };
>
> But the resulting PTE is in totally the wrong location as reported by
> /sys/kernel/debug/kernel_page_tables:
>
> ---[ Fixmap Area ]---
> 0xfffef000-0xffff0000 4K RW NX SHD MEM/CACHED/WBWA
>
> I continue to dig...
This sounds like you have an erroneous merge conflict resolution. You
seem to be poking into TOP_PTE rather than fixmap_page_table.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 38+ messages in thread* [PATCH v3 2/2] ARM : change fixmap mapping region to support 32 CPUs
2014-08-06 22:16 ` Russell King - ARM Linux
@ 2014-08-06 23:22 ` Kees Cook
-1 siblings, 0 replies; 38+ messages in thread
From: Kees Cook @ 2014-08-06 23:22 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Aug 6, 2014 at 3:16 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Aug 06, 2014 at 10:28:37AM -0700, Kees Cook wrote:
>> That's what I was thinking. I tried this, and things are still weird,
>> though I think I'm narrowing it down. I made the early_pte_alloc
>> happen, but after boot it doesn't show up in
>> /sys/kernel/debug/kernel_page_tables. When I attempt a fixmap text
>> poke, I get this out of dmesg (lkdtm is reporting the address returned
>> from the patch mapping):
>>
>> lkdtm: 80421ac0 mapped RW via ffdefac0
>> Unable to handle kernel paging request at virtual address ffdefac0
>> pgd = 9e888000
>> [ffdefac0] *pgd=9fffc811, *pte=00000000, *ppte=00000000
>> Internal error: Oops: 807 [#1] SMP ARM
>>
>> The target address (0xffdefac0) is correct; it's in the range set aside:
>>
>> #define FIXADDR_START 0xffc00000UL
>> #define FIXADDR_END 0xffe00000UL
>> #define FIXADDR_TOP (FIXADDR_END - PAGE_SIZE)
>>
>> enum fixed_addresses {
>> /* Support 16 CPUs for kmap as the first region of fixmap entries. */
>> FIX_KMAP_BEGIN,
>> FIX_KMAP_END = 15,
>>
>> /* Support writing RO kernel text via kprobes, jump labels, etc. */
>> FIX_TEXT_POKE0,
>> FIX_TEXT_POKE1,
>>
>> __end_of_fixed_addresses
>> };
>>
>> But the resulting PTE is in totally the wrong location as reported by
>> /sys/kernel/debug/kernel_page_tables:
>>
>> ---[ Fixmap Area ]---
>> 0xfffef000-0xffff0000 4K RW NX SHD MEM/CACHED/WBWA
>>
>> I continue to dig...
>
> This sounds like you have an erroneous merge conflict resolution. You
> seem to be poking into TOP_PTE rather than fixmap_page_table.
Yeah, agreed. This did turn out to be the issue, so I reworked the
set_fixmap routine to aim at the correct pte. The result seems to
work, so I after retesting everything, I sent the series out. So
close! :)
-Kees
--
Kees Cook
Chrome OS Security
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: [PATCH v3 2/2] ARM : change fixmap mapping region to support 32 CPUs
@ 2014-08-06 23:22 ` Kees Cook
0 siblings, 0 replies; 38+ messages in thread
From: Kees Cook @ 2014-08-06 23:22 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Nicolas Pitre, Liu hua, Rob Herring, wangnan0, Laura Abbott,
peifeiyue, Will Deacon, linux-kernel@vger.kernel.org,
Vitaly Andrianov, Rabin Vincent, Santosh Shilimkar,
liusdu@126.com, linux-arm-kernel@lists.infradead.org, Mark Salter
On Wed, Aug 6, 2014 at 3:16 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Aug 06, 2014 at 10:28:37AM -0700, Kees Cook wrote:
>> That's what I was thinking. I tried this, and things are still weird,
>> though I think I'm narrowing it down. I made the early_pte_alloc
>> happen, but after boot it doesn't show up in
>> /sys/kernel/debug/kernel_page_tables. When I attempt a fixmap text
>> poke, I get this out of dmesg (lkdtm is reporting the address returned
>> from the patch mapping):
>>
>> lkdtm: 80421ac0 mapped RW via ffdefac0
>> Unable to handle kernel paging request at virtual address ffdefac0
>> pgd = 9e888000
>> [ffdefac0] *pgd=9fffc811, *pte=00000000, *ppte=00000000
>> Internal error: Oops: 807 [#1] SMP ARM
>>
>> The target address (0xffdefac0) is correct; it's in the range set aside:
>>
>> #define FIXADDR_START 0xffc00000UL
>> #define FIXADDR_END 0xffe00000UL
>> #define FIXADDR_TOP (FIXADDR_END - PAGE_SIZE)
>>
>> enum fixed_addresses {
>> /* Support 16 CPUs for kmap as the first region of fixmap entries. */
>> FIX_KMAP_BEGIN,
>> FIX_KMAP_END = 15,
>>
>> /* Support writing RO kernel text via kprobes, jump labels, etc. */
>> FIX_TEXT_POKE0,
>> FIX_TEXT_POKE1,
>>
>> __end_of_fixed_addresses
>> };
>>
>> But the resulting PTE is in totally the wrong location as reported by
>> /sys/kernel/debug/kernel_page_tables:
>>
>> ---[ Fixmap Area ]---
>> 0xfffef000-0xffff0000 4K RW NX SHD MEM/CACHED/WBWA
>>
>> I continue to dig...
>
> This sounds like you have an erroneous merge conflict resolution. You
> seem to be poking into TOP_PTE rather than fixmap_page_table.
Yeah, agreed. This did turn out to be the issue, so I reworked the
set_fixmap routine to aim at the correct pte. The result seems to
work, so I after retesting everything, I sent the series out. So
close! :)
-Kees
--
Kees Cook
Chrome OS Security
^ permalink raw reply [flat|nested] 38+ messages in thread