[PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

** The initial solution.
The easier solution is to update the bootmem APIs semantics to use
phys_addr_t which makes things works but needs to update almost
all bootmem API semantics and the changes were too intrusive. Many suggested
to use memblock.

** NO_BOOTMEM is suppose to be memblock

- Initially started with the assumption that NO_BOOTMEM can work easily on ARM.
- It does actually work on 32 bit machines nicely..
- But doesn't for LPAE for obvious reason of bootmem.h API signatures truncates
the addresses.

** So I tried to remove BOOTMEM and NO_BOOTMEM dependency for ARM (read 32 bit arch)

- Started replacing bootmem_* usage with dirty hacked memblock based API.
This can be letter wrapped with only needed parameter export.
- Couple of ARM related patch-ups were fine but soon realized that we need
to patch generic kernel multiple places .. So decided to stop and check again
These changes are becoming too much...

So I need to hear back again from folks who has been involved in the discussion
in past. Am sending the email with changes just to explain the idea and issues
o.w patch as such is crappy.

Thanks for help

Cc: Tejun Heo <tj@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
---
 arch/arm/kernel/devtree.c |    2 +-
 arch/arm/kernel/setup.c   |    2 +-
 include/linux/bootmem.h   |    2 ++
 init/main.c               |    4 ++--
 mm/nobootmem.c            |    2 +-
 mm/percpu.c               |    4 ++--
 6 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 5af04f6..720b9f9 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -33,7 +33,7 @@ void __init early_init_dt_add_memory_arch(u64 base, u64 size)
 
 void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
 {
-	return alloc_bootmem_align(size, align);
+	return __alloc_memory_core_early(MAX_NUMNODES, size, align, 0, ARCH_LOW_ADDRESS_LIMIT);
 }
 
 void __init arm_dt_memblock_reserve(void)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 385131c..57698ed 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -619,7 +619,7 @@ static void __init request_standard_resources(struct machine_desc *mdesc)
 	kernel_data.end     = virt_to_phys(_end - 1);
 
 	for_each_memblock(memory, region) {
-		res = alloc_bootmem_low(sizeof(*res));
+		res = __alloc_memory_core_early(MAX_NUMNODES, sizeof(*res), SMP_CACHE_BYTES, 0, ARCH_LOW_ADDRESS_LIMIT);
 		res->name  = "System RAM";
 		res->start = __pfn_to_phys(memblock_region_memory_base_pfn(region));
 		res->end = __pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1;
diff --git a/include/linux/bootmem.h b/include/linux/bootmem.h
index 5f0b0e1..a916df6 100644
--- a/include/linux/bootmem.h
+++ b/include/linux/bootmem.h
@@ -142,6 +142,8 @@ extern void *__alloc_bootmem_low_node(pg_data_t *pgdat,
 #define alloc_bootmem_low_pages_node(pgdat, x) \
 	__alloc_bootmem_low_node(pgdat, x, PAGE_SIZE, 0)
 
+extern void * __init __alloc_memory_core_early(int nid, u64 size, u64 align,
+					u64 goal, u64 limit);
 #ifdef CONFIG_HAVE_ARCH_ALLOC_REMAP
 extern void *alloc_remap(int nid, unsigned long size);
 #else
diff --git a/init/main.c b/init/main.c
index 9484f4b..53c488d 100644
--- a/init/main.c
+++ b/init/main.c
@@ -344,8 +344,8 @@ static inline void smp_prepare_cpus(unsigned int maxcpus) { }
  */
 static void __init setup_command_line(char *command_line)
 {
-	saved_command_line = alloc_bootmem(strlen (boot_command_line)+1);
-	static_command_line = alloc_bootmem(strlen (command_line)+1);
+	saved_command_line =__alloc_memory_core_early(MAX_NUMNODES, (strlen (boot_command_line)+1), SMP_CACHE_BYTES, 0, ARCH_LOW_ADDRESS_LIMIT);
+	static_command_line =__alloc_memory_core_early(MAX_NUMNODES, (strlen (command_line)+1), SMP_CACHE_BYTES, 0, ARCH_LOW_ADDRESS_LIMIT);
 	strcpy (saved_command_line, boot_command_line);
 	strcpy (static_command_line, command_line);
 }
diff --git a/mm/nobootmem.c b/mm/nobootmem.c
index bdd3fa2..43a2f95 100644
--- a/mm/nobootmem.c
+++ b/mm/nobootmem.c
@@ -32,7 +32,7 @@ unsigned long max_low_pfn;
 unsigned long min_low_pfn;
 unsigned long max_pfn;
 
-static void * __init __alloc_memory_core_early(int nid, u64 size, u64 align,
+void * __init __alloc_memory_core_early(int nid, u64 size, u64 align,
 					u64 goal, u64 limit)
 {
 	void *ptr;
diff --git a/mm/percpu.c b/mm/percpu.c
index 8c8e08f..30cd3df 100644
--- a/mm/percpu.c
+++ b/mm/percpu.c
@@ -1063,7 +1063,7 @@ struct pcpu_alloc_info * __init pcpu_alloc_alloc_info(int nr_groups,
 			  __alignof__(ai->groups[0].cpu_map[0]));
 	ai_size = base_size + nr_units * sizeof(ai->groups[0].cpu_map[0]);
 
-	ptr = alloc_bootmem_nopanic(PFN_ALIGN(ai_size));
+	ptr = __alloc_memory_core_early(MAX_NUMNODES, PFN_ALIGN(ai_size), SMP_CACHE_BYTES, 0, ARCH_LOW_ADDRESS_LIMIT);
 	if (!ptr)
 		return NULL;
 	ai = ptr;
@@ -1895,7 +1895,7 @@ void __init setup_per_cpu_areas(void)
 	void *fc;
 
 	ai = pcpu_alloc_alloc_info(1, 1);
-	fc = __alloc_bootmem(unit_size, PAGE_SIZE, __pa(MAX_DMA_ADDRESS));
+	fc = __alloc_memory_core_early(MAX_NUMNODES, unit_size, PAGE_SIZE, __pa(MAX_DMA_ADDRESS), ARCH_LOW_ADDRESS_LIMIT);
 	if (!ai || !fc)
 		panic("Failed to allocate memory for percpu areas.");
 	/* kmemleak tracks the percpu allocations separately */
-- 
1.7.9.5

[PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

** The initial solution.
The easier solution is to update the bootmem APIs semantics to use
phys_addr_t which makes things works but needs to update almost
all bootmem API semantics and the changes were too intrusive. Many suggested
to use memblock.

** NO_BOOTMEM is suppose to be memblock

- Initially started with the assumption that NO_BOOTMEM can work easily on ARM.
- It does actually work on 32 bit machines nicely..
- But doesn't for LPAE for obvious reason of bootmem.h API signatures truncates
the addresses.

** So I tried to remove BOOTMEM and NO_BOOTMEM dependency for ARM (read 32 bit arch)

- Started replacing bootmem_* usage with dirty hacked memblock based API.
This can be letter wrapped with only needed parameter export.
- Couple of ARM related patch-ups were fine but soon realized that we need
to patch generic kernel multiple places .. So decided to stop and check again
These changes are becoming too much...

So I need to hear back again from folks who has been involved in the discussion
in past. Am sending the email with changes just to explain the idea and issues
o.w patch as such is crappy.

Thanks for help

Cc: Tejun Heo <tj@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
---
 arch/arm/kernel/devtree.c |    2 +-
 arch/arm/kernel/setup.c   |    2 +-
 include/linux/bootmem.h   |    2 ++
 init/main.c               |    4 ++--
 mm/nobootmem.c            |    2 +-
 mm/percpu.c               |    4 ++--
 6 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 5af04f6..720b9f9 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -33,7 +33,7 @@ void __init early_init_dt_add_memory_arch(u64 base, u64 size)
 
 void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
 {
-	return alloc_bootmem_align(size, align);
+	return __alloc_memory_core_early(MAX_NUMNODES, size, align, 0, ARCH_LOW_ADDRESS_LIMIT);
 }
 
 void __init arm_dt_memblock_reserve(void)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 385131c..57698ed 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -619,7 +619,7 @@ static void __init request_standard_resources(struct machine_desc *mdesc)
 	kernel_data.end     = virt_to_phys(_end - 1);
 
 	for_each_memblock(memory, region) {
-		res = alloc_bootmem_low(sizeof(*res));
+		res = __alloc_memory_core_early(MAX_NUMNODES, sizeof(*res), SMP_CACHE_BYTES, 0, ARCH_LOW_ADDRESS_LIMIT);
 		res->name  = "System RAM";
 		res->start = __pfn_to_phys(memblock_region_memory_base_pfn(region));
 		res->end = __pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1;
diff --git a/include/linux/bootmem.h b/include/linux/bootmem.h
index 5f0b0e1..a916df6 100644
--- a/include/linux/bootmem.h
+++ b/include/linux/bootmem.h
@@ -142,6 +142,8 @@ extern void *__alloc_bootmem_low_node(pg_data_t *pgdat,
 #define alloc_bootmem_low_pages_node(pgdat, x) \
 	__alloc_bootmem_low_node(pgdat, x, PAGE_SIZE, 0)
 
+extern void * __init __alloc_memory_core_early(int nid, u64 size, u64 align,
+					u64 goal, u64 limit);
 #ifdef CONFIG_HAVE_ARCH_ALLOC_REMAP
 extern void *alloc_remap(int nid, unsigned long size);
 #else
diff --git a/init/main.c b/init/main.c
index 9484f4b..53c488d 100644
--- a/init/main.c
+++ b/init/main.c
@@ -344,8 +344,8 @@ static inline void smp_prepare_cpus(unsigned int maxcpus) { }
  */
 static void __init setup_command_line(char *command_line)
 {
-	saved_command_line = alloc_bootmem(strlen (boot_command_line)+1);
-	static_command_line = alloc_bootmem(strlen (command_line)+1);
+	saved_command_line =__alloc_memory_core_early(MAX_NUMNODES, (strlen (boot_command_line)+1), SMP_CACHE_BYTES, 0, ARCH_LOW_ADDRESS_LIMIT);
+	static_command_line =__alloc_memory_core_early(MAX_NUMNODES, (strlen (command_line)+1), SMP_CACHE_BYTES, 0, ARCH_LOW_ADDRESS_LIMIT);
 	strcpy (saved_command_line, boot_command_line);
 	strcpy (static_command_line, command_line);
 }
diff --git a/mm/nobootmem.c b/mm/nobootmem.c
index bdd3fa2..43a2f95 100644
--- a/mm/nobootmem.c
+++ b/mm/nobootmem.c
@@ -32,7 +32,7 @@ unsigned long max_low_pfn;
 unsigned long min_low_pfn;
 unsigned long max_pfn;
 
-static void * __init __alloc_memory_core_early(int nid, u64 size, u64 align,
+void * __init __alloc_memory_core_early(int nid, u64 size, u64 align,
 					u64 goal, u64 limit)
 {
 	void *ptr;
diff --git a/mm/percpu.c b/mm/percpu.c
index 8c8e08f..30cd3df 100644
--- a/mm/percpu.c
+++ b/mm/percpu.c
@@ -1063,7 +1063,7 @@ struct pcpu_alloc_info * __init pcpu_alloc_alloc_info(int nr_groups,
 			  __alignof__(ai->groups[0].cpu_map[0]));
 	ai_size = base_size + nr_units * sizeof(ai->groups[0].cpu_map[0]);
 
-	ptr = alloc_bootmem_nopanic(PFN_ALIGN(ai_size));
+	ptr = __alloc_memory_core_early(MAX_NUMNODES, PFN_ALIGN(ai_size), SMP_CACHE_BYTES, 0, ARCH_LOW_ADDRESS_LIMIT);
 	if (!ptr)
 		return NULL;
 	ai = ptr;
@@ -1895,7 +1895,7 @@ void __init setup_per_cpu_areas(void)
 	void *fc;
 
 	ai = pcpu_alloc_alloc_info(1, 1);
-	fc = __alloc_bootmem(unit_size, PAGE_SIZE, __pa(MAX_DMA_ADDRESS));
+	fc = __alloc_memory_core_early(MAX_NUMNODES, unit_size, PAGE_SIZE, __pa(MAX_DMA_ADDRESS), ARCH_LOW_ADDRESS_LIMIT);
 	if (!ai || !fc)
 		panic("Failed to allocate memory for percpu areas.");
 	/* kmemleak tracks the percpu allocations separately */
-- 
1.7.9.5

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Tejun Heo]

Hello,

I haven't looked at bootmem for a while so could be a bit out of touch
but a couple questions.

On Fri, Jun 28, 2013 at 09:01:03PM -0400, Santosh Shilimkar wrote:
> - Started replacing bootmem_* usage with dirty hacked memblock based API.
> This can be letter wrapped with only needed parameter export.

You can't use memblock directly?

> - Couple of ARM related patch-ups were fine but soon realized that we need
> to patch generic kernel multiple places .. So decided to stop and check again
> These changes are becoming too much...

I suppose LPAE on arm is analogous to PAE on x86, IOW, high memory?
This does affect memory initilization as you need to register memory
areas which aren't addressable directly; however, why does it affect
generic code which is just allocating memory?  Note that x86 already
does highmem and the existing code works fine.  Once all bootmem users
are gone, we can remove the bootmem wrappers but I don't what the
point is with introducing yet another wrapper.

Thanks.

-- 
tejun

[PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Tejun Heo]

Hello,

I haven't looked at bootmem for a while so could be a bit out of touch
but a couple questions.

On Fri, Jun 28, 2013 at 09:01:03PM -0400, Santosh Shilimkar wrote:
> - Started replacing bootmem_* usage with dirty hacked memblock based API.
> This can be letter wrapped with only needed parameter export.

You can't use memblock directly?

> - Couple of ARM related patch-ups were fine but soon realized that we need
> to patch generic kernel multiple places .. So decided to stop and check again
> These changes are becoming too much...

I suppose LPAE on arm is analogous to PAE on x86, IOW, high memory?
This does affect memory initilization as you need to register memory
areas which aren't addressable directly; however, why does it affect
generic code which is just allocating memory?  Note that x86 already
does highmem and the existing code works fine.  Once all bootmem users
are gone, we can remove the bootmem wrappers but I don't what the
point is with introducing yet another wrapper.

Thanks.

-- 
tejun

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Russell King - ARM Linux]

On Sat, Jun 29, 2013 at 08:29:59AM -0700, Tejun Heo wrote:
> I suppose LPAE on arm is analogous to PAE on x86, IOW, high memory?
> This does affect memory initilization as you need to register memory
> areas which aren't addressable directly; however, why does it affect
> generic code which is just allocating memory?  Note that x86 already
> does highmem and the existing code works fine.  Once all bootmem users
> are gone, we can remove the bootmem wrappers but I don't what the
> point is with introducing yet another wrapper.

The reason is actually quite simple: on x86 you always have memory
starting at physical address zero.

Unfortunately, that has not been true on ARM - it's very common for
there to be an offset on physical memory, sometimes of the order of
3GB or more.  This is because on reset, ARMs start executing the code
at physical address zero, which therefore can't be RAM - and there's
a desire to avoid complex switching games in hardware to temporarily
map ROM there instead of RAM.

On these SoCs which Santosh is working on, the main physical memory
mapping is above 4GB, with just a small alias below 4GB to allow the
system to boot without the MMU being on, as they may have more than
4GB of RAM.  As I understand it, the small alias below 4GB is not
suitable for use as a "lowmem" mapping.

[PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Russell King - ARM Linux]

On Sat, Jun 29, 2013 at 08:29:59AM -0700, Tejun Heo wrote:
> I suppose LPAE on arm is analogous to PAE on x86, IOW, high memory?
> This does affect memory initilization as you need to register memory
> areas which aren't addressable directly; however, why does it affect
> generic code which is just allocating memory?  Note that x86 already
> does highmem and the existing code works fine.  Once all bootmem users
> are gone, we can remove the bootmem wrappers but I don't what the
> point is with introducing yet another wrapper.

The reason is actually quite simple: on x86 you always have memory
starting at physical address zero.

Unfortunately, that has not been true on ARM - it's very common for
there to be an offset on physical memory, sometimes of the order of
3GB or more.  This is because on reset, ARMs start executing the code
at physical address zero, which therefore can't be RAM - and there's
a desire to avoid complex switching games in hardware to temporarily
map ROM there instead of RAM.

On these SoCs which Santosh is working on, the main physical memory
mapping is above 4GB, with just a small alias below 4GB to allow the
system to boot without the MMU being on, as they may have more than
4GB of RAM.  As I understand it, the small alias below 4GB is not
suitable for use as a "lowmem" mapping.

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Tejun Heo]

( Expanding cc list, original thread is at
  http://thread.gmane.org/gmane.linux.kernel/1518046 )

Hello,

On Sat, Jun 29, 2013 at 06:21:24PM +0100, Russell King - ARM Linux wrote:
> Unfortunately, that has not been true on ARM - it's very common for
> there to be an offset on physical memory, sometimes of the order of
> 3GB or more.  This is because on reset, ARMs start executing the code
> at physical address zero, which therefore can't be RAM - and there's
> a desire to avoid complex switching games in hardware to temporarily
> map ROM there instead of RAM.
> 
> On these SoCs which Santosh is working on, the main physical memory
> mapping is above 4GB, with just a small alias below 4GB to allow the
> system to boot without the MMU being on, as they may have more than
> 4GB of RAM.  As I understand it, the small alias below 4GB is not
> suitable for use as a "lowmem" mapping.

Ah, okay, so the @limit which is in physical address can be over 4GB
even for lowmem mappings and alloc_bootmem takes them in ulongs,
urghhh....

Given that still about half of the archs aren't using memblock yet, I
think there are three options.

1. Converting all bootmem interface to use physaddr_t.  But that's
   what memblock is.

2. Introducing new interface.  Easier right now but the danger there
   is that it might end up duplicating most of alloc_bootmem()
   interface anyway and we'll have yet another variant of early mem
   allocator to enjoy.

3. Make all generic code use memblock interface instead of bootmem and
   implement memblock wrapper on archs which don't use memblock yet.
   We'll probably need to sort out different combinations of
   HAVE_MEMBLOCK and NO_BOOTMEM.  If this is doable, it probably is
   the most future proof way.  While it adds new memblock interface
   built on top of bootmem, it would also allow removing the bootmem
   interface built on top of memblock - ie. nobootmem.c, which
   probably is what we should have done from the beginning.

What do you guys think?

Thanks.

-- 
tejun

[PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Tejun Heo]

( Expanding cc list, original thread is at
  http://thread.gmane.org/gmane.linux.kernel/1518046 )

Hello,

On Sat, Jun 29, 2013 at 06:21:24PM +0100, Russell King - ARM Linux wrote:
> Unfortunately, that has not been true on ARM - it's very common for
> there to be an offset on physical memory, sometimes of the order of
> 3GB or more.  This is because on reset, ARMs start executing the code
> at physical address zero, which therefore can't be RAM - and there's
> a desire to avoid complex switching games in hardware to temporarily
> map ROM there instead of RAM.
> 
> On these SoCs which Santosh is working on, the main physical memory
> mapping is above 4GB, with just a small alias below 4GB to allow the
> system to boot without the MMU being on, as they may have more than
> 4GB of RAM.  As I understand it, the small alias below 4GB is not
> suitable for use as a "lowmem" mapping.

Ah, okay, so the @limit which is in physical address can be over 4GB
even for lowmem mappings and alloc_bootmem takes them in ulongs,
urghhh....

Given that still about half of the archs aren't using memblock yet, I
think there are three options.

1. Converting all bootmem interface to use physaddr_t.  But that's
   what memblock is.

2. Introducing new interface.  Easier right now but the danger there
   is that it might end up duplicating most of alloc_bootmem()
   interface anyway and we'll have yet another variant of early mem
   allocator to enjoy.

3. Make all generic code use memblock interface instead of bootmem and
   implement memblock wrapper on archs which don't use memblock yet.
   We'll probably need to sort out different combinations of
   HAVE_MEMBLOCK and NO_BOOTMEM.  If this is doable, it probably is
   the most future proof way.  While it adds new memblock interface
   built on top of bootmem, it would also allow removing the bootmem
   interface built on top of memblock - ie. nobootmem.c, which
   probably is what we should have done from the beginning.

What do you guys think?

Thanks.

-- 
tejun

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Tejun Heo]

( Expanding cc list, original thread is at
  http://thread.gmane.org/gmane.linux.kernel/1518046 )

Hello,

On Sat, Jun 29, 2013 at 06:21:24PM +0100, Russell King - ARM Linux wrote:
> Unfortunately, that has not been true on ARM - it's very common for
> there to be an offset on physical memory, sometimes of the order of
> 3GB or more.  This is because on reset, ARMs start executing the code
> at physical address zero, which therefore can't be RAM - and there's
> a desire to avoid complex switching games in hardware to temporarily
> map ROM there instead of RAM.
> 
> On these SoCs which Santosh is working on, the main physical memory
> mapping is above 4GB, with just a small alias below 4GB to allow the
> system to boot without the MMU being on, as they may have more than
> 4GB of RAM.  As I understand it, the small alias below 4GB is not
> suitable for use as a "lowmem" mapping.

Ah, okay, so the @limit which is in physical address can be over 4GB
even for lowmem mappings and alloc_bootmem takes them in ulongs,
urghhh....

Given that still about half of the archs aren't using memblock yet, I
think there are three options.

1. Converting all bootmem interface to use physaddr_t.  But that's
   what memblock is.

2. Introducing new interface.  Easier right now but the danger there
   is that it might end up duplicating most of alloc_bootmem()
   interface anyway and we'll have yet another variant of early mem
   allocator to enjoy.

3. Make all generic code use memblock interface instead of bootmem and
   implement memblock wrapper on archs which don't use memblock yet.
   We'll probably need to sort out different combinations of
   HAVE_MEMBLOCK and NO_BOOTMEM.  If this is doable, it probably is
   the most future proof way.  While it adds new memblock interface
   built on top of bootmem, it would also allow removing the bootmem
   interface built on top of memblock - ie. nobootmem.c, which
   probably is what we should have done from the beginning.

What do you guys think?

Thanks.

-- 
tejun

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[H. Peter Anvin]

3 makes sense to me.

Tejun Heo <tj@kernel.org> wrote:

>( Expanding cc list, original thread is at
>  http://thread.gmane.org/gmane.linux.kernel/1518046 )
>
>Hello,
>
>On Sat, Jun 29, 2013 at 06:21:24PM +0100, Russell King - ARM Linux
>wrote:
>> Unfortunately, that has not been true on ARM - it's very common for
>> there to be an offset on physical memory, sometimes of the order of
>> 3GB or more.  This is because on reset, ARMs start executing the code
>> at physical address zero, which therefore can't be RAM - and there's
>> a desire to avoid complex switching games in hardware to temporarily
>> map ROM there instead of RAM.
>> 
>> On these SoCs which Santosh is working on, the main physical memory
>> mapping is above 4GB, with just a small alias below 4GB to allow the
>> system to boot without the MMU being on, as they may have more than
>> 4GB of RAM.  As I understand it, the small alias below 4GB is not
>> suitable for use as a "lowmem" mapping.
>
>Ah, okay, so the @limit which is in physical address can be over 4GB
>even for lowmem mappings and alloc_bootmem takes them in ulongs,
>urghhh....
>
>Given that still about half of the archs aren't using memblock yet, I
>think there are three options.
>
>1. Converting all bootmem interface to use physaddr_t.  But that's
>   what memblock is.
>
>2. Introducing new interface.  Easier right now but the danger there
>   is that it might end up duplicating most of alloc_bootmem()
>   interface anyway and we'll have yet another variant of early mem
>   allocator to enjoy.
>
>3. Make all generic code use memblock interface instead of bootmem and
>   implement memblock wrapper on archs which don't use memblock yet.
>   We'll probably need to sort out different combinations of
>   HAVE_MEMBLOCK and NO_BOOTMEM.  If this is doable, it probably is
>   the most future proof way.  While it adds new memblock interface
>   built on top of bootmem, it would also allow removing the bootmem
>   interface built on top of memblock - ie. nobootmem.c, which
>   probably is what we should have done from the beginning.
>
>What do you guys think?
>
>Thanks.

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.

[PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[H. Peter Anvin]

3 makes sense to me.

Tejun Heo <tj@kernel.org> wrote:

>( Expanding cc list, original thread is at
>  http://thread.gmane.org/gmane.linux.kernel/1518046 )
>
>Hello,
>
>On Sat, Jun 29, 2013 at 06:21:24PM +0100, Russell King - ARM Linux
>wrote:
>> Unfortunately, that has not been true on ARM - it's very common for
>> there to be an offset on physical memory, sometimes of the order of
>> 3GB or more.  This is because on reset, ARMs start executing the code
>> at physical address zero, which therefore can't be RAM - and there's
>> a desire to avoid complex switching games in hardware to temporarily
>> map ROM there instead of RAM.
>> 
>> On these SoCs which Santosh is working on, the main physical memory
>> mapping is above 4GB, with just a small alias below 4GB to allow the
>> system to boot without the MMU being on, as they may have more than
>> 4GB of RAM.  As I understand it, the small alias below 4GB is not
>> suitable for use as a "lowmem" mapping.
>
>Ah, okay, so the @limit which is in physical address can be over 4GB
>even for lowmem mappings and alloc_bootmem takes them in ulongs,
>urghhh....
>
>Given that still about half of the archs aren't using memblock yet, I
>think there are three options.
>
>1. Converting all bootmem interface to use physaddr_t.  But that's
>   what memblock is.
>
>2. Introducing new interface.  Easier right now but the danger there
>   is that it might end up duplicating most of alloc_bootmem()
>   interface anyway and we'll have yet another variant of early mem
>   allocator to enjoy.
>
>3. Make all generic code use memblock interface instead of bootmem and
>   implement memblock wrapper on archs which don't use memblock yet.
>   We'll probably need to sort out different combinations of
>   HAVE_MEMBLOCK and NO_BOOTMEM.  If this is doable, it probably is
>   the most future proof way.  While it adds new memblock interface
>   built on top of bootmem, it would also allow removing the bootmem
>   interface built on top of memblock - ie. nobootmem.c, which
>   probably is what we should have done from the beginning.
>
>What do you guys think?
>
>Thanks.

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[H. Peter Anvin]

3 makes sense to me.

Tejun Heo <tj@kernel.org> wrote:

>( Expanding cc list, original thread is at
>  http://thread.gmane.org/gmane.linux.kernel/1518046 )
>
>Hello,
>
>On Sat, Jun 29, 2013 at 06:21:24PM +0100, Russell King - ARM Linux
>wrote:
>> Unfortunately, that has not been true on ARM - it's very common for
>> there to be an offset on physical memory, sometimes of the order of
>> 3GB or more.  This is because on reset, ARMs start executing the code
>> at physical address zero, which therefore can't be RAM - and there's
>> a desire to avoid complex switching games in hardware to temporarily
>> map ROM there instead of RAM.
>> 
>> On these SoCs which Santosh is working on, the main physical memory
>> mapping is above 4GB, with just a small alias below 4GB to allow the
>> system to boot without the MMU being on, as they may have more than
>> 4GB of RAM.  As I understand it, the small alias below 4GB is not
>> suitable for use as a "lowmem" mapping.
>
>Ah, okay, so the @limit which is in physical address can be over 4GB
>even for lowmem mappings and alloc_bootmem takes them in ulongs,
>urghhh....
>
>Given that still about half of the archs aren't using memblock yet, I
>think there are three options.
>
>1. Converting all bootmem interface to use physaddr_t.  But that's
>   what memblock is.
>
>2. Introducing new interface.  Easier right now but the danger there
>   is that it might end up duplicating most of alloc_bootmem()
>   interface anyway and we'll have yet another variant of early mem
>   allocator to enjoy.
>
>3. Make all generic code use memblock interface instead of bootmem and
>   implement memblock wrapper on archs which don't use memblock yet.
>   We'll probably need to sort out different combinations of
>   HAVE_MEMBLOCK and NO_BOOTMEM.  If this is doable, it probably is
>   the most future proof way.  While it adds new memblock interface
>   built on top of bootmem, it would also allow removing the bootmem
>   interface built on top of memblock - ie. nobootmem.c, which
>   probably is what we should have done from the beginning.
>
>What do you guys think?
>
>Thanks.

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[H. Peter Anvin]

3 makes sense to me.

Tejun Heo <tj@kernel.org> wrote:

>( Expanding cc list, original thread is at
>  http://thread.gmane.org/gmane.linux.kernel/1518046 )
>
>Hello,
>
>On Sat, Jun 29, 2013 at 06:21:24PM +0100, Russell King - ARM Linux
>wrote:
>> Unfortunately, that has not been true on ARM - it's very common for
>> there to be an offset on physical memory, sometimes of the order of
>> 3GB or more.  This is because on reset, ARMs start executing the code
>> at physical address zero, which therefore can't be RAM - and there's
>> a desire to avoid complex switching games in hardware to temporarily
>> map ROM there instead of RAM.
>> 
>> On these SoCs which Santosh is working on, the main physical memory
>> mapping is above 4GB, with just a small alias below 4GB to allow the
>> system to boot without the MMU being on, as they may have more than
>> 4GB of RAM.  As I understand it, the small alias below 4GB is not
>> suitable for use as a "lowmem" mapping.
>
>Ah, okay, so the @limit which is in physical address can be over 4GB
>even for lowmem mappings and alloc_bootmem takes them in ulongs,
>urghhh....
>
>Given that still about half of the archs aren't using memblock yet, I
>think there are three options.
>
>1. Converting all bootmem interface to use physaddr_t.  But that's
>   what memblock is.
>
>2. Introducing new interface.  Easier right now but the danger there
>   is that it might end up duplicating most of alloc_bootmem()
>   interface anyway and we'll have yet another variant of early mem
>   allocator to enjoy.
>
>3. Make all generic code use memblock interface instead of bootmem and
>   implement memblock wrapper on archs which don't use memblock yet.
>   We'll probably need to sort out different combinations of
>   HAVE_MEMBLOCK and NO_BOOTMEM.  If this is doable, it probably is
>   the most future proof way.  While it adds new memblock interface
>   built on top of bootmem, it would also allow removing the bootmem
>   interface built on top of memblock - ie. nobootmem.c, which
>   probably is what we should have done from the beginning.
>
>What do you guys think?
>
>Thanks.

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Yinghai Lu]

On Sat, Jun 29, 2013 at 10:57 AM, Tejun Heo <tj@kernel.org> wrote:
> ( Expanding cc list, original thread is at
>   http://thread.gmane.org/gmane.linux.kernel/1518046 )
>
> Hello,
>
> On Sat, Jun 29, 2013 at 06:21:24PM +0100, Russell King - ARM Linux wrote:
>> Unfortunately, that has not been true on ARM - it's very common for
>> there to be an offset on physical memory, sometimes of the order of
>> 3GB or more.  This is because on reset, ARMs start executing the code
>> at physical address zero, which therefore can't be RAM - and there's
>> a desire to avoid complex switching games in hardware to temporarily
>> map ROM there instead of RAM.
>>
>> On these SoCs which Santosh is working on, the main physical memory
>> mapping is above 4GB, with just a small alias below 4GB to allow the
>> system to boot without the MMU being on, as they may have more than
>> 4GB of RAM.  As I understand it, the small alias below 4GB is not
>> suitable for use as a "lowmem" mapping.

is that 32bit ARM or 64bit ARM?

>
> Ah, okay, so the @limit which is in physical address can be over 4GB
> even for lowmem mappings and alloc_bootmem takes them in ulongs,
> urghhh....
>
> Given that still about half of the archs aren't using memblock yet, I
> think there are three options.
>
> 1. Converting all bootmem interface to use physaddr_t.  But that's
>    what memblock is.
>
> 2. Introducing new interface.  Easier right now but the danger there
>    is that it might end up duplicating most of alloc_bootmem()
>    interface anyway and we'll have yet another variant of early mem
>    allocator to enjoy.
>
> 3. Make all generic code use memblock interface instead of bootmem and
>    implement memblock wrapper on archs which don't use memblock yet.
>    We'll probably need to sort out different combinations of
>    HAVE_MEMBLOCK and NO_BOOTMEM.  If this is doable, it probably is
>    the most future proof way.  While it adds new memblock interface
>    built on top of bootmem, it would also allow removing the bootmem
>    interface built on top of memblock - ie. nobootmem.c, which
>    probably is what we should have done from the beginning.
>
> What do you guys think?

2. looks more simple.
but will use alloc_memblock as interface.

We don't need to use __alloc_memory_core_early() directly, right?

Thanks

Yinghai

[PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Yinghai Lu]

On Sat, Jun 29, 2013 at 10:57 AM, Tejun Heo <tj@kernel.org> wrote:
> ( Expanding cc list, original thread is at
>   http://thread.gmane.org/gmane.linux.kernel/1518046 )
>
> Hello,
>
> On Sat, Jun 29, 2013 at 06:21:24PM +0100, Russell King - ARM Linux wrote:
>> Unfortunately, that has not been true on ARM - it's very common for
>> there to be an offset on physical memory, sometimes of the order of
>> 3GB or more.  This is because on reset, ARMs start executing the code
>> at physical address zero, which therefore can't be RAM - and there's
>> a desire to avoid complex switching games in hardware to temporarily
>> map ROM there instead of RAM.
>>
>> On these SoCs which Santosh is working on, the main physical memory
>> mapping is above 4GB, with just a small alias below 4GB to allow the
>> system to boot without the MMU being on, as they may have more than
>> 4GB of RAM.  As I understand it, the small alias below 4GB is not
>> suitable for use as a "lowmem" mapping.

is that 32bit ARM or 64bit ARM?

>
> Ah, okay, so the @limit which is in physical address can be over 4GB
> even for lowmem mappings and alloc_bootmem takes them in ulongs,
> urghhh....
>
> Given that still about half of the archs aren't using memblock yet, I
> think there are three options.
>
> 1. Converting all bootmem interface to use physaddr_t.  But that's
>    what memblock is.
>
> 2. Introducing new interface.  Easier right now but the danger there
>    is that it might end up duplicating most of alloc_bootmem()
>    interface anyway and we'll have yet another variant of early mem
>    allocator to enjoy.
>
> 3. Make all generic code use memblock interface instead of bootmem and
>    implement memblock wrapper on archs which don't use memblock yet.
>    We'll probably need to sort out different combinations of
>    HAVE_MEMBLOCK and NO_BOOTMEM.  If this is doable, it probably is
>    the most future proof way.  While it adds new memblock interface
>    built on top of bootmem, it would also allow removing the bootmem
>    interface built on top of memblock - ie. nobootmem.c, which
>    probably is what we should have done from the beginning.
>
> What do you guys think?

2. looks more simple.
but will use alloc_memblock as interface.

We don't need to use __alloc_memory_core_early() directly, right?

Thanks

Yinghai

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Yinghai Lu]

On Sat, Jun 29, 2013 at 10:57 AM, Tejun Heo <tj@kernel.org> wrote:
> ( Expanding cc list, original thread is at
>   http://thread.gmane.org/gmane.linux.kernel/1518046 )
>
> Hello,
>
> On Sat, Jun 29, 2013 at 06:21:24PM +0100, Russell King - ARM Linux wrote:
>> Unfortunately, that has not been true on ARM - it's very common for
>> there to be an offset on physical memory, sometimes of the order of
>> 3GB or more.  This is because on reset, ARMs start executing the code
>> at physical address zero, which therefore can't be RAM - and there's
>> a desire to avoid complex switching games in hardware to temporarily
>> map ROM there instead of RAM.
>>
>> On these SoCs which Santosh is working on, the main physical memory
>> mapping is above 4GB, with just a small alias below 4GB to allow the
>> system to boot without the MMU being on, as they may have more than
>> 4GB of RAM.  As I understand it, the small alias below 4GB is not
>> suitable for use as a "lowmem" mapping.

is that 32bit ARM or 64bit ARM?

>
> Ah, okay, so the @limit which is in physical address can be over 4GB
> even for lowmem mappings and alloc_bootmem takes them in ulongs,
> urghhh....
>
> Given that still about half of the archs aren't using memblock yet, I
> think there are three options.
>
> 1. Converting all bootmem interface to use physaddr_t.  But that's
>    what memblock is.
>
> 2. Introducing new interface.  Easier right now but the danger there
>    is that it might end up duplicating most of alloc_bootmem()
>    interface anyway and we'll have yet another variant of early mem
>    allocator to enjoy.
>
> 3. Make all generic code use memblock interface instead of bootmem and
>    implement memblock wrapper on archs which don't use memblock yet.
>    We'll probably need to sort out different combinations of
>    HAVE_MEMBLOCK and NO_BOOTMEM.  If this is doable, it probably is
>    the most future proof way.  While it adds new memblock interface
>    built on top of bootmem, it would also allow removing the bootmem
>    interface built on top of memblock - ie. nobootmem.c, which
>    probably is what we should have done from the beginning.
>
> What do you guys think?

2. looks more simple.
but will use alloc_memblock as interface.

We don't need to use __alloc_memory_core_early() directly, right?

Thanks

Yinghai

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Russell King - ARM Linux]

On Sat, Jun 29, 2013 at 12:29:55PM -0700, Yinghai Lu wrote:
> On Sat, Jun 29, 2013 at 10:57 AM, Tejun Heo <tj@kernel.org> wrote:
> > ( Expanding cc list, original thread is at
> >   http://thread.gmane.org/gmane.linux.kernel/1518046 )
> >
> > Hello,
> >
> > On Sat, Jun 29, 2013 at 06:21:24PM +0100, Russell King - ARM Linux wrote:
> >> Unfortunately, that has not been true on ARM - it's very common for
> >> there to be an offset on physical memory, sometimes of the order of
> >> 3GB or more.  This is because on reset, ARMs start executing the code
> >> at physical address zero, which therefore can't be RAM - and there's
> >> a desire to avoid complex switching games in hardware to temporarily
> >> map ROM there instead of RAM.
> >>
> >> On these SoCs which Santosh is working on, the main physical memory
> >> mapping is above 4GB, with just a small alias below 4GB to allow the
> >> system to boot without the MMU being on, as they may have more than
> >> 4GB of RAM.  As I understand it, the small alias below 4GB is not
> >> suitable for use as a "lowmem" mapping.
> 
> is that 32bit ARM or 64bit ARM?

Only 32-bit has LPAE.  Such things don't make sense on 64-bit CPUs.

[PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Russell King - ARM Linux]

On Sat, Jun 29, 2013 at 12:29:55PM -0700, Yinghai Lu wrote:
> On Sat, Jun 29, 2013 at 10:57 AM, Tejun Heo <tj@kernel.org> wrote:
> > ( Expanding cc list, original thread is at
> >   http://thread.gmane.org/gmane.linux.kernel/1518046 )
> >
> > Hello,
> >
> > On Sat, Jun 29, 2013 at 06:21:24PM +0100, Russell King - ARM Linux wrote:
> >> Unfortunately, that has not been true on ARM - it's very common for
> >> there to be an offset on physical memory, sometimes of the order of
> >> 3GB or more.  This is because on reset, ARMs start executing the code
> >> at physical address zero, which therefore can't be RAM - and there's
> >> a desire to avoid complex switching games in hardware to temporarily
> >> map ROM there instead of RAM.
> >>
> >> On these SoCs which Santosh is working on, the main physical memory
> >> mapping is above 4GB, with just a small alias below 4GB to allow the
> >> system to boot without the MMU being on, as they may have more than
> >> 4GB of RAM.  As I understand it, the small alias below 4GB is not
> >> suitable for use as a "lowmem" mapping.
> 
> is that 32bit ARM or 64bit ARM?

Only 32-bit has LPAE.  Such things don't make sense on 64-bit CPUs.

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Russell King - ARM Linux]

On Sat, Jun 29, 2013 at 12:29:55PM -0700, Yinghai Lu wrote:
> On Sat, Jun 29, 2013 at 10:57 AM, Tejun Heo <tj@kernel.org> wrote:
> > ( Expanding cc list, original thread is at
> >   http://thread.gmane.org/gmane.linux.kernel/1518046 )
> >
> > Hello,
> >
> > On Sat, Jun 29, 2013 at 06:21:24PM +0100, Russell King - ARM Linux wrote:
> >> Unfortunately, that has not been true on ARM - it's very common for
> >> there to be an offset on physical memory, sometimes of the order of
> >> 3GB or more.  This is because on reset, ARMs start executing the code
> >> at physical address zero, which therefore can't be RAM - and there's
> >> a desire to avoid complex switching games in hardware to temporarily
> >> map ROM there instead of RAM.
> >>
> >> On these SoCs which Santosh is working on, the main physical memory
> >> mapping is above 4GB, with just a small alias below 4GB to allow the
> >> system to boot without the MMU being on, as they may have more than
> >> 4GB of RAM.  As I understand it, the small alias below 4GB is not
> >> suitable for use as a "lowmem" mapping.
> 
> is that 32bit ARM or 64bit ARM?

Only 32-bit has LPAE.  Such things don't make sense on 64-bit CPUs.

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Russell King - ARM Linux]

On Sat, Jun 29, 2013 at 12:29:55PM -0700, Yinghai Lu wrote:
> On Sat, Jun 29, 2013 at 10:57 AM, Tejun Heo <tj@kernel.org> wrote:
> > ( Expanding cc list, original thread is at
> >   http://thread.gmane.org/gmane.linux.kernel/1518046 )
> >
> > Hello,
> >
> > On Sat, Jun 29, 2013 at 06:21:24PM +0100, Russell King - ARM Linux wrote:
> >> Unfortunately, that has not been true on ARM - it's very common for
> >> there to be an offset on physical memory, sometimes of the order of
> >> 3GB or more.  This is because on reset, ARMs start executing the code
> >> at physical address zero, which therefore can't be RAM - and there's
> >> a desire to avoid complex switching games in hardware to temporarily
> >> map ROM there instead of RAM.
> >>
> >> On these SoCs which Santosh is working on, the main physical memory
> >> mapping is above 4GB, with just a small alias below 4GB to allow the
> >> system to boot without the MMU being on, as they may have more than
> >> 4GB of RAM.  As I understand it, the small alias below 4GB is not
> >> suitable for use as a "lowmem" mapping.
> 
> is that 32bit ARM or 64bit ARM?

Only 32-bit has LPAE.  Such things don't make sense on 64-bit CPUs.

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Yinghai Lu]

On Sat, Jun 29, 2013 at 12:55 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sat, Jun 29, 2013 at 12:29:55PM -0700, Yinghai Lu wrote:
>> >> On these SoCs which Santosh is working on, the main physical memory
>> >> mapping is above 4GB, with just a small alias below 4GB to allow the
>> >> system to boot without the MMU being on, as they may have more than
>> >> 4GB of RAM.  As I understand it, the small alias below 4GB is not
>> >> suitable for use as a "lowmem" mapping.
>>
>> is that 32bit ARM or 64bit ARM?
>
> Only 32-bit has LPAE.  Such things don't make sense on 64-bit CPUs.

32bit ARM does not support NO_BOOTMEM yet.

arch/arc/Kconfig:       select NO_BOOTMEM
arch/arm64/Kconfig:     select NO_BOOTMEM
arch/sparc/Kconfig:     select NO_BOOTMEM
arch/x86/Kconfig:config NO_BOOTMEM


so may need to
1. make 32bit ARM to use NO_BOOTMEM at first.

2 .we can add alloc_memblock as MACRO or inline for bootmem arches,

3. NO_BOOTMEM arches will have alloc_memblock in nobootmem.c

4. replace alloc_bootmem calling with alloc_memblock calling in core code.

Thanks

Yinghai

[PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Yinghai Lu]

On Sat, Jun 29, 2013 at 12:55 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sat, Jun 29, 2013 at 12:29:55PM -0700, Yinghai Lu wrote:
>> >> On these SoCs which Santosh is working on, the main physical memory
>> >> mapping is above 4GB, with just a small alias below 4GB to allow the
>> >> system to boot without the MMU being on, as they may have more than
>> >> 4GB of RAM.  As I understand it, the small alias below 4GB is not
>> >> suitable for use as a "lowmem" mapping.
>>
>> is that 32bit ARM or 64bit ARM?
>
> Only 32-bit has LPAE.  Such things don't make sense on 64-bit CPUs.

32bit ARM does not support NO_BOOTMEM yet.

arch/arc/Kconfig:       select NO_BOOTMEM
arch/arm64/Kconfig:     select NO_BOOTMEM
arch/sparc/Kconfig:     select NO_BOOTMEM
arch/x86/Kconfig:config NO_BOOTMEM


so may need to
1. make 32bit ARM to use NO_BOOTMEM at first.

2 .we can add alloc_memblock as MACRO or inline for bootmem arches,

3. NO_BOOTMEM arches will have alloc_memblock in nobootmem.c

4. replace alloc_bootmem calling with alloc_memblock calling in core code.

Thanks

Yinghai

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Yinghai Lu]

On Sat, Jun 29, 2013 at 12:55 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sat, Jun 29, 2013 at 12:29:55PM -0700, Yinghai Lu wrote:
>> >> On these SoCs which Santosh is working on, the main physical memory
>> >> mapping is above 4GB, with just a small alias below 4GB to allow the
>> >> system to boot without the MMU being on, as they may have more than
>> >> 4GB of RAM.  As I understand it, the small alias below 4GB is not
>> >> suitable for use as a "lowmem" mapping.
>>
>> is that 32bit ARM or 64bit ARM?
>
> Only 32-bit has LPAE.  Such things don't make sense on 64-bit CPUs.

32bit ARM does not support NO_BOOTMEM yet.

arch/arc/Kconfig:       select NO_BOOTMEM
arch/arm64/Kconfig:     select NO_BOOTMEM
arch/sparc/Kconfig:     select NO_BOOTMEM
arch/x86/Kconfig:config NO_BOOTMEM


so may need to
1. make 32bit ARM to use NO_BOOTMEM at first.

2 .we can add alloc_memblock as MACRO or inline for bootmem arches,

3. NO_BOOTMEM arches will have alloc_memblock in nobootmem.c

4. replace alloc_bootmem calling with alloc_memblock calling in core code.

Thanks

Yinghai

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

On Saturday 29 June 2013 04:08 PM, Yinghai Lu wrote:
> On Sat, Jun 29, 2013 at 12:55 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Sat, Jun 29, 2013 at 12:29:55PM -0700, Yinghai Lu wrote:
>>>>> On these SoCs which Santosh is working on, the main physical memory
>>>>> mapping is above 4GB, with just a small alias below 4GB to allow the
>>>>> system to boot without the MMU being on, as they may have more than
>>>>> 4GB of RAM.  As I understand it, the small alias below 4GB is not
>>>>> suitable for use as a "lowmem" mapping.
>>>
>>> is that 32bit ARM or 64bit ARM?
>>
>> Only 32-bit has LPAE.  Such things don't make sense on 64-bit CPUs.
> 
Thanks Russell for clarifying the issue on the thread. Another major
reason of not being to use 32 bit alias address space for lowmem
is that address space isn't coherent on the SOC am dealing with.

> 32bit ARM does not support NO_BOOTMEM yet.
> 
> arch/arc/Kconfig:       select NO_BOOTMEM
> arch/arm64/Kconfig:     select NO_BOOTMEM
> arch/sparc/Kconfig:     select NO_BOOTMEM
> arch/x86/Kconfig:config NO_BOOTMEM
> 
> 
> so may need to
> 1. make 32bit ARM to use NO_BOOTMEM at first.
> 
Sorry. I should have mentioned that in the change-log. 
I have been carrying some WIP patches for ARM. Will post them
on ARM list after finishing remainder of the testing.

> 2 .we can add alloc_memblock as MACRO or inline for bootmem arches,
> 
> 3. NO_BOOTMEM arches will have alloc_memblock in nobootmem.c
> 
> 4. replace alloc_bootmem calling with alloc_memblock calling in core code.
> 
Great that we all agree to see back of nobootmem.c and have a direct
memblock API. Will be happy to help in conversion to proposed new interfaces
if I can get the alloc_memblock API and core related changes.

Will be good to know who is going to create proposed memblock API
so that we all can collaborate in conversion.

Regards,
Santosh 

[PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

On Saturday 29 June 2013 04:08 PM, Yinghai Lu wrote:
> On Sat, Jun 29, 2013 at 12:55 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Sat, Jun 29, 2013 at 12:29:55PM -0700, Yinghai Lu wrote:
>>>>> On these SoCs which Santosh is working on, the main physical memory
>>>>> mapping is above 4GB, with just a small alias below 4GB to allow the
>>>>> system to boot without the MMU being on, as they may have more than
>>>>> 4GB of RAM.  As I understand it, the small alias below 4GB is not
>>>>> suitable for use as a "lowmem" mapping.
>>>
>>> is that 32bit ARM or 64bit ARM?
>>
>> Only 32-bit has LPAE.  Such things don't make sense on 64-bit CPUs.
> 
Thanks Russell for clarifying the issue on the thread. Another major
reason of not being to use 32 bit alias address space for lowmem
is that address space isn't coherent on the SOC am dealing with.

> 32bit ARM does not support NO_BOOTMEM yet.
> 
> arch/arc/Kconfig:       select NO_BOOTMEM
> arch/arm64/Kconfig:     select NO_BOOTMEM
> arch/sparc/Kconfig:     select NO_BOOTMEM
> arch/x86/Kconfig:config NO_BOOTMEM
> 
> 
> so may need to
> 1. make 32bit ARM to use NO_BOOTMEM at first.
> 
Sorry. I should have mentioned that in the change-log. 
I have been carrying some WIP patches for ARM. Will post them
on ARM list after finishing remainder of the testing.

> 2 .we can add alloc_memblock as MACRO or inline for bootmem arches,
> 
> 3. NO_BOOTMEM arches will have alloc_memblock in nobootmem.c
> 
> 4. replace alloc_bootmem calling with alloc_memblock calling in core code.
> 
Great that we all agree to see back of nobootmem.c and have a direct
memblock API. Will be happy to help in conversion to proposed new interfaces
if I can get the alloc_memblock API and core related changes.

Will be good to know who is going to create proposed memblock API
so that we all can collaborate in conversion.

Regards,
Santosh 

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

On Saturday 29 June 2013 04:08 PM, Yinghai Lu wrote:
> On Sat, Jun 29, 2013 at 12:55 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Sat, Jun 29, 2013 at 12:29:55PM -0700, Yinghai Lu wrote:
>>>>> On these SoCs which Santosh is working on, the main physical memory
>>>>> mapping is above 4GB, with just a small alias below 4GB to allow the
>>>>> system to boot without the MMU being on, as they may have more than
>>>>> 4GB of RAM.  As I understand it, the small alias below 4GB is not
>>>>> suitable for use as a "lowmem" mapping.
>>>
>>> is that 32bit ARM or 64bit ARM?
>>
>> Only 32-bit has LPAE.  Such things don't make sense on 64-bit CPUs.
> 
Thanks Russell for clarifying the issue on the thread. Another major
reason of not being to use 32 bit alias address space for lowmem
is that address space isn't coherent on the SOC am dealing with.

> 32bit ARM does not support NO_BOOTMEM yet.
> 
> arch/arc/Kconfig:       select NO_BOOTMEM
> arch/arm64/Kconfig:     select NO_BOOTMEM
> arch/sparc/Kconfig:     select NO_BOOTMEM
> arch/x86/Kconfig:config NO_BOOTMEM
> 
> 
> so may need to
> 1. make 32bit ARM to use NO_BOOTMEM at first.
> 
Sorry. I should have mentioned that in the change-log. 
I have been carrying some WIP patches for ARM. Will post them
on ARM list after finishing remainder of the testing.

> 2 .we can add alloc_memblock as MACRO or inline for bootmem arches,
> 
> 3. NO_BOOTMEM arches will have alloc_memblock in nobootmem.c
> 
> 4. replace alloc_bootmem calling with alloc_memblock calling in core code.
> 
Great that we all agree to see back of nobootmem.c and have a direct
memblock API. Will be happy to help in conversion to proposed new interfaces
if I can get the alloc_memblock API and core related changes.

Will be good to know who is going to create proposed memblock API
so that we all can collaborate in conversion.

Regards,
Santosh 

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

On Saturday 29 June 2013 04:08 PM, Yinghai Lu wrote:
> On Sat, Jun 29, 2013 at 12:55 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Sat, Jun 29, 2013 at 12:29:55PM -0700, Yinghai Lu wrote:
>>>>> On these SoCs which Santosh is working on, the main physical memory
>>>>> mapping is above 4GB, with just a small alias below 4GB to allow the
>>>>> system to boot without the MMU being on, as they may have more than
>>>>> 4GB of RAM.  As I understand it, the small alias below 4GB is not
>>>>> suitable for use as a "lowmem" mapping.
>>>
>>> is that 32bit ARM or 64bit ARM?
>>
>> Only 32-bit has LPAE.  Such things don't make sense on 64-bit CPUs.
> 
Thanks Russell for clarifying the issue on the thread. Another major
reason of not being to use 32 bit alias address space for lowmem
is that address space isn't coherent on the SOC am dealing with.

> 32bit ARM does not support NO_BOOTMEM yet.
> 
> arch/arc/Kconfig:       select NO_BOOTMEM
> arch/arm64/Kconfig:     select NO_BOOTMEM
> arch/sparc/Kconfig:     select NO_BOOTMEM
> arch/x86/Kconfig:config NO_BOOTMEM
> 
> 
> so may need to
> 1. make 32bit ARM to use NO_BOOTMEM at first.
> 
Sorry. I should have mentioned that in the change-log. 
I have been carrying some WIP patches for ARM. Will post them
on ARM list after finishing remainder of the testing.

> 2 .we can add alloc_memblock as MACRO or inline for bootmem arches,
> 
> 3. NO_BOOTMEM arches will have alloc_memblock in nobootmem.c
> 
> 4. replace alloc_bootmem calling with alloc_memblock calling in core code.
> 
Great that we all agree to see back of nobootmem.c and have a direct
memblock API. Will be happy to help in conversion to proposed new interfaces
if I can get the alloc_memblock API and core related changes.

Will be good to know who is going to create proposed memblock API
so that we all can collaborate in conversion.

Regards,
Santosh 

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

Tejun,

On Monday 01 July 2013 10:10 AM, Santosh Shilimkar wrote:
> On Saturday 29 June 2013 04:08 PM, Yinghai Lu wrote:
>> On Sat, Jun 29, 2013 at 12:55 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>> On Sat, Jun 29, 2013 at 12:29:55PM -0700, Yinghai Lu wrote:
>>>>>> On these SoCs which Santosh is working on, the main physical memory
>>>>>> mapping is above 4GB, with just a small alias below 4GB to allow the
>>>>>> system to boot without the MMU being on, as they may have more than
>>>>>> 4GB of RAM.  As I understand it, the small alias below 4GB is not
>>>>>> suitable for use as a "lowmem" mapping.
>>>>
>>>> is that 32bit ARM or 64bit ARM?
>>>
>>> Only 32-bit has LPAE.  Such things don't make sense on 64-bit CPUs.
>>
> Thanks Russell for clarifying the issue on the thread. Another major
> reason of not being to use 32 bit alias address space for lowmem
> is that address space isn't coherent on the SOC am dealing with.
> 
>> 32bit ARM does not support NO_BOOTMEM yet.
>>
>> arch/arc/Kconfig:       select NO_BOOTMEM
>> arch/arm64/Kconfig:     select NO_BOOTMEM
>> arch/sparc/Kconfig:     select NO_BOOTMEM
>> arch/x86/Kconfig:config NO_BOOTMEM
>>
>>
>> so may need to
>> 1. make 32bit ARM to use NO_BOOTMEM at first.
>>
> Sorry. I should have mentioned that in the change-log. 
> I have been carrying some WIP patches for ARM. Will post them
> on ARM list after finishing remainder of the testing.
> 
>> 2 .we can add alloc_memblock as MACRO or inline for bootmem arches,
>>
>> 3. NO_BOOTMEM arches will have alloc_memblock in nobootmem.c
>>
>> 4. replace alloc_bootmem calling with alloc_memblock calling in core code.
>>
> Great that we all agree to see back of nobootmem.c and have a direct
> memblock API. Will be happy to help in conversion to proposed new interfaces
> if I can get the alloc_memblock API and core related changes.
> 
> Will be good to know who is going to create proposed memblock API
> so that we all can collaborate in conversion.
> 
Any comments here. I would like to know your plan for the new
API. You might have seen on the ARM no-bootmem thread, we started to
move ARM to nobootmem with Russell's help.

Regards,
Santosh

[PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

Tejun,

On Monday 01 July 2013 10:10 AM, Santosh Shilimkar wrote:
> On Saturday 29 June 2013 04:08 PM, Yinghai Lu wrote:
>> On Sat, Jun 29, 2013 at 12:55 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>> On Sat, Jun 29, 2013 at 12:29:55PM -0700, Yinghai Lu wrote:
>>>>>> On these SoCs which Santosh is working on, the main physical memory
>>>>>> mapping is above 4GB, with just a small alias below 4GB to allow the
>>>>>> system to boot without the MMU being on, as they may have more than
>>>>>> 4GB of RAM.  As I understand it, the small alias below 4GB is not
>>>>>> suitable for use as a "lowmem" mapping.
>>>>
>>>> is that 32bit ARM or 64bit ARM?
>>>
>>> Only 32-bit has LPAE.  Such things don't make sense on 64-bit CPUs.
>>
> Thanks Russell for clarifying the issue on the thread. Another major
> reason of not being to use 32 bit alias address space for lowmem
> is that address space isn't coherent on the SOC am dealing with.
> 
>> 32bit ARM does not support NO_BOOTMEM yet.
>>
>> arch/arc/Kconfig:       select NO_BOOTMEM
>> arch/arm64/Kconfig:     select NO_BOOTMEM
>> arch/sparc/Kconfig:     select NO_BOOTMEM
>> arch/x86/Kconfig:config NO_BOOTMEM
>>
>>
>> so may need to
>> 1. make 32bit ARM to use NO_BOOTMEM at first.
>>
> Sorry. I should have mentioned that in the change-log. 
> I have been carrying some WIP patches for ARM. Will post them
> on ARM list after finishing remainder of the testing.
> 
>> 2 .we can add alloc_memblock as MACRO or inline for bootmem arches,
>>
>> 3. NO_BOOTMEM arches will have alloc_memblock in nobootmem.c
>>
>> 4. replace alloc_bootmem calling with alloc_memblock calling in core code.
>>
> Great that we all agree to see back of nobootmem.c and have a direct
> memblock API. Will be happy to help in conversion to proposed new interfaces
> if I can get the alloc_memblock API and core related changes.
> 
> Will be good to know who is going to create proposed memblock API
> so that we all can collaborate in conversion.
> 
Any comments here. I would like to know your plan for the new
API. You might have seen on the ARM no-bootmem thread, we started to
move ARM to nobootmem with Russell's help.

Regards,
Santosh

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

Tejun,

On Monday 01 July 2013 10:10 AM, Santosh Shilimkar wrote:
> On Saturday 29 June 2013 04:08 PM, Yinghai Lu wrote:
>> On Sat, Jun 29, 2013 at 12:55 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>> On Sat, Jun 29, 2013 at 12:29:55PM -0700, Yinghai Lu wrote:
>>>>>> On these SoCs which Santosh is working on, the main physical memory
>>>>>> mapping is above 4GB, with just a small alias below 4GB to allow the
>>>>>> system to boot without the MMU being on, as they may have more than
>>>>>> 4GB of RAM.  As I understand it, the small alias below 4GB is not
>>>>>> suitable for use as a "lowmem" mapping.
>>>>
>>>> is that 32bit ARM or 64bit ARM?
>>>
>>> Only 32-bit has LPAE.  Such things don't make sense on 64-bit CPUs.
>>
> Thanks Russell for clarifying the issue on the thread. Another major
> reason of not being to use 32 bit alias address space for lowmem
> is that address space isn't coherent on the SOC am dealing with.
> 
>> 32bit ARM does not support NO_BOOTMEM yet.
>>
>> arch/arc/Kconfig:       select NO_BOOTMEM
>> arch/arm64/Kconfig:     select NO_BOOTMEM
>> arch/sparc/Kconfig:     select NO_BOOTMEM
>> arch/x86/Kconfig:config NO_BOOTMEM
>>
>>
>> so may need to
>> 1. make 32bit ARM to use NO_BOOTMEM at first.
>>
> Sorry. I should have mentioned that in the change-log. 
> I have been carrying some WIP patches for ARM. Will post them
> on ARM list after finishing remainder of the testing.
> 
>> 2 .we can add alloc_memblock as MACRO or inline for bootmem arches,
>>
>> 3. NO_BOOTMEM arches will have alloc_memblock in nobootmem.c
>>
>> 4. replace alloc_bootmem calling with alloc_memblock calling in core code.
>>
> Great that we all agree to see back of nobootmem.c and have a direct
> memblock API. Will be happy to help in conversion to proposed new interfaces
> if I can get the alloc_memblock API and core related changes.
> 
> Will be good to know who is going to create proposed memblock API
> so that we all can collaborate in conversion.
> 
Any comments here. I would like to know your plan for the new
API. You might have seen on the ARM no-bootmem thread, we started to
move ARM to nobootmem with Russell's help.

Regards,
Santosh

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

Tejun,

On Monday 01 July 2013 10:10 AM, Santosh Shilimkar wrote:
> On Saturday 29 June 2013 04:08 PM, Yinghai Lu wrote:
>> On Sat, Jun 29, 2013 at 12:55 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>> On Sat, Jun 29, 2013 at 12:29:55PM -0700, Yinghai Lu wrote:
>>>>>> On these SoCs which Santosh is working on, the main physical memory
>>>>>> mapping is above 4GB, with just a small alias below 4GB to allow the
>>>>>> system to boot without the MMU being on, as they may have more than
>>>>>> 4GB of RAM.  As I understand it, the small alias below 4GB is not
>>>>>> suitable for use as a "lowmem" mapping.
>>>>
>>>> is that 32bit ARM or 64bit ARM?
>>>
>>> Only 32-bit has LPAE.  Such things don't make sense on 64-bit CPUs.
>>
> Thanks Russell for clarifying the issue on the thread. Another major
> reason of not being to use 32 bit alias address space for lowmem
> is that address space isn't coherent on the SOC am dealing with.
> 
>> 32bit ARM does not support NO_BOOTMEM yet.
>>
>> arch/arc/Kconfig:       select NO_BOOTMEM
>> arch/arm64/Kconfig:     select NO_BOOTMEM
>> arch/sparc/Kconfig:     select NO_BOOTMEM
>> arch/x86/Kconfig:config NO_BOOTMEM
>>
>>
>> so may need to
>> 1. make 32bit ARM to use NO_BOOTMEM at first.
>>
> Sorry. I should have mentioned that in the change-log. 
> I have been carrying some WIP patches for ARM. Will post them
> on ARM list after finishing remainder of the testing.
> 
>> 2 .we can add alloc_memblock as MACRO or inline for bootmem arches,
>>
>> 3. NO_BOOTMEM arches will have alloc_memblock in nobootmem.c
>>
>> 4. replace alloc_bootmem calling with alloc_memblock calling in core code.
>>
> Great that we all agree to see back of nobootmem.c and have a direct
> memblock API. Will be happy to help in conversion to proposed new interfaces
> if I can get the alloc_memblock API and core related changes.
> 
> Will be good to know who is going to create proposed memblock API
> so that we all can collaborate in conversion.
> 
Any comments here. I would like to know your plan for the new
API. You might have seen on the ARM no-bootmem thread, we started to
move ARM to nobootmem with Russell's help.

Regards,
Santosh

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

Tejun,

On Monday 01 July 2013 10:10 AM, Santosh Shilimkar wrote:
> On Saturday 29 June 2013 04:08 PM, Yinghai Lu wrote:
>> On Sat, Jun 29, 2013 at 12:55 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>> On Sat, Jun 29, 2013 at 12:29:55PM -0700, Yinghai Lu wrote:
>>>>>> On these SoCs which Santosh is working on, the main physical memory
>>>>>> mapping is above 4GB, with just a small alias below 4GB to allow the
>>>>>> system to boot without the MMU being on, as they may have more than
>>>>>> 4GB of RAM.  As I understand it, the small alias below 4GB is not
>>>>>> suitable for use as a "lowmem" mapping.
>>>>
>>>> is that 32bit ARM or 64bit ARM?
>>>
>>> Only 32-bit has LPAE.  Such things don't make sense on 64-bit CPUs.
>>
> Thanks Russell for clarifying the issue on the thread. Another major
> reason of not being to use 32 bit alias address space for lowmem
> is that address space isn't coherent on the SOC am dealing with.
> 
>> 32bit ARM does not support NO_BOOTMEM yet.
>>
>> arch/arc/Kconfig:       select NO_BOOTMEM
>> arch/arm64/Kconfig:     select NO_BOOTMEM
>> arch/sparc/Kconfig:     select NO_BOOTMEM
>> arch/x86/Kconfig:config NO_BOOTMEM
>>
>>
>> so may need to
>> 1. make 32bit ARM to use NO_BOOTMEM at first.
>>
> Sorry. I should have mentioned that in the change-log. 
> I have been carrying some WIP patches for ARM. Will post them
> on ARM list after finishing remainder of the testing.
> 
>> 2 .we can add alloc_memblock as MACRO or inline for bootmem arches,
>>
>> 3. NO_BOOTMEM arches will have alloc_memblock in nobootmem.c
>>
>> 4. replace alloc_bootmem calling with alloc_memblock calling in core code.
>>
> Great that we all agree to see back of nobootmem.c and have a direct
> memblock API. Will be happy to help in conversion to proposed new interfaces
> if I can get the alloc_memblock API and core related changes.
> 
> Will be good to know who is going to create proposed memblock API
> so that we all can collaborate in conversion.
> 
Any comments here. I would like to know your plan for the new
API. You might have seen on the ARM no-bootmem thread, we started to
move ARM to nobootmem with Russell's help.

Regards,
Santosh

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Tejun Heo]

Hello,

On Thu, Jul 25, 2013 at 06:33:14PM -0400, Santosh Shilimkar wrote:
> Any comments here. I would like to know your plan for the new
> API. You might have seen on the ARM no-bootmem thread, we started to
> move ARM to nobootmem with Russell's help.

Ooh, the plan sounds good to me and I was thinking you were gonna do
it?

Thanks.

-- 
tejun

[PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Tejun Heo]

Hello,

On Thu, Jul 25, 2013 at 06:33:14PM -0400, Santosh Shilimkar wrote:
> Any comments here. I would like to know your plan for the new
> API. You might have seen on the ARM no-bootmem thread, we started to
> move ARM to nobootmem with Russell's help.

Ooh, the plan sounds good to me and I was thinking you were gonna do
it?

Thanks.

-- 
tejun

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Tejun Heo]

Hello,

On Thu, Jul 25, 2013 at 06:33:14PM -0400, Santosh Shilimkar wrote:
> Any comments here. I would like to know your plan for the new
> API. You might have seen on the ARM no-bootmem thread, we started to
> move ARM to nobootmem with Russell's help.

Ooh, the plan sounds good to me and I was thinking you were gonna do
it?

Thanks.

-- 
tejun

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

On Thursday 25 July 2013 06:36 PM, Tejun Heo wrote:
> Hello,
> 
> On Thu, Jul 25, 2013 at 06:33:14PM -0400, Santosh Shilimkar wrote:
>> Any comments here. I would like to know your plan for the new
>> API. You might have seen on the ARM no-bootmem thread, we started to
>> move ARM to nobootmem with Russell's help.
> 
> Ooh, the plan sounds good to me and I was thinking you were gonna do
> it?
> 
Wooo..

Sorry if I wasn't clear before, but I need help to at least have new
memblock API support since I am not familiar with memblock code. 
I could help in adaptation to the new API for ARM arch and
core kernel code.

Let me know your thoughts.

Regards,
Santosh

[PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

On Thursday 25 July 2013 06:36 PM, Tejun Heo wrote:
> Hello,
> 
> On Thu, Jul 25, 2013 at 06:33:14PM -0400, Santosh Shilimkar wrote:
>> Any comments here. I would like to know your plan for the new
>> API. You might have seen on the ARM no-bootmem thread, we started to
>> move ARM to nobootmem with Russell's help.
> 
> Ooh, the plan sounds good to me and I was thinking you were gonna do
> it?
> 
Wooo..

Sorry if I wasn't clear before, but I need help to at least have new
memblock API support since I am not familiar with memblock code. 
I could help in adaptation to the new API for ARM arch and
core kernel code.

Let me know your thoughts.

Regards,
Santosh

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

On Thursday 25 July 2013 06:36 PM, Tejun Heo wrote:
> Hello,
> 
> On Thu, Jul 25, 2013 at 06:33:14PM -0400, Santosh Shilimkar wrote:
>> Any comments here. I would like to know your plan for the new
>> API. You might have seen on the ARM no-bootmem thread, we started to
>> move ARM to nobootmem with Russell's help.
> 
> Ooh, the plan sounds good to me and I was thinking you were gonna do
> it?
> 
Wooo..

Sorry if I wasn't clear before, but I need help to at least have new
memblock API support since I am not familiar with memblock code. 
I could help in adaptation to the new API for ARM arch and
core kernel code.

Let me know your thoughts.

Regards,
Santosh

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

On Thursday 25 July 2013 06:36 PM, Tejun Heo wrote:
> Hello,
> 
> On Thu, Jul 25, 2013 at 06:33:14PM -0400, Santosh Shilimkar wrote:
>> Any comments here. I would like to know your plan for the new
>> API. You might have seen on the ARM no-bootmem thread, we started to
>> move ARM to nobootmem with Russell's help.
> 
> Ooh, the plan sounds good to me and I was thinking you were gonna do
> it?
> 
Wooo..

Sorry if I wasn't clear before, but I need help to at least have new
memblock API support since I am not familiar with memblock code. 
I could help in adaptation to the new API for ARM arch and
core kernel code.

Let me know your thoughts.

Regards,
Santosh

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

On Thursday 25 July 2013 06:36 PM, Tejun Heo wrote:
> Hello,
> 
> On Thu, Jul 25, 2013 at 06:33:14PM -0400, Santosh Shilimkar wrote:
>> Any comments here. I would like to know your plan for the new
>> API. You might have seen on the ARM no-bootmem thread, we started to
>> move ARM to nobootmem with Russell's help.
> 
> Ooh, the plan sounds good to me and I was thinking you were gonna do
> it?
> 
Wooo..

Sorry if I wasn't clear before, but I need help to at least have new
memblock API support since I am not familiar with memblock code. 
I could help in adaptation to the new API for ARM arch and
core kernel code.

Let me know your thoughts.

Regards,
Santosh

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Tejun Heo]

Hello,

On Thu, Jul 25, 2013 at 07:15:11PM -0400, Santosh Shilimkar wrote:
> Sorry if I wasn't clear before, but I need help to at least have new
> memblock API support since I am not familiar with memblock code. 
> I could help in adaptation to the new API for ARM arch and
> core kernel code.
> 
> Let me know your thoughts.

Unfortunately, I'm currently a bit too occupied to work on it myself.
Any volunteers?

Thanks.

-- 
tejun

[PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Tejun Heo]

Hello,

On Thu, Jul 25, 2013 at 07:15:11PM -0400, Santosh Shilimkar wrote:
> Sorry if I wasn't clear before, but I need help to at least have new
> memblock API support since I am not familiar with memblock code. 
> I could help in adaptation to the new API for ARM arch and
> core kernel code.
> 
> Let me know your thoughts.

Unfortunately, I'm currently a bit too occupied to work on it myself.
Any volunteers?

Thanks.

-- 
tejun

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Tejun Heo]

Hello,

On Thu, Jul 25, 2013 at 07:15:11PM -0400, Santosh Shilimkar wrote:
> Sorry if I wasn't clear before, but I need help to at least have new
> memblock API support since I am not familiar with memblock code. 
> I could help in adaptation to the new API for ARM arch and
> core kernel code.
> 
> Let me know your thoughts.

Unfortunately, I'm currently a bit too occupied to work on it myself.
Any volunteers?

Thanks.

-- 
tejun

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

Tejun,

On Thursday 25 July 2013 11:08 PM, Tejun Heo wrote:
> Hello,
> 
> On Thu, Jul 25, 2013 at 07:15:11PM -0400, Santosh Shilimkar wrote:
>> Sorry if I wasn't clear before, but I need help to at least have new
>> memblock API support since I am not familiar with memblock code. 
>> I could help in adaptation to the new API for ARM arch and
>> core kernel code.
>>
>> Let me know your thoughts.
> 
> Unfortunately, I'm currently a bit too occupied to work on it myself.
> Any volunteers?
> 
Looking at the situation, how about proceeding with patch updating
the bootmem API signatures to use phys_addr_t  which can unblock me
to get my machine working.

Introduction of new API, conversions of core kernel code and then
arches moving away from bootmem is going to take significant time
anyways. I will continue my effort to get ARM port moved to no-bootmem
and get that merged.

Let me know how to make progress here. Appreciate your help on the subject.

Regards,
Santosh

[PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

Tejun,

On Thursday 25 July 2013 11:08 PM, Tejun Heo wrote:
> Hello,
> 
> On Thu, Jul 25, 2013 at 07:15:11PM -0400, Santosh Shilimkar wrote:
>> Sorry if I wasn't clear before, but I need help to at least have new
>> memblock API support since I am not familiar with memblock code. 
>> I could help in adaptation to the new API for ARM arch and
>> core kernel code.
>>
>> Let me know your thoughts.
> 
> Unfortunately, I'm currently a bit too occupied to work on it myself.
> Any volunteers?
> 
Looking at the situation, how about proceeding with patch updating
the bootmem API signatures to use phys_addr_t  which can unblock me
to get my machine working.

Introduction of new API, conversions of core kernel code and then
arches moving away from bootmem is going to take significant time
anyways. I will continue my effort to get ARM port moved to no-bootmem
and get that merged.

Let me know how to make progress here. Appreciate your help on the subject.

Regards,
Santosh

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

Tejun,

On Thursday 25 July 2013 11:08 PM, Tejun Heo wrote:
> Hello,
> 
> On Thu, Jul 25, 2013 at 07:15:11PM -0400, Santosh Shilimkar wrote:
>> Sorry if I wasn't clear before, but I need help to at least have new
>> memblock API support since I am not familiar with memblock code. 
>> I could help in adaptation to the new API for ARM arch and
>> core kernel code.
>>
>> Let me know your thoughts.
> 
> Unfortunately, I'm currently a bit too occupied to work on it myself.
> Any volunteers?
> 
Looking at the situation, how about proceeding with patch updating
the bootmem API signatures to use phys_addr_t  which can unblock me
to get my machine working.

Introduction of new API, conversions of core kernel code and then
arches moving away from bootmem is going to take significant time
anyways. I will continue my effort to get ARM port moved to no-bootmem
and get that merged.

Let me know how to make progress here. Appreciate your help on the subject.

Regards,
Santosh

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

Tejun,

On Thursday 25 July 2013 11:08 PM, Tejun Heo wrote:
> Hello,
> 
> On Thu, Jul 25, 2013 at 07:15:11PM -0400, Santosh Shilimkar wrote:
>> Sorry if I wasn't clear before, but I need help to at least have new
>> memblock API support since I am not familiar with memblock code. 
>> I could help in adaptation to the new API for ARM arch and
>> core kernel code.
>>
>> Let me know your thoughts.
> 
> Unfortunately, I'm currently a bit too occupied to work on it myself.
> Any volunteers?
> 
Looking at the situation, how about proceeding with patch updating
the bootmem API signatures to use phys_addr_t  which can unblock me
to get my machine working.

Introduction of new API, conversions of core kernel code and then
arches moving away from bootmem is going to take significant time
anyways. I will continue my effort to get ARM port moved to no-bootmem
and get that merged.

Let me know how to make progress here. Appreciate your help on the subject.

Regards,
Santosh

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

Tejun,

On Thursday 25 July 2013 11:08 PM, Tejun Heo wrote:
> Hello,
> 
> On Thu, Jul 25, 2013 at 07:15:11PM -0400, Santosh Shilimkar wrote:
>> Sorry if I wasn't clear before, but I need help to at least have new
>> memblock API support since I am not familiar with memblock code. 
>> I could help in adaptation to the new API for ARM arch and
>> core kernel code.
>>
>> Let me know your thoughts.
> 
> Unfortunately, I'm currently a bit too occupied to work on it myself.
> Any volunteers?
> 
Looking at the situation, how about proceeding with patch updating
the bootmem API signatures to use phys_addr_t  which can unblock me
to get my machine working.

Introduction of new API, conversions of core kernel code and then
arches moving away from bootmem is going to take significant time
anyways. I will continue my effort to get ARM port moved to no-bootmem
and get that merged.

Let me know how to make progress here. Appreciate your help on the subject.

Regards,
Santosh

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Tejun Heo]

Hello,

On Fri, Aug 02, 2013 at 05:06:02PM -0400, Santosh Shilimkar wrote:
> Looking at the situation, how about proceeding with patch updating
> the bootmem API signatures to use phys_addr_t  which can unblock me
> to get my machine working.

I'm not sure about that.  No matter how you play it, it'll end up
duplicating memblock interface.

> Introduction of new API, conversions of core kernel code and then

What new API are we talking about?  Wasn't the plan to convert core
kernel code to use memblock and let bootmem emulate bootmem API?
There's no new API.

> arches moving away from bootmem is going to take significant time

And arches moving away from bootmem doesn't have to happen now.

> anyways. I will continue my effort to get ARM port moved to no-bootmem
> and get that merged.

Thanks.

-- 
tejun

[PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Tejun Heo]

Hello,

On Fri, Aug 02, 2013 at 05:06:02PM -0400, Santosh Shilimkar wrote:
> Looking at the situation, how about proceeding with patch updating
> the bootmem API signatures to use phys_addr_t  which can unblock me
> to get my machine working.

I'm not sure about that.  No matter how you play it, it'll end up
duplicating memblock interface.

> Introduction of new API, conversions of core kernel code and then

What new API are we talking about?  Wasn't the plan to convert core
kernel code to use memblock and let bootmem emulate bootmem API?
There's no new API.

> arches moving away from bootmem is going to take significant time

And arches moving away from bootmem doesn't have to happen now.

> anyways. I will continue my effort to get ARM port moved to no-bootmem
> and get that merged.

Thanks.

-- 
tejun

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Tejun Heo]

Hello,

On Fri, Aug 02, 2013 at 05:06:02PM -0400, Santosh Shilimkar wrote:
> Looking at the situation, how about proceeding with patch updating
> the bootmem API signatures to use phys_addr_t  which can unblock me
> to get my machine working.

I'm not sure about that.  No matter how you play it, it'll end up
duplicating memblock interface.

> Introduction of new API, conversions of core kernel code and then

What new API are we talking about?  Wasn't the plan to convert core
kernel code to use memblock and let bootmem emulate bootmem API?
There's no new API.

> arches moving away from bootmem is going to take significant time

And arches moving away from bootmem doesn't have to happen now.

> anyways. I will continue my effort to get ARM port moved to no-bootmem
> and get that merged.

Thanks.

-- 
tejun

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

On Monday 05 August 2013 11:01 AM, Tejun Heo wrote:
> Hello,
> 
> On Fri, Aug 02, 2013 at 05:06:02PM -0400, Santosh Shilimkar wrote:
>> Looking at the situation, how about proceeding with patch updating
>> the bootmem API signatures to use phys_addr_t  which can unblock me
>> to get my machine working.
> 
> I'm not sure about that.  No matter how you play it, it'll end up
> duplicating memblock interface.
> 
fair enough.

>> Introduction of new API, conversions of core kernel code and then
> 
> What new API are we talking about?  Wasn't the plan to convert core
> kernel code to use memblock and let bootmem emulate bootmem API?
> There's no new API.
> 
So looks like I am bit confused here. The current memblock_alloc()
API just returns the physical address which not mapped memory.
Most of the bootmem users including core code expects the
mapped memory pointer which the code can directly operate on.
So the current memblock_alloc() isn't going to help. The nobootmem.c
has __alloc_memory_core_early() which is actually used by most of
the bootmem wrappers to achieve the same. So my assumption was
that we need an equivalent exported memblock API.

What am I missing?

>> arches moving away from bootmem is going to take significant time
> 
> And arches moving away from bootmem doesn't have to happen now.
> 
I agree. The core code conversion is more of an issue.

Regards,
Santosh

[PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

On Monday 05 August 2013 11:01 AM, Tejun Heo wrote:
> Hello,
> 
> On Fri, Aug 02, 2013 at 05:06:02PM -0400, Santosh Shilimkar wrote:
>> Looking at the situation, how about proceeding with patch updating
>> the bootmem API signatures to use phys_addr_t  which can unblock me
>> to get my machine working.
> 
> I'm not sure about that.  No matter how you play it, it'll end up
> duplicating memblock interface.
> 
fair enough.

>> Introduction of new API, conversions of core kernel code and then
> 
> What new API are we talking about?  Wasn't the plan to convert core
> kernel code to use memblock and let bootmem emulate bootmem API?
> There's no new API.
> 
So looks like I am bit confused here. The current memblock_alloc()
API just returns the physical address which not mapped memory.
Most of the bootmem users including core code expects the
mapped memory pointer which the code can directly operate on.
So the current memblock_alloc() isn't going to help. The nobootmem.c
has __alloc_memory_core_early() which is actually used by most of
the bootmem wrappers to achieve the same. So my assumption was
that we need an equivalent exported memblock API.

What am I missing?

>> arches moving away from bootmem is going to take significant time
> 
> And arches moving away from bootmem doesn't have to happen now.
> 
I agree. The core code conversion is more of an issue.

Regards,
Santosh

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

On Monday 05 August 2013 11:01 AM, Tejun Heo wrote:
> Hello,
> 
> On Fri, Aug 02, 2013 at 05:06:02PM -0400, Santosh Shilimkar wrote:
>> Looking at the situation, how about proceeding with patch updating
>> the bootmem API signatures to use phys_addr_t  which can unblock me
>> to get my machine working.
> 
> I'm not sure about that.  No matter how you play it, it'll end up
> duplicating memblock interface.
> 
fair enough.

>> Introduction of new API, conversions of core kernel code and then
> 
> What new API are we talking about?  Wasn't the plan to convert core
> kernel code to use memblock and let bootmem emulate bootmem API?
> There's no new API.
> 
So looks like I am bit confused here. The current memblock_alloc()
API just returns the physical address which not mapped memory.
Most of the bootmem users including core code expects the
mapped memory pointer which the code can directly operate on.
So the current memblock_alloc() isn't going to help. The nobootmem.c
has __alloc_memory_core_early() which is actually used by most of
the bootmem wrappers to achieve the same. So my assumption was
that we need an equivalent exported memblock API.

What am I missing?

>> arches moving away from bootmem is going to take significant time
> 
> And arches moving away from bootmem doesn't have to happen now.
> 
I agree. The core code conversion is more of an issue.

Regards,
Santosh

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

On Monday 05 August 2013 11:01 AM, Tejun Heo wrote:
> Hello,
> 
> On Fri, Aug 02, 2013 at 05:06:02PM -0400, Santosh Shilimkar wrote:
>> Looking at the situation, how about proceeding with patch updating
>> the bootmem API signatures to use phys_addr_t  which can unblock me
>> to get my machine working.
> 
> I'm not sure about that.  No matter how you play it, it'll end up
> duplicating memblock interface.
> 
fair enough.

>> Introduction of new API, conversions of core kernel code and then
> 
> What new API are we talking about?  Wasn't the plan to convert core
> kernel code to use memblock and let bootmem emulate bootmem API?
> There's no new API.
> 
So looks like I am bit confused here. The current memblock_alloc()
API just returns the physical address which not mapped memory.
Most of the bootmem users including core code expects the
mapped memory pointer which the code can directly operate on.
So the current memblock_alloc() isn't going to help. The nobootmem.c
has __alloc_memory_core_early() which is actually used by most of
the bootmem wrappers to achieve the same. So my assumption was
that we need an equivalent exported memblock API.

What am I missing?

>> arches moving away from bootmem is going to take significant time
> 
> And arches moving away from bootmem doesn't have to happen now.
> 
I agree. The core code conversion is more of an issue.

Regards,
Santosh

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

On Monday 05 August 2013 11:01 AM, Tejun Heo wrote:
> Hello,
> 
> On Fri, Aug 02, 2013 at 05:06:02PM -0400, Santosh Shilimkar wrote:
>> Looking at the situation, how about proceeding with patch updating
>> the bootmem API signatures to use phys_addr_t  which can unblock me
>> to get my machine working.
> 
> I'm not sure about that.  No matter how you play it, it'll end up
> duplicating memblock interface.
> 
fair enough.

>> Introduction of new API, conversions of core kernel code and then
> 
> What new API are we talking about?  Wasn't the plan to convert core
> kernel code to use memblock and let bootmem emulate bootmem API?
> There's no new API.
> 
So looks like I am bit confused here. The current memblock_alloc()
API just returns the physical address which not mapped memory.
Most of the bootmem users including core code expects the
mapped memory pointer which the code can directly operate on.
So the current memblock_alloc() isn't going to help. The nobootmem.c
has __alloc_memory_core_early() which is actually used by most of
the bootmem wrappers to achieve the same. So my assumption was
that we need an equivalent exported memblock API.

What am I missing?

>> arches moving away from bootmem is going to take significant time
> 
> And arches moving away from bootmem doesn't have to happen now.
> 
I agree. The core code conversion is more of an issue.

Regards,
Santosh

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Tejun Heo]

Hello,

On Mon, Aug 05, 2013 at 11:29:46AM -0400, Santosh Shilimkar wrote:
> So looks like I am bit confused here. The current memblock_alloc()
> API just returns the physical address which not mapped memory.

The memory returned by memblock is mapped if the memory area being
allocated can be mappable.  To access, the address just needs to be
converted to va.

> Most of the bootmem users including core code expects the
> mapped memory pointer which the code can directly operate on.
> So the current memblock_alloc() isn't going to help. The nobootmem.c
> has __alloc_memory_core_early() which is actually used by most of
> the bootmem wrappers to achieve the same. So my assumption was
> that we need an equivalent exported memblock API.
> 
> What am I missing?

Oh, you weren't.  I was.  I thought we already had full interface
implemented.  Yeah, it looks like we need to build something new
around memblock / __alloc_memory_core_early().

Thanks.

-- 
tejun

[PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Tejun Heo]

Hello,

On Mon, Aug 05, 2013 at 11:29:46AM -0400, Santosh Shilimkar wrote:
> So looks like I am bit confused here. The current memblock_alloc()
> API just returns the physical address which not mapped memory.

The memory returned by memblock is mapped if the memory area being
allocated can be mappable.  To access, the address just needs to be
converted to va.

> Most of the bootmem users including core code expects the
> mapped memory pointer which the code can directly operate on.
> So the current memblock_alloc() isn't going to help. The nobootmem.c
> has __alloc_memory_core_early() which is actually used by most of
> the bootmem wrappers to achieve the same. So my assumption was
> that we need an equivalent exported memblock API.
> 
> What am I missing?

Oh, you weren't.  I was.  I thought we already had full interface
implemented.  Yeah, it looks like we need to build something new
around memblock / __alloc_memory_core_early().

Thanks.

-- 
tejun

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Tejun Heo]

Hello,

On Mon, Aug 05, 2013 at 11:29:46AM -0400, Santosh Shilimkar wrote:
> So looks like I am bit confused here. The current memblock_alloc()
> API just returns the physical address which not mapped memory.

The memory returned by memblock is mapped if the memory area being
allocated can be mappable.  To access, the address just needs to be
converted to va.

> Most of the bootmem users including core code expects the
> mapped memory pointer which the code can directly operate on.
> So the current memblock_alloc() isn't going to help. The nobootmem.c
> has __alloc_memory_core_early() which is actually used by most of
> the bootmem wrappers to achieve the same. So my assumption was
> that we need an equivalent exported memblock API.
> 
> What am I missing?

Oh, you weren't.  I was.  I thought we already had full interface
implemented.  Yeah, it looks like we need to build something new
around memblock / __alloc_memory_core_early().

Thanks.

-- 
tejun

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

On Monday 05 August 2013 11:38 AM, Tejun Heo wrote:
> Hello,
> 
> On Mon, Aug 05, 2013 at 11:29:46AM -0400, Santosh Shilimkar wrote:
>> So looks like I am bit confused here. The current memblock_alloc()
>> API just returns the physical address which not mapped memory.
> 
> The memory returned by memblock is mapped if the memory area being
> allocated can be mappable.  To access, the address just needs to be
> converted to va.
> 
>> Most of the bootmem users including core code expects the
>> mapped memory pointer which the code can directly operate on.
>> So the current memblock_alloc() isn't going to help. The nobootmem.c
>> has __alloc_memory_core_early() which is actually used by most of
>> the bootmem wrappers to achieve the same. So my assumption was
>> that we need an equivalent exported memblock API.
>>
>> What am I missing?
> 
> Oh, you weren't.  I was.  I thought we already had full interface
> implemented.  Yeah, it looks like we need to build something new
> around memblock / __alloc_memory_core_early().
> 
Exactly. This is what actually I referred as the new API.

Regards,
Santosh

[PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

On Monday 05 August 2013 11:38 AM, Tejun Heo wrote:
> Hello,
> 
> On Mon, Aug 05, 2013 at 11:29:46AM -0400, Santosh Shilimkar wrote:
>> So looks like I am bit confused here. The current memblock_alloc()
>> API just returns the physical address which not mapped memory.
> 
> The memory returned by memblock is mapped if the memory area being
> allocated can be mappable.  To access, the address just needs to be
> converted to va.
> 
>> Most of the bootmem users including core code expects the
>> mapped memory pointer which the code can directly operate on.
>> So the current memblock_alloc() isn't going to help. The nobootmem.c
>> has __alloc_memory_core_early() which is actually used by most of
>> the bootmem wrappers to achieve the same. So my assumption was
>> that we need an equivalent exported memblock API.
>>
>> What am I missing?
> 
> Oh, you weren't.  I was.  I thought we already had full interface
> implemented.  Yeah, it looks like we need to build something new
> around memblock / __alloc_memory_core_early().
> 
Exactly. This is what actually I referred as the new API.

Regards,
Santosh

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

On Monday 05 August 2013 11:38 AM, Tejun Heo wrote:
> Hello,
> 
> On Mon, Aug 05, 2013 at 11:29:46AM -0400, Santosh Shilimkar wrote:
>> So looks like I am bit confused here. The current memblock_alloc()
>> API just returns the physical address which not mapped memory.
> 
> The memory returned by memblock is mapped if the memory area being
> allocated can be mappable.  To access, the address just needs to be
> converted to va.
> 
>> Most of the bootmem users including core code expects the
>> mapped memory pointer which the code can directly operate on.
>> So the current memblock_alloc() isn't going to help. The nobootmem.c
>> has __alloc_memory_core_early() which is actually used by most of
>> the bootmem wrappers to achieve the same. So my assumption was
>> that we need an equivalent exported memblock API.
>>
>> What am I missing?
> 
> Oh, you weren't.  I was.  I thought we already had full interface
> implemented.  Yeah, it looks like we need to build something new
> around memblock / __alloc_memory_core_early().
> 
Exactly. This is what actually I referred as the new API.

Regards,
Santosh

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

On Monday 05 August 2013 11:38 AM, Tejun Heo wrote:
> Hello,
> 
> On Mon, Aug 05, 2013 at 11:29:46AM -0400, Santosh Shilimkar wrote:
>> So looks like I am bit confused here. The current memblock_alloc()
>> API just returns the physical address which not mapped memory.
> 
> The memory returned by memblock is mapped if the memory area being
> allocated can be mappable.  To access, the address just needs to be
> converted to va.
> 
>> Most of the bootmem users including core code expects the
>> mapped memory pointer which the code can directly operate on.
>> So the current memblock_alloc() isn't going to help. The nobootmem.c
>> has __alloc_memory_core_early() which is actually used by most of
>> the bootmem wrappers to achieve the same. So my assumption was
>> that we need an equivalent exported memblock API.
>>
>> What am I missing?
> 
> Oh, you weren't.  I was.  I thought we already had full interface
> implemented.  Yeah, it looks like we need to build something new
> around memblock / __alloc_memory_core_early().
> 
Exactly. This is what actually I referred as the new API.

Regards,
Santosh