[PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter

[PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter

[Tiezhu Yang]

In the current code, the kernel command-line parameter mem= and memmap=
can not work well on MIPS, this patchset refactors the related code to
fix them.

For kdump on MIPS, if the users want to limit the memory region for the
capture kernel to avoid corrupting the memory image of the panic kernel,
use the parameter memmap=limit@base is the proper way, I will submit a
patch to use memmap=limit@base for kexec-tools after this patchset is
applied.

v4: Fix some build warnings reported by kernel test robot

v3: Modify patch #3 to maintain compatibility for memmap=limit{$,#,!}base,
    commented by Mike Rapoport, thank you

v2: Add some new patches to support memmap=limit@base

Tiezhu Yang (4):
  MIPS: Refactor early_parse_mem() to fix mem= parameter
  memblock: Introduce memblock_mem_range_remove_map()
  MIPS: Refactor early_parse_memmap() to fix memmap= parameter
  MIPS: Remove not used variable usermem

 arch/mips/kernel/setup.c | 69 ++++++++++++++++++++++--------------------------
 include/linux/memblock.h |  1 +
 mm/memblock.c            |  9 +++++--
 3 files changed, 40 insertions(+), 39 deletions(-)

-- 
2.1.0

[PATCH v4 1/4] MIPS: Refactor early_parse_mem() to fix mem= parameter

[Tiezhu Yang]

According to Documentation/admin-guide/kernel-parameters.txt,
the kernel command-line parameter mem= means "Force usage of
a specific amount of memory", but when add "mem=3G" to the
command-line, kernel boot hangs in sparse_init().

This commit is similar with the implementation of the other
archs such as arm64, powerpc and riscv, refactor the function
early_parse_mem() and then use memblock_enforce_memory_limit()
to limit the memory size.

With this patch, when add "mem=3G" to the command-line, the
kernel boots successfully, we can see the following messages:

  [    0.000000] Memory limited to 3072MB
  ...
  [    0.000000] Early memory node ranges
  [    0.000000]   node   0: [mem 0x0000000000200000-0x000000000effffff]
  [    0.000000]   node   0: [mem 0x0000000090200000-0x00000000ffffffff]
  [    0.000000]   node   0: [mem 0x0000000120000000-0x00000001613fffff]
  ...
  [    0.000000] Memory: 3005280K/3145728K available (...)

After login, the output of free command is consistent with the
above log.

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
---
 arch/mips/kernel/setup.c | 26 +++++++++-----------------
 1 file changed, 9 insertions(+), 17 deletions(-)

diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index f979adf..50396ba 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -339,27 +339,15 @@ static void __init bootmem_init(void)
 #endif	/* CONFIG_SGI_IP27 */
 
 static int usermem __initdata;
+static phys_addr_t memory_limit;
 
 static int __init early_parse_mem(char *p)
 {
-	phys_addr_t start, size;
-
-	/*
-	 * If a user specifies memory size, we
-	 * blow away any automatically generated
-	 * size.
-	 */
-	if (usermem == 0) {
-		usermem = 1;
-		memblock_remove(memblock_start_of_DRAM(),
-			memblock_end_of_DRAM() - memblock_start_of_DRAM());
-	}
-	start = 0;
-	size = memparse(p, &p);
-	if (*p == '@')
-		start = memparse(p + 1, &p);
+	if (!p)
+		return 1;
 
-	memblock_add(start, size);
+	memory_limit = memparse(p, &p) & PAGE_MASK;
+	pr_notice("Memory limited to %lluMB\n", (u64)memory_limit >> 20);
 
 	return 0;
 }
@@ -678,6 +666,10 @@ static void __init arch_mem_init(char **cmdline_p)
 	memblock_reserve(__pa_symbol(&__nosave_begin),
 		__pa_symbol(&__nosave_end) - __pa_symbol(&__nosave_begin));
 
+	/* Limit the memory. */
+	memblock_enforce_memory_limit(memory_limit);
+	memblock_allow_resize();
+
 	early_memtest(PFN_PHYS(ARCH_PFN_OFFSET), PFN_PHYS(max_low_pfn));
 }
 
-- 
2.1.0

[PATCH v4 2/4] memblock: Introduce memblock_mem_range_remove_map()

[Tiezhu Yang]

This is preparation for supporting memmap=limit@base parameter,
no functionality change.

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
---
 include/linux/memblock.h | 1 +
 mm/memblock.c            | 9 +++++++--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 50ad196..e558d2c 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -482,6 +482,7 @@ phys_addr_t memblock_end_of_DRAM(void);
 void memblock_enforce_memory_limit(phys_addr_t memory_limit);
 void memblock_cap_memory_range(phys_addr_t base, phys_addr_t size);
 void memblock_mem_limit_remove_map(phys_addr_t limit);
+void memblock_mem_range_remove_map(phys_addr_t base, phys_addr_t limit);
 bool memblock_is_memory(phys_addr_t addr);
 bool memblock_is_map_memory(phys_addr_t addr);
 bool memblock_is_region_memory(phys_addr_t base, phys_addr_t size);
diff --git a/mm/memblock.c b/mm/memblock.c
index 1018e50..2476d15d 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1723,7 +1723,7 @@ void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size)
 			base + size, PHYS_ADDR_MAX);
 }
 
-void __init memblock_mem_limit_remove_map(phys_addr_t limit)
+void __init memblock_mem_range_remove_map(phys_addr_t base, phys_addr_t limit)
 {
 	phys_addr_t max_addr;
 
@@ -1736,7 +1736,12 @@ void __init memblock_mem_limit_remove_map(phys_addr_t limit)
 	if (max_addr == PHYS_ADDR_MAX)
 		return;
 
-	memblock_cap_memory_range(0, max_addr);
+	memblock_cap_memory_range(base, max_addr);
+}
+
+void __init memblock_mem_limit_remove_map(phys_addr_t limit)
+{
+	memblock_mem_range_remove_map(0, limit);
 }
 
 static int __init_memblock memblock_search(struct memblock_type *type, phys_addr_t addr)
-- 
2.1.0

[PATCH v4 3/4] MIPS: Refactor early_parse_memmap() to fix memmap= parameter

[Tiezhu Yang]

According to Documentation/admin-guide/kernel-parameters.txt,
the kernel command-line parameter memmap= means "Force usage
of a specific region of memory", but when add "memmap=3G@64M"
to the command-line, kernel boot hangs in sparse_init().

In order to support memmap=limit@base, refactor the function
early_parse_memmap() and then use memblock_mem_range_remove_map()
to limit the memory region.

With this patch, when add "memmap=3G@64M" to the command-line,
the kernel boots successfully, we can see the following messages:

  [    0.000000] Memory limited to 64MB-3136MB
  ...
  [    0.000000] Early memory node ranges
  [    0.000000]   node   0: [mem 0x0000000004000000-0x000000000effffff]
  [    0.000000]   node   0: [mem 0x0000000090200000-0x00000000ffffffff]
  [    0.000000]   node   0: [mem 0x0000000120000000-0x00000001653fffff]
  ...
  [    0.000000] Memory: 3070816K/3147776K available (...)

When add "memmap=128M@64M nr_cpus=1 init 3" to the command-line,
the kernel also boots successfully, we can see the following messages:

  [    0.000000] Memory limited to 64MB-192MB
  ...
  [    0.000000] Early memory node ranges
  [    0.000000]   node   0: [mem 0x0000000004000000-0x000000000c1fffff]
  ...
  [    0.000000] Memory: 95312K/133120K available (...)

After login, the output of free command is consistent with the
above log.

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
---
 arch/mips/kernel/setup.c | 40 ++++++++++++++++++++++++----------------
 1 file changed, 24 insertions(+), 16 deletions(-)

diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 50396ba..30c7d95 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -340,6 +340,7 @@ static void __init bootmem_init(void)
 
 static int usermem __initdata;
 static phys_addr_t memory_limit;
+static phys_addr_t memory_base;
 
 static int __init early_parse_mem(char *p)
 {
@@ -356,7 +357,6 @@ early_param("mem", early_parse_mem);
 static int __init early_parse_memmap(char *p)
 {
 	char *oldp;
-	u64 start_at, mem_size;
 
 	if (!p)
 		return -EINVAL;
@@ -367,30 +367,38 @@ static int __init early_parse_memmap(char *p)
 	}
 
 	oldp = p;
-	mem_size = memparse(p, &p);
+	memory_limit = memparse(p, &p) & PAGE_MASK;
 	if (p == oldp)
 		return -EINVAL;
 
 	if (*p == '@') {
-		start_at = memparse(p+1, &p);
-		memblock_add(start_at, mem_size);
+		memory_base = memparse(p + 1, &p) & PAGE_MASK;
+	} else if (*p == '$') {
+		memory_base = memparse(p+1, &p) & PAGE_MASK;
+		memblock_reserve(memory_base, memory_limit);
+		pr_notice("Memory reserved to %lluMB-%lluMB\n",
+			  (u64)memory_base >> 20, (u64)(memory_base + memory_limit) >> 20);
+		memory_base = 0;
+		memory_limit = 0;
+		return 0;
 	} else if (*p == '#') {
-		pr_err("\"memmap=nn#ss\" (force ACPI data) invalid on MIPS\n");
+		pr_err("\"memmap=nn#ss\" invalid on MIPS\n");
+		memory_limit = 0;
+		return -EINVAL;
+	} else if (*p == '!') {
+		pr_err("\"memmap=nn!ss\" invalid on MIPS\n");
+		memory_limit = 0;
 		return -EINVAL;
-	} else if (*p == '$') {
-		start_at = memparse(p+1, &p);
-		memblock_add(start_at, mem_size);
-		memblock_reserve(start_at, mem_size);
 	} else {
-		pr_err("\"memmap\" invalid format!\n");
+		pr_err("Unrecognized memmap syntax: %s\n", p);
+		memory_limit = 0;
 		return -EINVAL;
 	}
 
-	if (*p == '\0') {
-		usermem = 1;
-		return 0;
-	} else
-		return -EINVAL;
+	pr_notice("Memory limited to %lluMB-%lluMB\n",
+		  (u64)memory_base >> 20, (u64)(memory_base + memory_limit) >> 20);
+
+	return *p == '\0' ? 0 : -EINVAL;
 }
 early_param("memmap", early_parse_memmap);
 
@@ -667,7 +675,7 @@ static void __init arch_mem_init(char **cmdline_p)
 		__pa_symbol(&__nosave_end) - __pa_symbol(&__nosave_begin));
 
 	/* Limit the memory. */
-	memblock_enforce_memory_limit(memory_limit);
+	memblock_mem_range_remove_map(memory_base, memory_limit);
 	memblock_allow_resize();
 
 	early_memtest(PFN_PHYS(ARCH_PFN_OFFSET), PFN_PHYS(max_low_pfn));
-- 
2.1.0

[PATCH v4 4/4] MIPS: Remove not used variable usermem

[Tiezhu Yang]

Now, the variable usermem is not used any more, just remove it.

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
---
 arch/mips/kernel/setup.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 30c7d95..8f900f8 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -338,7 +338,6 @@ static void __init bootmem_init(void)
 
 #endif	/* CONFIG_SGI_IP27 */
 
-static int usermem __initdata;
 static phys_addr_t memory_limit;
 static phys_addr_t memory_base;
 
@@ -628,10 +627,6 @@ static void __init arch_mem_init(char **cmdline_p)
 	*cmdline_p = command_line;
 
 	parse_early_param();
-
-	if (usermem)
-		pr_info("User-defined physical RAM map overwrite\n");
-
 	check_kernel_sections_mem();
 
 	early_init_fdt_reserve_self();
-- 
2.1.0

Re: [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter

[Mike Rapoport]

Hi,

On Tue, Mar 01, 2022 at 12:28:57PM +0800, Tiezhu Yang wrote:
> In the current code, the kernel command-line parameter mem= and memmap=
> can not work well on MIPS, this patchset refactors the related code to
> fix them.
> 
> For kdump on MIPS, if the users want to limit the memory region for the
> capture kernel to avoid corrupting the memory image of the panic kernel,
> use the parameter memmap=limit@base is the proper way, I will submit a
> patch to use memmap=limit@base for kexec-tools after this patchset is
> applied.

Sorry, apparently I misread the prevoius version.
What's wrong with the current implementation of mem=limit@base for the
kdump case?
 
> v4: Fix some build warnings reported by kernel test robot
> 
> v3: Modify patch #3 to maintain compatibility for memmap=limit{$,#,!}base,
>     commented by Mike Rapoport, thank you
> 
> v2: Add some new patches to support memmap=limit@base
> 
> Tiezhu Yang (4):
>   MIPS: Refactor early_parse_mem() to fix mem= parameter
>   memblock: Introduce memblock_mem_range_remove_map()
>   MIPS: Refactor early_parse_memmap() to fix memmap= parameter
>   MIPS: Remove not used variable usermem
> 
>  arch/mips/kernel/setup.c | 69 ++++++++++++++++++++++--------------------------
>  include/linux/memblock.h |  1 +
>  mm/memblock.c            |  9 +++++--
>  3 files changed, 40 insertions(+), 39 deletions(-)
> 
> -- 
> 2.1.0
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter

[Tiezhu Yang]

On 03/01/2022 05:55 PM, Mike Rapoport wrote:
> Hi,
>
> On Tue, Mar 01, 2022 at 12:28:57PM +0800, Tiezhu Yang wrote:
>> In the current code, the kernel command-line parameter mem= and memmap=
>> can not work well on MIPS, this patchset refactors the related code to
>> fix them.
>>
>> For kdump on MIPS, if the users want to limit the memory region for the
>> capture kernel to avoid corrupting the memory image of the panic kernel,
>> use the parameter memmap=limit@base is the proper way, I will submit a
>> patch to use memmap=limit@base for kexec-tools after this patchset is
>> applied.
>
> Sorry, apparently I misread the prevoius version.
> What's wrong with the current implementation of mem=limit@base for the
> kdump case?

In the current code, without this patchset, kernel boot hangs when add
mem=3G, mem=3G@64M or memmap=3G@64M to the command-line, it means that
the parameter mem= and memmap= have bug on mips.

Thanks,
Tiezhu

>
>> v4: Fix some build warnings reported by kernel test robot
>>
>> v3: Modify patch #3 to maintain compatibility for memmap=limit{$,#,!}base,
>>     commented by Mike Rapoport, thank you
>>
>> v2: Add some new patches to support memmap=limit@base
>>
>> Tiezhu Yang (4):
>>   MIPS: Refactor early_parse_mem() to fix mem= parameter
>>   memblock: Introduce memblock_mem_range_remove_map()
>>   MIPS: Refactor early_parse_memmap() to fix memmap= parameter
>>   MIPS: Remove not used variable usermem
>>
>>  arch/mips/kernel/setup.c | 69 ++++++++++++++++++++++--------------------------
>>  include/linux/memblock.h |  1 +
>>  mm/memblock.c            |  9 +++++--
>>  3 files changed, 40 insertions(+), 39 deletions(-)
>>
>> --
>> 2.1.0
>>
>

Re: [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter

[Mike Rapoport]

On Tue, Mar 01, 2022 at 07:51:23PM +0800, Tiezhu Yang wrote:
> 
> 
> On 03/01/2022 05:55 PM, Mike Rapoport wrote:
> > Hi,
> > 
> > On Tue, Mar 01, 2022 at 12:28:57PM +0800, Tiezhu Yang wrote:
> > > In the current code, the kernel command-line parameter mem= and memmap=
> > > can not work well on MIPS, this patchset refactors the related code to
> > > fix them.
> > > 
> > > For kdump on MIPS, if the users want to limit the memory region for the
> > > capture kernel to avoid corrupting the memory image of the panic kernel,
> > > use the parameter memmap=limit@base is the proper way, I will submit a
> > > patch to use memmap=limit@base for kexec-tools after this patchset is
> > > applied.
> > 
> > Sorry, apparently I misread the prevoius version.
> > What's wrong with the current implementation of mem=limit@base for the
> > kdump case?
> 
> In the current code, without this patchset, kernel boot hangs when add
> mem=3G, mem=3G@64M or memmap=3G@64M to the command-line, it means that
> the parameter mem= and memmap= have bug on mips.

I can see how mem=3G may be wrong when the memory does not start at 0, but
it seems to do the right thing of mem=3G@64M. 

Do you see system hangs with mem=3G@64M?

Do you have the logs before the hang?

As for memmap= option, it does not specify the memory map but rather alters
the memory map passed by the firmware. Particularity in MIPS implementation
it allows to add a single range of available or reserved memory.

AFAIU, for the kdump use-case mem=X@Y should suffice.

> Thanks,
> Tiezhu
> 
> > 
> > > v4: Fix some build warnings reported by kernel test robot
> > > 
> > > v3: Modify patch #3 to maintain compatibility for memmap=limit{$,#,!}base,
> > >     commented by Mike Rapoport, thank you
> > > 
> > > v2: Add some new patches to support memmap=limit@base
> > > 
> > > Tiezhu Yang (4):
> > >   MIPS: Refactor early_parse_mem() to fix mem= parameter
> > >   memblock: Introduce memblock_mem_range_remove_map()
> > >   MIPS: Refactor early_parse_memmap() to fix memmap= parameter
> > >   MIPS: Remove not used variable usermem
> > > 
> > >  arch/mips/kernel/setup.c | 69 ++++++++++++++++++++++--------------------------
> > >  include/linux/memblock.h |  1 +
> > >  mm/memblock.c            |  9 +++++--
> > >  3 files changed, 40 insertions(+), 39 deletions(-)
> > > 
> > > --
> > > 2.1.0
> > > 
> > 
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter

[Tiezhu Yang]

On 03/01/2022 10:31 PM, Mike Rapoport wrote:
> On Tue, Mar 01, 2022 at 07:51:23PM +0800, Tiezhu Yang wrote:
>>
>>
>> On 03/01/2022 05:55 PM, Mike Rapoport wrote:
>>> Hi,
>>>
>>> On Tue, Mar 01, 2022 at 12:28:57PM +0800, Tiezhu Yang wrote:
>>>> In the current code, the kernel command-line parameter mem= and memmap=
>>>> can not work well on MIPS, this patchset refactors the related code to
>>>> fix them.
>>>>
>>>> For kdump on MIPS, if the users want to limit the memory region for the
>>>> capture kernel to avoid corrupting the memory image of the panic kernel,
>>>> use the parameter memmap=limit@base is the proper way, I will submit a
>>>> patch to use memmap=limit@base for kexec-tools after this patchset is
>>>> applied.
>>>
>>> Sorry, apparently I misread the prevoius version.
>>> What's wrong with the current implementation of mem=limit@base for the
>>> kdump case?
>>
>> In the current code, without this patchset, kernel boot hangs when add
>> mem=3G, mem=3G@64M or memmap=3G@64M to the command-line, it means that
>> the parameter mem= and memmap= have bug on mips.
>
> I can see how mem=3G may be wrong when the memory does not start at 0, but
> it seems to do the right thing of mem=3G@64M.
>
> Do you see system hangs with mem=3G@64M?

Yes.

>
> Do you have the logs before the hang?

Here are the logs:

[    0.000000] Linux version 5.17.0-rc3+ (loongson@linux) (gcc (GCC) 
7.3.1 20180303 (Red Hat 7.3.1-6), GNU ld version 
2.28-13.fc21.loongson.6) #1 SMP PREEMPT Wed Mar 2 09:07:39 CST 2022
[    0.000000] CpuClock = 1800000000
[    0.000000] The bridge chip is LS7A
[    0.000000] CP0_Config3: CP0 16.3 (0xdc8030a0)
[    0.000000] CP0_PageGrain: CP0 5.1 (0x28000000)
[    0.000000] NUMA: Discovered 4 cpus on 1 nodes
[    0.000000] Node0: mem_type:1, mem_start:0x200000, mem_size:0xee MB
[    0.000000]        start_pfn:0x80, end_pfn:0x3c00, num_physpages:0x3b80
[    0.000000] Node0: mem_type:2, mem_start:0x90200000, mem_size:0x6fe MB
[    0.000000]        start_pfn:0x24080, end_pfn:0x40000, 
num_physpages:0x1fb00
[    0.000000] Node0: mem_type:2, mem_start:0x120000000, mem_size:0x1600 MB
[    0.000000]        start_pfn:0x48000, end_pfn:0xa0000, 
num_physpages:0x77b00
[    0.000000] Node0's addrspace_offset is 0x0
[    0.000000] Node0: start_pfn=0x80, end_pfn=0xa0000
[    0.000000] NUMA: set cpumask cpu 0 on node 0
[    0.000000] NUMA: set cpumask cpu 1 on node 0
[    0.000000] NUMA: set cpumask cpu 2 on node 0
[    0.000000] NUMA: set cpumask cpu 3 on node 0
[    0.000000] printk: bootconsole [early0] enabled
[    0.000000] CPU0 revision is: 0014c001 (ICT Loongson-3)
[    0.000000] FPU revision is: 00f70501
[    0.000000] MSA revision is: 00060140
[    0.000000] OF: fdt: No chosen node found, continuing without
[    0.000000] MIPS: machine is loongson,loongson64g-4core-ls7a
[    0.000000] User-defined physical RAM map overwrite
[    0.000000] Kernel sections are not in the memory maps
[    0.000000] Initrd not found or empty - disabling initrd


>
> As for memmap= option, it does not specify the memory map but rather alters
> the memory map passed by the firmware. Particularity in MIPS implementation
> it allows to add a single range of available or reserved memory.
>
> AFAIU, for the kdump use-case mem=X@Y should suffice.

We can modify some code to make mem=X@Y work well,
but according to Documentation/admin-guide/kernel-parameters.txt,
the common way is mem=X and memmap=X@Y, so mem=X@Y for mips seems
odd, the intention of this patchset is to make mem= and memmap=
work well and consistent with the other archs.

Thanks,
Tiezhu

>
>> Thanks,
>> Tiezhu
>>
>>>
>>>> v4: Fix some build warnings reported by kernel test robot
>>>>
>>>> v3: Modify patch #3 to maintain compatibility for memmap=limit{$,#,!}base,
>>>>     commented by Mike Rapoport, thank you
>>>>
>>>> v2: Add some new patches to support memmap=limit@base
>>>>
>>>> Tiezhu Yang (4):
>>>>   MIPS: Refactor early_parse_mem() to fix mem= parameter
>>>>   memblock: Introduce memblock_mem_range_remove_map()
>>>>   MIPS: Refactor early_parse_memmap() to fix memmap= parameter
>>>>   MIPS: Remove not used variable usermem
>>>>
>>>>  arch/mips/kernel/setup.c | 69 ++++++++++++++++++++++--------------------------
>>>>  include/linux/memblock.h |  1 +
>>>>  mm/memblock.c            |  9 +++++--
>>>>  3 files changed, 40 insertions(+), 39 deletions(-)
>>>>
>>>> --
>>>> 2.1.0
>>>>
>>>
>>
>

Re: [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter

[Mike Rapoport]

On Wed, Mar 02, 2022 at 09:50:49AM +0800, Tiezhu Yang wrote:
> 
> 
> On 03/01/2022 10:31 PM, Mike Rapoport wrote:
> > On Tue, Mar 01, 2022 at 07:51:23PM +0800, Tiezhu Yang wrote:
> > > 
> > > 
> > > On 03/01/2022 05:55 PM, Mike Rapoport wrote:
> > > > Hi,
> > > > 
> > > > On Tue, Mar 01, 2022 at 12:28:57PM +0800, Tiezhu Yang wrote:
> > > > > In the current code, the kernel command-line parameter mem= and memmap=
> > > > > can not work well on MIPS, this patchset refactors the related code to
> > > > > fix them.
> > > > > 
> > > > > For kdump on MIPS, if the users want to limit the memory region for the
> > > > > capture kernel to avoid corrupting the memory image of the panic kernel,
> > > > > use the parameter memmap=limit@base is the proper way, I will submit a
> > > > > patch to use memmap=limit@base for kexec-tools after this patchset is
> > > > > applied.
> > > > 
> > > > Sorry, apparently I misread the prevoius version.
> > > > What's wrong with the current implementation of mem=limit@base for the
> > > > kdump case?
> > > 
> > > In the current code, without this patchset, kernel boot hangs when add
> > > mem=3G, mem=3G@64M or memmap=3G@64M to the command-line, it means that
> > > the parameter mem= and memmap= have bug on mips.
> > 
> > I can see how mem=3G may be wrong when the memory does not start at 0, but
> > it seems to do the right thing of mem=3G@64M.
> > 
> > Do you see system hangs with mem=3G@64M?
> 
> Yes.
> 
> > 
> > Do you have the logs before the hang?
> 
> Here are the logs:
> 
> [    0.000000] Linux version 5.17.0-rc3+ (loongson@linux) (gcc (GCC) 7.3.1
> 20180303 (Red Hat 7.3.1-6), GNU ld version 2.28-13.fc21.loongson.6) #1 SMP
> PREEMPT Wed Mar 2 09:07:39 CST 2022
> [    0.000000] CpuClock = 1800000000
> [    0.000000] The bridge chip is LS7A
> [    0.000000] CP0_Config3: CP0 16.3 (0xdc8030a0)
> [    0.000000] CP0_PageGrain: CP0 5.1 (0x28000000)
> [    0.000000] NUMA: Discovered 4 cpus on 1 nodes
> [    0.000000] Node0: mem_type:1, mem_start:0x200000, mem_size:0xee MB
> [    0.000000]        start_pfn:0x80, end_pfn:0x3c00, num_physpages:0x3b80
> [    0.000000] Node0: mem_type:2, mem_start:0x90200000, mem_size:0x6fe MB
> [    0.000000]        start_pfn:0x24080, end_pfn:0x40000,
> num_physpages:0x1fb00
> [    0.000000] Node0: mem_type:2, mem_start:0x120000000, mem_size:0x1600 MB
> [    0.000000]        start_pfn:0x48000, end_pfn:0xa0000,
> num_physpages:0x77b00
> [    0.000000] Node0's addrspace_offset is 0x0
> [    0.000000] Node0: start_pfn=0x80, end_pfn=0xa0000
> [    0.000000] NUMA: set cpumask cpu 0 on node 0
> [    0.000000] NUMA: set cpumask cpu 1 on node 0
> [    0.000000] NUMA: set cpumask cpu 2 on node 0
> [    0.000000] NUMA: set cpumask cpu 3 on node 0
> [    0.000000] printk: bootconsole [early0] enabled
> [    0.000000] CPU0 revision is: 0014c001 (ICT Loongson-3)
> [    0.000000] FPU revision is: 00f70501
> [    0.000000] MSA revision is: 00060140
> [    0.000000] OF: fdt: No chosen node found, continuing without
> [    0.000000] MIPS: machine is loongson,loongson64g-4core-ls7a
> [    0.000000] User-defined physical RAM map overwrite
> [    0.000000] Kernel sections are not in the memory maps
> [    0.000000] Initrd not found or empty - disabling initrd
 
Can you please also send the log with "memblock=debug" added to the kernel
command line?
 
> > As for memmap= option, it does not specify the memory map but rather alters
> > the memory map passed by the firmware. Particularity in MIPS implementation
> > it allows to add a single range of available or reserved memory.
> > 
> > AFAIU, for the kdump use-case mem=X@Y should suffice.
> 
> We can modify some code to make mem=X@Y work well,
> but according to Documentation/admin-guide/kernel-parameters.txt,
> the common way is mem=X and memmap=X@Y, so mem=X@Y for mips seems
> odd, the intention of this patchset is to make mem= and memmap=
> work well and consistent with the other archs.

These options are anyway not consistent on different architectures.
arm, mips and x86 implement mem= one way and arm64, powerpc and riscv in
another so there is no common way to use mem=.

Your changes will break the existing systems that use mem= and memmap=
options because they change the semantics of their MIPS implementation.

For kexec/kdump use-cases modern architectures usually do not pass mem= but
rather prepare the memory map for the kexeced kernel to use. I believe this
would be the right solution.

> Thanks,
> Tiezhu
> 
> > 
> > > Thanks,
> > > Tiezhu
> > > 
> > > > 
> > > > > v4: Fix some build warnings reported by kernel test robot
> > > > > 
> > > > > v3: Modify patch #3 to maintain compatibility for memmap=limit{$,#,!}base,
> > > > >     commented by Mike Rapoport, thank you
> > > > > 
> > > > > v2: Add some new patches to support memmap=limit@base
> > > > > 
> > > > > Tiezhu Yang (4):
> > > > >   MIPS: Refactor early_parse_mem() to fix mem= parameter
> > > > >   memblock: Introduce memblock_mem_range_remove_map()
> > > > >   MIPS: Refactor early_parse_memmap() to fix memmap= parameter
> > > > >   MIPS: Remove not used variable usermem
> > > > > 
> > > > >  arch/mips/kernel/setup.c | 69 ++++++++++++++++++++++--------------------------
> > > > >  include/linux/memblock.h |  1 +
> > > > >  mm/memblock.c            |  9 +++++--
> > > > >  3 files changed, 40 insertions(+), 39 deletions(-)
> > > > > 
> > > > > --
> > > > > 2.1.0
> > > > > 
> > > > 
> > > 
> > 
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter

[Tiezhu Yang]

On 03/02/2022 04:03 PM, Mike Rapoport wrote:
> On Wed, Mar 02, 2022 at 09:50:49AM +0800, Tiezhu Yang wrote:
>>
>>
>> On 03/01/2022 10:31 PM, Mike Rapoport wrote:
>>> On Tue, Mar 01, 2022 at 07:51:23PM +0800, Tiezhu Yang wrote:
>>>>
>>>>
>>>> On 03/01/2022 05:55 PM, Mike Rapoport wrote:
>>>>> Hi,
>>>>>
>>>>> On Tue, Mar 01, 2022 at 12:28:57PM +0800, Tiezhu Yang wrote:
>>>>>> In the current code, the kernel command-line parameter mem= and memmap=
>>>>>> can not work well on MIPS, this patchset refactors the related code to
>>>>>> fix them.
>>>>>>
>>>>>> For kdump on MIPS, if the users want to limit the memory region for the
>>>>>> capture kernel to avoid corrupting the memory image of the panic kernel,
>>>>>> use the parameter memmap=limit@base is the proper way, I will submit a
>>>>>> patch to use memmap=limit@base for kexec-tools after this patchset is
>>>>>> applied.
>>>>>
>>>>> Sorry, apparently I misread the prevoius version.
>>>>> What's wrong with the current implementation of mem=limit@base for the
>>>>> kdump case?
>>>>
>>>> In the current code, without this patchset, kernel boot hangs when add
>>>> mem=3G, mem=3G@64M or memmap=3G@64M to the command-line, it means that
>>>> the parameter mem= and memmap= have bug on mips.
>>>
>>> I can see how mem=3G may be wrong when the memory does not start at 0, but
>>> it seems to do the right thing of mem=3G@64M.
>>>
>>> Do you see system hangs with mem=3G@64M?
>>
>> Yes.
>>
>>>
>>> Do you have the logs before the hang?
>>
>> Here are the logs:
>>
>> [    0.000000] Linux version 5.17.0-rc3+ (loongson@linux) (gcc (GCC) 7.3.1
>> 20180303 (Red Hat 7.3.1-6), GNU ld version 2.28-13.fc21.loongson.6) #1 SMP
>> PREEMPT Wed Mar 2 09:07:39 CST 2022
>> [    0.000000] CpuClock = 1800000000
>> [    0.000000] The bridge chip is LS7A
>> [    0.000000] CP0_Config3: CP0 16.3 (0xdc8030a0)
>> [    0.000000] CP0_PageGrain: CP0 5.1 (0x28000000)
>> [    0.000000] NUMA: Discovered 4 cpus on 1 nodes
>> [    0.000000] Node0: mem_type:1, mem_start:0x200000, mem_size:0xee MB
>> [    0.000000]        start_pfn:0x80, end_pfn:0x3c00, num_physpages:0x3b80
>> [    0.000000] Node0: mem_type:2, mem_start:0x90200000, mem_size:0x6fe MB
>> [    0.000000]        start_pfn:0x24080, end_pfn:0x40000,
>> num_physpages:0x1fb00
>> [    0.000000] Node0: mem_type:2, mem_start:0x120000000, mem_size:0x1600 MB
>> [    0.000000]        start_pfn:0x48000, end_pfn:0xa0000,
>> num_physpages:0x77b00
>> [    0.000000] Node0's addrspace_offset is 0x0
>> [    0.000000] Node0: start_pfn=0x80, end_pfn=0xa0000
>> [    0.000000] NUMA: set cpumask cpu 0 on node 0
>> [    0.000000] NUMA: set cpumask cpu 1 on node 0
>> [    0.000000] NUMA: set cpumask cpu 2 on node 0
>> [    0.000000] NUMA: set cpumask cpu 3 on node 0
>> [    0.000000] printk: bootconsole [early0] enabled
>> [    0.000000] CPU0 revision is: 0014c001 (ICT Loongson-3)
>> [    0.000000] FPU revision is: 00f70501
>> [    0.000000] MSA revision is: 00060140
>> [    0.000000] OF: fdt: No chosen node found, continuing without
>> [    0.000000] MIPS: machine is loongson,loongson64g-4core-ls7a
>> [    0.000000] User-defined physical RAM map overwrite
>> [    0.000000] Kernel sections are not in the memory maps
>> [    0.000000] Initrd not found or empty - disabling initrd
>
> Can you please also send the log with "memblock=debug" added to the kernel
> command line?

[    0.000000] Linux version 5.17.0-rc3+ (loongson@linux) (gcc (GCC) 
7.3.1 20180303 (Red Hat 7.3.1-6), GNU ld version 
2.28-13.fc21.loongson.6) #1 SMP PREEMPT Wed Mar 2 09:07:39 CST 2022
[    0.000000] CpuClock = 1800000000
[    0.000000] The bridge chip is LS7A
[    0.000000] CP0_Config3: CP0 16.3 (0xdc8030a0)
[    0.000000] CP0_PageGrain: CP0 5.1 (0x28000000)
[    0.000000] NUMA: Discovered 4 cpus on 1 nodes
[    0.000000] Node0: mem_type:1, mem_start:0x200000, mem_size:0xee MB
[    0.000000]        start_pfn:0x80, end_pfn:0x3c00, num_physpages:0x3b80
[    0.000000] Node0: mem_type:2, mem_start:0x90200000, mem_size:0x6fe MB
[    0.000000]        start_pfn:0x24080, end_pfn:0x40000, 
num_physpages:0x1fb00
[    0.000000] Node0: mem_type:2, mem_start:0x120000000, mem_size:0x1600 MB
[    0.000000]        start_pfn:0x48000, end_pfn:0xa0000, 
num_physpages:0x77b00
[    0.000000] Node0's addrspace_offset is 0x0
[    0.000000] Node0: start_pfn=0x80, end_pfn=0xa0000
[    0.000000] NUMA: set cpumask cpu 0 on node 0
[    0.000000] NUMA: set cpumask cpu 1 on node 0
[    0.000000] NUMA: set cpumask cpu 2 on node 0
[    0.000000] NUMA: set cpumask cpu 3 on node 0
[    0.000000] printk: bootconsole [early0] enabled
[    0.000000] CPU0 revision is: 0014c001 (ICT Loongson-3)
[    0.000000] FPU revision is: 00f70501
[    0.000000] MSA revision is: 00060140
[    0.000000] OF: fdt: No chosen node found, continuing without
[    0.000000] MIPS: machine is loongson,loongson64g-4core-ls7a
[    0.000000] User-defined physical RAM map overwrite
[    0.000000] Kernel sections are not in the memory maps
[    0.000000] memblock_add: [0x0000000000200000-0x000000000231185f] 
setup_arch+0x140/0x794
[    0.000000] memblock_reserve: [0x0000000001260520-0x0000000001262560] 
setup_arch+0x148/0x794
[    0.000000] Initrd not found or empty - disabling initrd
[    0.000000] memblock_alloc_try_nid: 8257 bytes align=0x40 nid=-1 
from=0x0000000000000000 max_addr=0x0000000000000000 
early_init_dt_alloc_memory_arch+0x30/0x60
[    0.000000] memblock_reserve: [0x0000000004000000-0x0000000004002040] 
memblock_alloc_range_nid+0xf0/0x178
[    0.000000] memblock_alloc_try_nid: 37972 bytes align=0x8 nid=-1 
from=0x0000000000000000 max_addr=0x0000000000000000 
early_init_dt_alloc_memory_arch+0x30/0x60
[    0.000000] memblock_reserve: [0x0000000004002048-0x000000000400b49b] 
memblock_alloc_range_nid+0xf0/0x178

>
>>> As for memmap= option, it does not specify the memory map but rather alters
>>> the memory map passed by the firmware. Particularity in MIPS implementation
>>> it allows to add a single range of available or reserved memory.
>>>
>>> AFAIU, for the kdump use-case mem=X@Y should suffice.
>>
>> We can modify some code to make mem=X@Y work well,
>> but according to Documentation/admin-guide/kernel-parameters.txt,
>> the common way is mem=X and memmap=X@Y, so mem=X@Y for mips seems
>> odd, the intention of this patchset is to make mem= and memmap=
>> work well and consistent with the other archs.
>
> These options are anyway not consistent on different architectures.
> arm, mips and x86 implement mem= one way and arm64, powerpc and riscv in
> another so there is no common way to use mem=.
>
> Your changes will break the existing systems that use mem= and memmap=
> options because they change the semantics of their MIPS implementation.

Thank you, I know your opinion.
Let's wait for Thomas's review to get some more feedbacks.

Thanks,
Tiezhu

>
> For kexec/kdump use-cases modern architectures usually do not pass mem= but
> rather prepare the memory map for the kexeced kernel to use. I believe this
> would be the right solution.
>
>> Thanks,
>> Tiezhu
>>
>>>
>>>> Thanks,
>>>> Tiezhu
>>>>
>>>>>
>>>>>> v4: Fix some build warnings reported by kernel test robot
>>>>>>
>>>>>> v3: Modify patch #3 to maintain compatibility for memmap=limit{$,#,!}base,
>>>>>>     commented by Mike Rapoport, thank you
>>>>>>
>>>>>> v2: Add some new patches to support memmap=limit@base
>>>>>>
>>>>>> Tiezhu Yang (4):
>>>>>>   MIPS: Refactor early_parse_mem() to fix mem= parameter
>>>>>>   memblock: Introduce memblock_mem_range_remove_map()
>>>>>>   MIPS: Refactor early_parse_memmap() to fix memmap= parameter
>>>>>>   MIPS: Remove not used variable usermem
>>>>>>
>>>>>>  arch/mips/kernel/setup.c | 69 ++++++++++++++++++++++--------------------------
>>>>>>  include/linux/memblock.h |  1 +
>>>>>>  mm/memblock.c            |  9 +++++--
>>>>>>  3 files changed, 40 insertions(+), 39 deletions(-)
>>>>>>
>>>>>> --
>>>>>> 2.1.0
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter

[Mike Rapoport]

On Wed, Mar 02, 2022 at 05:28:27PM +0800, Tiezhu Yang wrote:
> 
> On 03/02/2022 04:03 PM, Mike Rapoport wrote:
> > On Wed, Mar 02, 2022 at 09:50:49AM +0800, Tiezhu Yang wrote:
> 
> [    0.000000] Linux version 5.17.0-rc3+ (loongson@linux) (gcc (GCC) 7.3.1
> 20180303 (Red Hat 7.3.1-6), GNU ld version 2.28-13.fc21.loongson.6) #1 SMP
> PREEMPT Wed Mar 2 09:07:39 CST 2022
> [    0.000000] CpuClock = 1800000000
> [    0.000000] The bridge chip is LS7A
> [    0.000000] CP0_Config3: CP0 16.3 (0xdc8030a0)
> [    0.000000] CP0_PageGrain: CP0 5.1 (0x28000000)
> [    0.000000] NUMA: Discovered 4 cpus on 1 nodes
> [    0.000000] Node0: mem_type:1, mem_start:0x200000, mem_size:0xee MB
> [    0.000000]        start_pfn:0x80, end_pfn:0x3c00, num_physpages:0x3b80
> [    0.000000] Node0: mem_type:2, mem_start:0x90200000, mem_size:0x6fe MB
> [    0.000000]        start_pfn:0x24080, end_pfn:0x40000,
> num_physpages:0x1fb00
> [    0.000000] Node0: mem_type:2, mem_start:0x120000000, mem_size:0x1600 MB
> [    0.000000]        start_pfn:0x48000, end_pfn:0xa0000,
> num_physpages:0x77b00
> [    0.000000] Node0's addrspace_offset is 0x0
> [    0.000000] Node0: start_pfn=0x80, end_pfn=0xa0000
> [    0.000000] NUMA: set cpumask cpu 0 on node 0
> [    0.000000] NUMA: set cpumask cpu 1 on node 0
> [    0.000000] NUMA: set cpumask cpu 2 on node 0
> [    0.000000] NUMA: set cpumask cpu 3 on node 0
> [    0.000000] printk: bootconsole [early0] enabled
> [    0.000000] CPU0 revision is: 0014c001 (ICT Loongson-3)
> [    0.000000] FPU revision is: 00f70501
> [    0.000000] MSA revision is: 00060140
> [    0.000000] OF: fdt: No chosen node found, continuing without
> [    0.000000] MIPS: machine is loongson,loongson64g-4core-ls7a
> [    0.000000] User-defined physical RAM map overwrite
> [    0.000000] Kernel sections are not in the memory maps
> [    0.000000] memblock_add: [0x0000000000200000-0x000000000231185f]
> setup_arch+0x140/0x794
> [    0.000000] memblock_reserve: [0x0000000001260520-0x0000000001262560]
> setup_arch+0x148/0x794
> [    0.000000] Initrd not found or empty - disabling initrd
> [    0.000000] memblock_alloc_try_nid: 8257 bytes align=0x40 nid=-1
> from=0x0000000000000000 max_addr=0x0000000000000000
> early_init_dt_alloc_memory_arch+0x30/0x60
> [    0.000000] memblock_reserve: [0x0000000004000000-0x0000000004002040]
> memblock_alloc_range_nid+0xf0/0x178
> [    0.000000] memblock_alloc_try_nid: 37972 bytes align=0x8 nid=-1
> from=0x0000000000000000 max_addr=0x0000000000000000
> early_init_dt_alloc_memory_arch+0x30/0x60
> [    0.000000] memblock_reserve: [0x0000000004002048-0x000000000400b49b]
> memblock_alloc_range_nid+0xf0/0x178
 
As far as I can tell, the kernel lives in 0x200000 and using mem=3G@64M
removes the memory with the kernel and also makes the kernel think there is
memory between 0x400000 and 0xf000000 while there seem to be a hole up to
0x90200000.

This definitely can be reason for the hangs.



-- 
Sincerely yours,
Mike.

Re: [PATCH v4 1/4] MIPS: Refactor early_parse_mem() to fix mem= parameter

[Thomas Bogendoerfer]

On Tue, Mar 01, 2022 at 12:28:58PM +0800, Tiezhu Yang wrote:
> According to Documentation/admin-guide/kernel-parameters.txt,
> the kernel command-line parameter mem= means "Force usage of
> a specific amount of memory", but when add "mem=3G" to the
> command-line, kernel boot hangs in sparse_init().
> 
> This commit is similar with the implementation of the other
> archs such as arm64, powerpc and riscv, refactor the function
> early_parse_mem() and then use memblock_enforce_memory_limit()
> to limit the memory size.
> 
> With this patch, when add "mem=3G" to the command-line, the
> kernel boots successfully, we can see the following messages:

unfortunately this patch would break platforms without memory detection,
which simply use mem=32M for memory configuration. Not sure how many
rely on this mechanism. If we can make sure nobody uses it, I'm fine
with your patch.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

Re: [PATCH v4 1/4] MIPS: Refactor early_parse_mem() to fix mem= parameter

[Thomas Bogendoerfer]

On Fri, Mar 04, 2022 at 04:10:52PM +0100, Thomas Bogendoerfer wrote:
> On Tue, Mar 01, 2022 at 12:28:58PM +0800, Tiezhu Yang wrote:
> > According to Documentation/admin-guide/kernel-parameters.txt,
> > the kernel command-line parameter mem= means "Force usage of
> > a specific amount of memory", but when add "mem=3G" to the
> > command-line, kernel boot hangs in sparse_init().
> > 
> > This commit is similar with the implementation of the other
> > archs such as arm64, powerpc and riscv, refactor the function
> > early_parse_mem() and then use memblock_enforce_memory_limit()
> > to limit the memory size.
> > 
> > With this patch, when add "mem=3G" to the command-line, the
> > kernel boots successfully, we can see the following messages:
> 
> unfortunately this patch would break platforms without memory detection,
> which simply use mem=32M for memory configuration. Not sure how many
> rely on this mechanism. If we can make sure nobody uses it, I'm fine
> with your patch.

maybe we could add a CONFIG option, which will be selected by
platforms, which don't need/want this usermem thing.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

Re: [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter

[Maciej W. Rozycki]

On Wed, 2 Mar 2022, Tiezhu Yang wrote:

> > As for memmap= option, it does not specify the memory map but rather alters
> > the memory map passed by the firmware. Particularity in MIPS implementation
> > it allows to add a single range of available or reserved memory.
> > 
> > AFAIU, for the kdump use-case mem=X@Y should suffice.
> 
> We can modify some code to make mem=X@Y work well,
> but according to Documentation/admin-guide/kernel-parameters.txt,
> the common way is mem=X and memmap=X@Y, so mem=X@Y for mips seems
> odd, the intention of this patchset is to make mem= and memmap=
> work well and consistent with the other archs.

 It is not the MIPS implementation that is odd, it is the others that have 
changed the semantics that are.

 When I added `mem=...' support to the MIPS platform, back on Dec 11th, 
2000, which I needed for a system with with memory holes until I got 
proper memory probing implemented, AFAIR the only other implementation was 
for the x86 and naturally what I did for the MIPS platform was exactly the 
same.  It used to be documented too, but the documentation was removed 
sometime back in 2003 when someone has changed the x86 semantics for 
reasons unknown to me and without letting people working on other 
platforms know, so things diverged.

 Please review:

<https://lore.kernel.org/linux-mips/alpine.LFD.2.21.2010050133330.333514@eddie.linux-mips.org/>

as it has been already discussed.

 If you have a system that hangs with `mem=3G' and which does have 
contiguous RAM available for the kernel to use from 0 through to 3GiB, 
then please either bisect the problem or try finding the root cause as it 
used to work at least those 21 years ago.  Conversely if your system does 
*not* have such RAM available, then use the correct option(s) instead that 
reflect your memory map.

 It is preferable that the memory map be determined automatically either 
by the firmware and then passed to the kernel somehow, or a device tree 
entry, or probed by the kernel itself.  You shouldn't have to specify 
`mem=...' by hand except for debugging or as a temporary workaround.

 For example I have an x86 system that Linux does not how to interrogate 
for RAM beyond 64MiB, so I do use `memmap=128M@0' (for legacy reasons the 
x86 platform has a special exception to always exclude area between 640K 
and 1M from being used even if not explicitly specified, but we do not 
have a need for such legacy such legacy concerns with the MIPS port).  I 
consider it an interim measure however until the kernel has been fixed.

  Maciej

Re: [PATCH v4 1/4] MIPS: Refactor early_parse_mem() to fix mem= parameter

[Maciej W. Rozycki]

On Fri, 4 Mar 2022, Thomas Bogendoerfer wrote:

> > > With this patch, when add "mem=3G" to the command-line, the
> > > kernel boots successfully, we can see the following messages:
> > 
> > unfortunately this patch would break platforms without memory detection,
> > which simply use mem=32M for memory configuration. Not sure how many
> > rely on this mechanism. If we can make sure nobody uses it, I'm fine
> > with your patch.
> 
> maybe we could add a CONFIG option, which will be selected by
> platforms, which don't need/want this usermem thing.

 FWIW I don't understand what the issue is here beyond that we have a bug 
that causes a system to hang when "mem=3G" is passed on the kernel command 
line.  That is assuming that system does have contiguous RAM available for 
the kernel to use from address 0 up to 3GiB; otherwise it's a user error 
to tell the kernel it has that memory available (I did get bitten by that 
myself too): garbage in, garbage out.

 I think having a CONFIG option automatically selected to disable the 
ability to give a memory map override would handicap people in debugging 
their systems or working around firmware bugs, so I would rather be 
against it.

  Maciej

Re: [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter

[Tiezhu Yang]

On 03/05/2022 01:05 AM, Maciej W. Rozycki wrote:
> On Wed, 2 Mar 2022, Tiezhu Yang wrote:
>
>>> As for memmap= option, it does not specify the memory map but rather alters
>>> the memory map passed by the firmware. Particularity in MIPS implementation
>>> it allows to add a single range of available or reserved memory.
>>>
>>> AFAIU, for the kdump use-case mem=X@Y should suffice.
>>
>> We can modify some code to make mem=X@Y work well,
>> but according to Documentation/admin-guide/kernel-parameters.txt,
>> the common way is mem=X and memmap=X@Y, so mem=X@Y for mips seems
>> odd, the intention of this patchset is to make mem= and memmap=
>> work well and consistent with the other archs.
>
>  It is not the MIPS implementation that is odd, it is the others that have
> changed the semantics that are.
>
>  When I added `mem=...' support to the MIPS platform, back on Dec 11th,
> 2000, which I needed for a system with with memory holes until I got
> proper memory probing implemented, AFAIR the only other implementation was
> for the x86 and naturally what I did for the MIPS platform was exactly the
> same.  It used to be documented too, but the documentation was removed
> sometime back in 2003 when someone has changed the x86 semantics for
> reasons unknown to me and without letting people working on other
> platforms know, so things diverged.
>
>  Please review:
>
> <https://lore.kernel.org/linux-mips/alpine.LFD.2.21.2010050133330.333514@eddie.linux-mips.org/>
>
> as it has been already discussed.
>
>  If you have a system that hangs with `mem=3G' and which does have
> contiguous RAM available for the kernel to use from 0 through to 3GiB,
> then please either bisect the problem or try finding the root cause as it
> used to work at least those 21 years ago.  Conversely if your system does
> *not* have such RAM available, then use the correct option(s) instead that
> reflect your memory map.
>
>  It is preferable that the memory map be determined automatically either
> by the firmware and then passed to the kernel somehow, or a device tree
> entry, or probed by the kernel itself.  You shouldn't have to specify
> `mem=...' by hand except for debugging or as a temporary workaround.
>
>  For example I have an x86 system that Linux does not how to interrogate
> for RAM beyond 64MiB, so I do use `memmap=128M@0' (for legacy reasons the
> x86 platform has a special exception to always exclude area between 640K
> and 1M from being used even if not explicitly specified, but we do not
> have a need for such legacy such legacy concerns with the MIPS port).  I
> consider it an interim measure however until the kernel has been fixed.
>
>   Maciej
>

Hi Mike, Thomas and Maciej,

Thank you very much for your feedbacks and discussions.

To be frank, I think mem= and memmap= are used for debugging and testing
in most cases, the intention of this patchset is to refactor the related
code to make them work well on mips.

Now, if put the current patch #2 as the first patch, and then modify the
current patch #1 to support both mem=limit and mem=limit@base (if @base
is omitted, it is equivalent to mem=limit), the other patches #3 and #4
remain unchanged, make sense?

I will send v5 for your review.

Thanks,
Tiezhu

Re: [PATCH v4 1/4] MIPS: Refactor early_parse_mem() to fix mem= parameter

[Mike Rapoport]

On Fri, Mar 04, 2022 at 05:11:44PM +0000, Maciej W. Rozycki wrote:
> On Fri, 4 Mar 2022, Thomas Bogendoerfer wrote:
> 
> > > > With this patch, when add "mem=3G" to the command-line, the
> > > > kernel boots successfully, we can see the following messages:
> > > 
> > > unfortunately this patch would break platforms without memory detection,
> > > which simply use mem=32M for memory configuration. Not sure how many
> > > rely on this mechanism. If we can make sure nobody uses it, I'm fine
> > > with your patch.
> > 
> > maybe we could add a CONFIG option, which will be selected by
> > platforms, which don't need/want this usermem thing.
> 
>  FWIW I don't understand what the issue is here beyond that we have a bug 
> that causes a system to hang when "mem=3G" is passed on the kernel command 
> line.  That is assuming that system does have contiguous RAM available for 
> the kernel to use from address 0 up to 3GiB; otherwise it's a user error 
> to tell the kernel it has that memory available (I did get bitten by that 
> myself too): garbage in, garbage out.

This is exactly the case here because the system does not have contiguous
RAM:

  [    0.000000] Early memory node ranges
  [    0.000000]   node   0: [mem 0x0000000004000000-0x000000000effffff]
  [    0.000000]   node   0: [mem 0x0000000090200000-0x00000000ffffffff]
  [    0.000000]   node   0: [mem 0x0000000120000000-0x00000001653fffff]

(from patch 3/4 in this series)

I don't see what "bug" this patch is trying to fix. Is indeed possible to
make MIPS' mem= behave like it does not arm64 and ppc, but that would break
systems that use current semantics and I recall seeing some of OpenWRT
machines using mem= to override memory map supplied by firmware. 
 
>   Maciej

-- 
Sincerely yours,
Mike.

Re: [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter

[Mike Rapoport]

On Sat, Mar 05, 2022 at 02:19:41PM +0800, Tiezhu Yang wrote:
> 
> 
> On 03/05/2022 01:05 AM, Maciej W. Rozycki wrote:
> > On Wed, 2 Mar 2022, Tiezhu Yang wrote:
> > 
> > > > As for memmap= option, it does not specify the memory map but rather alters
> > > > the memory map passed by the firmware. Particularity in MIPS implementation
> > > > it allows to add a single range of available or reserved memory.
> > > > 
> > > > AFAIU, for the kdump use-case mem=X@Y should suffice.
> > > 
> > > We can modify some code to make mem=X@Y work well,
> > > but according to Documentation/admin-guide/kernel-parameters.txt,
> > > the common way is mem=X and memmap=X@Y, so mem=X@Y for mips seems
> > > odd, the intention of this patchset is to make mem= and memmap=
> > > work well and consistent with the other archs.
> > 
> >  It is not the MIPS implementation that is odd, it is the others that have
> > changed the semantics that are.
> > 
> >  When I added `mem=...' support to the MIPS platform, back on Dec 11th,
> > 2000, which I needed for a system with with memory holes until I got
> > proper memory probing implemented, AFAIR the only other implementation was
> > for the x86 and naturally what I did for the MIPS platform was exactly the
> > same.  It used to be documented too, but the documentation was removed
> > sometime back in 2003 when someone has changed the x86 semantics for
> > reasons unknown to me and without letting people working on other
> > platforms know, so things diverged.
> > 
> >  Please review:
> > 
> > <https://lore.kernel.org/linux-mips/alpine.LFD.2.21.2010050133330.333514@eddie.linux-mips.org/>
> > 
> > as it has been already discussed.
> > 
> >  If you have a system that hangs with `mem=3G' and which does have
> > contiguous RAM available for the kernel to use from 0 through to 3GiB,
> > then please either bisect the problem or try finding the root cause as it
> > used to work at least those 21 years ago.  Conversely if your system does
> > *not* have such RAM available, then use the correct option(s) instead that
> > reflect your memory map.
> > 
> >  It is preferable that the memory map be determined automatically either
> > by the firmware and then passed to the kernel somehow, or a device tree
> > entry, or probed by the kernel itself.  You shouldn't have to specify
> > `mem=...' by hand except for debugging or as a temporary workaround.
> > 
> >  For example I have an x86 system that Linux does not how to interrogate
> > for RAM beyond 64MiB, so I do use `memmap=128M@0' (for legacy reasons the
> > x86 platform has a special exception to always exclude area between 640K
> > and 1M from being used even if not explicitly specified, but we do not
> > have a need for such legacy such legacy concerns with the MIPS port).  I
> > consider it an interim measure however until the kernel has been fixed.
> > 
> >   Maciej
> > 
> 
> Hi Mike, Thomas and Maciej,
> 
> Thank you very much for your feedbacks and discussions.
> 
> To be frank, I think mem= and memmap= are used for debugging and testing
> in most cases, the intention of this patchset is to refactor the related
> code to make them work well on mips.

mem= works fine on mips and there is no need to change it.

If you must supply complex memory layout on the command line, consider
implementing support for memmap=exact and multiple memmap= parameters on
the kernel command line, like x86 does.
 
> Now, if put the current patch #2 as the first patch, and then modify the
> current patch #1 to support both mem=limit and mem=limit@base (if @base
> is omitted, it is equivalent to mem=limit), the other patches #3 and #4
> remain unchanged, make sense?
> 
> I will send v5 for your review.
> 
> Thanks,
> Tiezhu
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter

[Maciej W. Rozycki]

On Sat, 5 Mar 2022, Mike Rapoport wrote:

> > >  For example I have an x86 system that Linux does not how to interrogate
> > > for RAM beyond 64MiB, so I do use `memmap=128M@0' (for legacy reasons the
> > > x86 platform has a special exception to always exclude area between 640K
> > > and 1M from being used even if not explicitly specified, but we do not
> > > have a need for such legacy such legacy concerns with the MIPS port).  I
> > > consider it an interim measure however until the kernel has been fixed.
> > > 
> > >   Maciej
> > > 
> > 
> > Hi Mike, Thomas and Maciej,
> > 
> > Thank you very much for your feedbacks and discussions.
> > 
> > To be frank, I think mem= and memmap= are used for debugging and testing
> > in most cases, the intention of this patchset is to refactor the related
> > code to make them work well on mips.
> 
> mem= works fine on mips and there is no need to change it.
> 
> If you must supply complex memory layout on the command line, consider
> implementing support for memmap=exact and multiple memmap= parameters on
> the kernel command line, like x86 does.

 There's nothing to implement as the MIPS port has supported arbitrary 
memory maps since Dec 11th, 2000; that's almost 22 years now.  C.f.: 
<https://lore.kernel.org/linux-mips/Pine.GSO.3.96.1000814133957.7256S-100000@delta.ds2.pg.gda.pl/>, 
<https://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git/commit/?id=97b7ae4257ef>.

 Sadly commit a09fc446fb6d ("[MIPS] setup.c: use early_param() for early 
command line parsing") removed last pieces of inline documentation; I 
don't know why things like that get approved, but neither I can take 
responsibility.

 Also to say (in said commit):

"There's no point to rewrite some logic to parse command line
to pass initrd parameters or to declare a user memory area.
We could use instead parse_early_param() that does the same
thing."

is IMHO unfair given that the "rewrite" was there in place almost six 
years before `parse_early_param' even started to exist!  Why do people 
assume things have always been like they see them at the time they look?

  Maciej

Re: [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter

[Mike Rapoport]

On Sat, Mar 05, 2022 at 07:21:15PM +0000, Maciej W. Rozycki wrote:
> On Sat, 5 Mar 2022, Mike Rapoport wrote:
> 
> > > >  For example I have an x86 system that Linux does not how to interrogate
> > > > for RAM beyond 64MiB, so I do use `memmap=128M@0' (for legacy reasons the
> > > > x86 platform has a special exception to always exclude area between 640K
> > > > and 1M from being used even if not explicitly specified, but we do not
> > > > have a need for such legacy such legacy concerns with the MIPS port).  I
> > > > consider it an interim measure however until the kernel has been fixed.
> > > > 
> > > >   Maciej
> > > > 
> > > 
> > > Hi Mike, Thomas and Maciej,
> > > 
> > > Thank you very much for your feedbacks and discussions.
> > > 
> > > To be frank, I think mem= and memmap= are used for debugging and testing
> > > in most cases, the intention of this patchset is to refactor the related
> > > code to make them work well on mips.
> > 
> > mem= works fine on mips and there is no need to change it.
> > 
> > If you must supply complex memory layout on the command line, consider
> > implementing support for memmap=exact and multiple memmap= parameters on
> > the kernel command line, like x86 does.
> 
>  There's nothing to implement as the MIPS port has supported arbitrary 
> memory maps since Dec 11th, 2000; that's almost 22 years now.  C.f.: 
> <https://lore.kernel.org/linux-mips/Pine.GSO.3.96.1000814133957.7256S-100000@delta.ds2.pg.gda.pl/>, 
> <https://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git/commit/?id=97b7ae4257ef>.

You are right, and providing mem=X@Y for each contiguous memory range
should work even after 22 years.
I missed the fact that mem= can be repeated several times.
 
>  Sadly commit a09fc446fb6d ("[MIPS] setup.c: use early_param() for early 
> command line parsing") removed last pieces of inline documentation; I 
> don't know why things like that get approved, but neither I can take 
> responsibility.

This is sad indeed, but we still can update the kernel-parameters.txt with
a MIPS paragraph.
 
>   Maciej

-- 
Sincerely yours,
Mike.

Re: [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter

[Maciej W. Rozycki]

On Sat, 5 Mar 2022, Maciej W. Rozycki wrote:

>  Also to say (in said commit):
> 
> "There's no point to rewrite some logic to parse command line
> to pass initrd parameters or to declare a user memory area.
> We could use instead parse_early_param() that does the same
> thing."
> 
> is IMHO unfair given that the "rewrite" was there in place almost six 
> years before `parse_early_param' even started to exist!  Why do people 
> assume things have always been like they see them at the time they look?

 Self-correction for an incorrect last-moment edit: four years before 
rather than six (`parse_early_param' went in upstream shortly before:
<https://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git/commit/?id=5145764263ab>).

  Maciej

Re: [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter

[Maciej W. Rozycki]

On Sat, 5 Mar 2022, Mike Rapoport wrote:

> >  There's nothing to implement as the MIPS port has supported arbitrary 
> > memory maps since Dec 11th, 2000; that's almost 22 years now.  C.f.: 
> > <https://lore.kernel.org/linux-mips/Pine.GSO.3.96.1000814133957.7256S-100000@delta.ds2.pg.gda.pl/>, 
> > <https://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git/commit/?id=97b7ae4257ef>.
> 
> You are right, and providing mem=X@Y for each contiguous memory range
> should work even after 22 years.
> I missed the fact that mem= can be repeated several times.

 Yep, I have now finally tracked down the original bootstrap log for the 
first try of that change:

This DECstation is a DS5000/2x0
Loading R[23]00 MMU routines.
CPU revision is: 00000230
Primary instruction cache 64kb, linesize 4 bytes
Primary data cache 64kb, linesize 4 bytes
Linux version 2.4.0-test5 (macro@macro.ds2.pg.gda.pl) (gcc version 2.95.3 19991030 (prerelease)) #16 Sun Aug 13 16:43:22 CEST 2000
PROM-provided physical RAM map:
 memory: 06800000 @ 00000000
 memory: 00800000 @ 08000000
 memory: 00800000 @ 0a000000
User-defined physical RAM map:
 memory: 06800000 @ 00000000
 memory: 00800000 @ 08000000
 memory: 00800000 @ 0a000000
 memory: 00800000 @ 0c000000
On node 0 totalpages: 51200
zone(0): 51200 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: rw console=ttyS2 mem=104M@0M mem=8M@128M mem=8M@160M mem=8M@192M
Calibrating delay loop... 39.85 BogoMIPS
Memory: 127852k/204800k available (2403k kernel code, 76948k reserved, 610k data, 72k init)
[...]

NB that system is still in service, with more RAM since added.

> >  Sadly commit a09fc446fb6d ("[MIPS] setup.c: use early_param() for early 
> > command line parsing") removed last pieces of inline documentation; I 
> > don't know why things like that get approved, but neither I can take 
> > responsibility.
> 
> This is sad indeed, but we still can update the kernel-parameters.txt with
> a MIPS paragraph.

 Sure, patches are welcome.

  Maciej

Re: [PATCH v4 1/4] MIPS: Refactor early_parse_mem() to fix mem= parameter

[Thomas Bogendoerfer]

On Fri, Mar 04, 2022 at 05:11:44PM +0000, Maciej W. Rozycki wrote:
> On Fri, 4 Mar 2022, Thomas Bogendoerfer wrote:
> 
> > > > With this patch, when add "mem=3G" to the command-line, the
> > > > kernel boots successfully, we can see the following messages:
> > > 
> > > unfortunately this patch would break platforms without memory detection,
> > > which simply use mem=32M for memory configuration. Not sure how many
> > > rely on this mechanism. If we can make sure nobody uses it, I'm fine
> > > with your patch.
> > 
> > maybe we could add a CONFIG option, which will be selected by
> > platforms, which don't need/want this usermem thing.
> 
>  FWIW I don't understand what the issue is here beyond that we have a bug 
> that causes a system to hang when "mem=3G" is passed on the kernel command 
> line.  That is assuming that system does have contiguous RAM available for 
> the kernel to use from address 0 up to 3GiB; otherwise it's a user error 
> to tell the kernel it has that memory available (I did get bitten by that 
> myself too): garbage in, garbage out.

I did a quick test with an IP30:

>> bootp(): ip=dhcp root=/dev/nfs console=ttyS0 mem=384M
Setting $netaddr to 192.168.8.208 (from server )
Obtaining  from server 
9012640+181664 entry: 0xa800000020664a60
Linux version 5.17.0-rc3+ (tbogendoerfer@adalid) (mips64-linux-gnu-gcc (GCC) 6.1.1 20160621 (Red Hat Cross 6.1.1-2), GNU ld version 2.27-3.fc24) #155 SMP Mon Mar 7 13:12:01 CET 2022
ARCH: SGI-IP30
PROMLIB: ARC firmware Version 64 Revision 0
printk: bootconsole [early0] enabled
CPU0 revision is: 00000934 (R10000)
FPU revision is: 00000900
Detected 512MB of physical memory.
User-defined physical RAM map overwrite
Kernel sections are not in the memory maps
IP30: Slot: 0, PrID: 00000934, PhyID: 0, VirtID: 0
IP30: Slot: 1, PrID: 00000934, PhyID: 1, VirtID: 1
IP30: Detected 2 CPU(s) present.
Primary instruction cache 32kB, VIPT, 2-way, linesize 64 bytes.
Primary data cache 32kB, 2-way, VIPT, no aliases, linesize 32 bytes
Unified secondary cache 1024kB 2-way, linesize 128 bytes.
Zone ranges:
  DMA32    [mem 0x0000000000000000-0x00000000ffffffff]
  Normal   empty
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x0000000000000000-0x0000000017ffffff]
  node   0: [mem 0x0000000020004000-0x00000000208c7fff]
Initmem setup node 0 [mem 0x0000000000000000-0x00000000208c7fff]

after that it's dead (it doesn't have memory starting at 0x0).
Most SGI systems will act broken with mem= in one way or another.
And I already had the need to limit the amount of memory.

>  I think having a CONFIG option automatically selected to disable the 
> ability to give a memory map override would handicap people in debugging 
> their systems or working around firmware bugs, so I would rather be 
> against it.

I'm thinking about a CONFIG option, which isn't user selectable, but
selected via Kconfig only. But that would give to differents semantics
for mem=

So can I just limit amount of memory without interfering with normal
memory detection ?

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

Re: [PATCH v4 1/4] MIPS: Refactor early_parse_mem() to fix mem= parameter

[Mike Rapoport]

On Mon, Mar 07, 2022 at 05:29:09PM +0100, Thomas Bogendoerfer wrote:
> On Fri, Mar 04, 2022 at 05:11:44PM +0000, Maciej W. Rozycki wrote:
> > On Fri, 4 Mar 2022, Thomas Bogendoerfer wrote:
> > 
> > > > > With this patch, when add "mem=3G" to the command-line, the
> > > > > kernel boots successfully, we can see the following messages:
> > > > 
> > > > unfortunately this patch would break platforms without memory detection,
> > > > which simply use mem=32M for memory configuration. Not sure how many
> > > > rely on this mechanism. If we can make sure nobody uses it, I'm fine
> > > > with your patch.
> > > 
> > > maybe we could add a CONFIG option, which will be selected by
> > > platforms, which don't need/want this usermem thing.
> > 
> >  FWIW I don't understand what the issue is here beyond that we have a bug 
> > that causes a system to hang when "mem=3G" is passed on the kernel command 
> > line.  That is assuming that system does have contiguous RAM available for 
> > the kernel to use from address 0 up to 3GiB; otherwise it's a user error 
> > to tell the kernel it has that memory available (I did get bitten by that 
> > myself too): garbage in, garbage out.
> 
> I did a quick test with an IP30:
> 
> >> bootp(): ip=dhcp root=/dev/nfs console=ttyS0 mem=384M
> Setting $netaddr to 192.168.8.208 (from server )
> Obtaining  from server 
> 9012640+181664 entry: 0xa800000020664a60
> Linux version 5.17.0-rc3+ (tbogendoerfer@adalid) (mips64-linux-gnu-gcc (GCC) 6.1.1 20160621 (Red Hat Cross 6.1.1-2), GNU ld version 2.27-3.fc24) #155 SMP Mon Mar 7 13:12:01 CET 2022
> ARCH: SGI-IP30
> PROMLIB: ARC firmware Version 64 Revision 0
> printk: bootconsole [early0] enabled
> CPU0 revision is: 00000934 (R10000)
> FPU revision is: 00000900
> Detected 512MB of physical memory.
> User-defined physical RAM map overwrite
> Kernel sections are not in the memory maps
> IP30: Slot: 0, PrID: 00000934, PhyID: 0, VirtID: 0
> IP30: Slot: 1, PrID: 00000934, PhyID: 1, VirtID: 1
> IP30: Detected 2 CPU(s) present.
> Primary instruction cache 32kB, VIPT, 2-way, linesize 64 bytes.
> Primary data cache 32kB, 2-way, VIPT, no aliases, linesize 32 bytes
> Unified secondary cache 1024kB 2-way, linesize 128 bytes.
> Zone ranges:
>   DMA32    [mem 0x0000000000000000-0x00000000ffffffff]
>   Normal   empty
> Movable zone start for each node
> Early memory node ranges
>   node   0: [mem 0x0000000000000000-0x0000000017ffffff]
>   node   0: [mem 0x0000000020004000-0x00000000208c7fff]
> Initmem setup node 0 [mem 0x0000000000000000-0x00000000208c7fff]
> 
> after that it's dead (it doesn't have memory starting at 0x0).
> Most SGI systems will act broken with mem= in one way or another.
> And I already had the need to limit the amount of memory.
> 
> >  I think having a CONFIG option automatically selected to disable the 
> > ability to give a memory map override would handicap people in debugging 
> > their systems or working around firmware bugs, so I would rather be 
> > against it.
> 
> I'm thinking about a CONFIG option, which isn't user selectable, but
> selected via Kconfig only. But that would give to differents semantics
> for mem=
> 
> So can I just limit amount of memory without interfering with normal
> memory detection ?

Maybe it's better to add a new encoding to mem= that will have the semantics
of limiting amount of memory?

E.g.

mem=384M@

would mean "only use 384M of memory that firmware reported" while

mem=384M would mean "set memory to 0 - 384M" as it does now.

I think it's fine to have this MIPS specific because there is anyway no
consistency among architectures in mem= handling.
 
> Thomas.
> 
> -- 
> Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
> good idea.                                                [ RFC1925, 2.3 ]

-- 
Sincerely yours,
Mike.

Re: [PATCH v4 1/4] MIPS: Refactor early_parse_mem() to fix mem= parameter

[Maciej W. Rozycki]

On Tue, 8 Mar 2022, Mike Rapoport wrote:

> > So can I just limit amount of memory without interfering with normal
> > memory detection ?
> 
> Maybe it's better to add a new encoding to mem= that will have the semantics
> of limiting amount of memory?
> 
> E.g.
> 
> mem=384M@
> 
> would mean "only use 384M of memory that firmware reported" while
> 
> mem=384M would mean "set memory to 0 - 384M" as it does now.

 I think you're going in the right direction, we'd just need to sort out 
the most reasonable syntax for the new semantics; `mem=384M@' just seems 
too analogous to me to `mem=384M@0'.  Maybe `mem=384M-'?

 NB that would have to work with the existing overrides, for e.g.:

`mem=192M@0 mem=192M@256M mem=384M-'

to produce the following memory ranges available for use:

  Normal   [mem 0x0000000000000000-0x000000000bffffff]
  Normal   [mem 0x0000000010000000-0x0000000017ffffff]

(so that you can paste the final cap at some command prompt and still have 
earlier parameters respected that may have been passed by the firmware or 
bootloader, or built in).

  Maciej