Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Subject: Re: [PATCH] MIPS: Refactor early_parse_mem() to fix mem= parameter
To:     Tiezhu Yang <yangtiezhu@loongson.cn>
References: <1645707132-10121-1-git-send-email-yangtiezhu@loongson.cn>
Cc:     Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
        Xuefeng Li <lixuefeng@loongson.cn>, linux-mips@vger.kernel.org,
        linux-kernel@vger.kernel.org
From:   Youling Tang <tangyouling@loongson.cn>
Message-ID: <20d9c6d4-7df4-8a26-4b0f-a5a192cae78d@loongson.cn>
Date:   Fri, 25 Feb 2022 09:12:38 +0800
User-Agent: Mozilla/5.0 (X11; Linux mips64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <1645707132-10121-1-git-send-email-yangtiezhu@loongson.cn>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi, Tiezhu

On 02/24/2022 08:52 PM, 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:
>
>    [    0.000000] Memory limited to 3072MB
>    ...
>    [    0.000000] Memory: 2991952K/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 | 25 ++++++++-----------------
>   1 file changed, 8 insertions(+), 17 deletions(-)
>
> diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
> index f979adf..2917412 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 %lldMB\n", memory_limit >> 20);
>   
>   	return 0;

After applying this patch, my guess is that the kdump operation will fail.

In the MIPS architecture, when the kdump operation is performed, a
"mem=YM@XM" parameter will be added to the capture kernel (added by
kexec-tools), indicating that the available memory range of the
capture kernel is [X, X+Y).

After the "mem" parameter is changed to the above, there will be only
a similar parsing function like "mem=3G", and the type like
"mem=128M@64M" cannot be correctly parsed.

Thanks,
Youling.
>   }
> @@ -633,6 +621,9 @@ static void __init arch_mem_init(char **cmdline_p)
>   
>   	parse_early_param();
>   
> +	/* Limit the memory size via mem= command-line parameter */
> +	memblock_enforce_memory_limit(memory_limit);
> +
>   	if (usermem)
>   		pr_info("User-defined physical RAM map overwrite\n");
>