Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1588077 > unrolled thread

[PATCH RFC] arm64/mm: handle memmap kernel option

Back to article view | Back to linux.kernel

Contents

  [PATCH RFC] arm64/mm: handle memmap kernel option Yisheng Xie <xieyisheng1@huawei.com> - 2017-02-25 08:00 +0100
    Re: [PATCH RFC] arm64/mm: handle memmap kernel option Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-02-26 11:50 +0100
      Re: [PATCH RFC] arm64/mm: handle memmap kernel option Yisheng Xie <xieyisheng1@huawei.com> - 2017-02-27 05:00 +0100
        Re: [PATCH RFC] arm64/mm: handle memmap kernel option Yisheng Xie <xieyisheng1@huawei.com> - 2017-02-27 11:30 +0100
          Re: [PATCH RFC] arm64/mm: handle memmap kernel option Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-02-27 13:00 +0100
        Re: [PATCH RFC] arm64/mm: handle memmap kernel option Mark Rutland <mark.rutland@arm.com> - 2017-02-27 13:00 +0100

#1588077 — [PATCH RFC] arm64/mm: handle memmap kernel option

When use device tree mode, user can reserve memory by changes the dts,
however, when boot with ACPI, user cannot reserve memory except by
changing the ACPI table in BIOS, which is not so convenient.

To make user reserve memory for some specific use more convenient,
this patch implement the following memmap variants:
 - memmap=nn[KMG]$ss[KMG]: mark specified memory as reserved;
 - memmap=nn[KMG]@ss[KMG]: force usage of a specific region of memory;

Reported-by: Bob Dong <dongbo4@huawei.com>
Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com>
---
 arch/arm64/mm/init.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index e19e065..cf90c1d 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -188,6 +188,52 @@ static int __init early_mem(char *p)
 }
 early_param("mem", early_mem);
 
+static void __init parse_memmap_one(char *p)
+{
+	char *oldp;
+	unsigned long start_at, mem_size;
+
+	if (!p)
+		return;
+
+	oldp = p;
+	mem_size = memparse(p, &p);
+	if (p == oldp)
+		return;
+
+	switch (*p) {
+	case '@':
+		start_at = memparse(p + 1, &p);
+		memblock_add(start_at, mem_size);
+		break;
+
+	case '$':
+		start_at = memparse(p + 1, &p);
+		memblock_reserve(start_at, mem_size);
+		break;
+
+	default:
+		pr_warn("Unrecognized memmap syntax: %s\n", p);
+		break;
+	}
+}
+
+static int __init parse_memmap_opt(char *str)
+{
+	while (str) {
+		char *k = strchr(str, ',');
+
+		if (k)
+			*k++ = 0;
+
+		parse_memmap_one(str);
+		str = k;
+	}
+
+	return 0;
+}
+early_param("memmap", parse_memmap_opt);
+
 void __init arm64_memblock_init(void)
 {
 	const s64 linear_region_size = -(s64)PAGE_OFFSET;
-- 
1.7.12.4

[toc] | [next] | [standalone]

#1588310

On 25 February 2017 at 06:47, Yisheng Xie <xieyisheng1@huawei.com> wrote:
> When use device tree mode, user can reserve memory by changes the dts,
> however, when boot with ACPI, user cannot reserve memory except by
> changing the ACPI table in BIOS, which is not so convenient.
>
> To make user reserve memory for some specific use more convenient,
> this patch implement the following memmap variants:
>  - memmap=nn[KMG]$ss[KMG]: mark specified memory as reserved;
>  - memmap=nn[KMG]@ss[KMG]: force usage of a specific region of memory;
>
> Reported-by: Bob Dong <dongbo4@huawei.com>
> Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com>

Could you explain which problem you are solving here? ACPI implies
UEFI on arm64, and so these reservations could be made by a boot
component instead, if it requires a fixed memory reservation. If this
is a reservation for, e.g., OP-TEE, we should not rely on the command
line to communicate this information.

> ---
>  arch/arm64/mm/init.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 46 insertions(+)
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index e19e065..cf90c1d 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -188,6 +188,52 @@ static int __init early_mem(char *p)
>  }
>  early_param("mem", early_mem);
>
> +static void __init parse_memmap_one(char *p)
> +{
> +       char *oldp;
> +       unsigned long start_at, mem_size;
> +
> +       if (!p)
> +               return;
> +
> +       oldp = p;
> +       mem_size = memparse(p, &p);
> +       if (p == oldp)
> +               return;
> +
> +       switch (*p) {
> +       case '@':
> +               start_at = memparse(p + 1, &p);
> +               memblock_add(start_at, mem_size);
> +               break;
> +
> +       case '$':
> +               start_at = memparse(p + 1, &p);
> +               memblock_reserve(start_at, mem_size);
> +               break;
> +
> +       default:
> +               pr_warn("Unrecognized memmap syntax: %s\n", p);
> +               break;
> +       }
> +}
> +
> +static int __init parse_memmap_opt(char *str)
> +{
> +       while (str) {
> +               char *k = strchr(str, ',');
> +
> +               if (k)
> +                       *k++ = 0;
> +
> +               parse_memmap_one(str);
> +               str = k;
> +       }
> +
> +       return 0;
> +}
> +early_param("memmap", parse_memmap_opt);
> +
>  void __init arm64_memblock_init(void)
>  {
>         const s64 linear_region_size = -(s64)PAGE_OFFSET;
> --
> 1.7.12.4
>

[toc] | [prev] | [next] | [standalone]

#1588502

Hi Ard,

Thanks for comment.
On 2017/2/26 18:46, Ard Biesheuvel wrote:
> On 25 February 2017 at 06:47, Yisheng Xie <xieyisheng1@huawei.com> wrote:
>> When use device tree mode, user can reserve memory by changes the dts,
>> however, when boot with ACPI, user cannot reserve memory except by
>> changing the ACPI table in BIOS, which is not so convenient.
>>
>> To make user reserve memory for some specific use more convenient,
>> this patch implement the following memmap variants:
>>  - memmap=nn[KMG]$ss[KMG]: mark specified memory as reserved;
>>  - memmap=nn[KMG]@ss[KMG]: force usage of a specific region of memory;
>>
>> Reported-by: Bob Dong <dongbo4@huawei.com>
>> Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com>
> 
> Could you explain which problem you are solving here? ACPI implies
> UEFI on arm64, and so these reservations could be made by a boot
> component instead, if it requires a fixed memory reservation. If this
> is a reservation for, e.g., OP-TEE, we should not rely on the command
> line to communicate this information.
> 
We just want to reserve some memory for a driver and I just not so familiar
with how to reserve memory with UEFI. So doubt about whether it is suitable
to reserve memory with cmdline like "memmap=xxx", which had appeared in x86
for a long time.

Thanks
Yisheng Xie

[toc] | [prev] | [next] | [standalone]

#1588588

hi Mark,

Thanks for comment
On 2017/2/27 16:48, Mark Rutland wrote:
> Hi,
> 
> On Mon, Feb 27, 2017 at 11:48:50AM +0800, Yisheng Xie wrote:
>> On 2017/2/26 18:46, Ard Biesheuvel wrote:
>>> On 25 February 2017 at 06:47, Yisheng Xie <xieyisheng1@huawei.com> wrote:
> 
>>>> To make user reserve memory for some specific use more convenient,
>>>> this patch implement the following memmap variants:
>>>>  - memmap=nn[KMG]$ss[KMG]: mark specified memory as reserved;
>>>>  - memmap=nn[KMG]@ss[KMG]: force usage of a specific region of memory;
> 
>>> Could you explain which problem you are solving here? ACPI implies
>>> UEFI on arm64, and so these reservations could be made by a boot
>>> component instead, if it requires a fixed memory reservation. If this
>>> is a reservation for, e.g., OP-TEE, we should not rely on the command
>>> line to communicate this information.
>>>
>> We just want to reserve some memory for a driver and I just not so familiar
>> with how to reserve memory with UEFI. So doubt about whether it is suitable
>> to reserve memory with cmdline like "memmap=xxx", which had appeared in x86
>> for a long time.
> 
> Could you please explain for what purpose this is necessary?
> 
> Does the driver need a specific region of memory? Or just some contiguous
> region? Or something else?
> 
Yes, we want to use a specific region of memory.

> For the former, this is not an appropriate solution; firmware must absolutely
> mark the memory as reserved for a particular purpose.
> 
I see, so just forget about this patch. sorry for disturbing.

Thanks again for your explain.
Yisheng Xie

> If you just need contiguous physical memory, I believe it would be better to
> use CMA, and request CMA reserve a larger area if necessary.
> 



> Thanks,
> Mark.
> 
> .
> 

[toc] | [prev] | [next] | [standalone]

#1588632

On 27 February 2017 at 10:24, Yisheng Xie <xieyisheng1@huawei.com> wrote:
> hi Mark,
>
> Thanks for comment
> On 2017/2/27 16:48, Mark Rutland wrote:
>> Hi,
>>
>> On Mon, Feb 27, 2017 at 11:48:50AM +0800, Yisheng Xie wrote:
>>> On 2017/2/26 18:46, Ard Biesheuvel wrote:
>>>> On 25 February 2017 at 06:47, Yisheng Xie <xieyisheng1@huawei.com> wrote:
>>
>>>>> To make user reserve memory for some specific use more convenient,
>>>>> this patch implement the following memmap variants:
>>>>>  - memmap=nn[KMG]$ss[KMG]: mark specified memory as reserved;
>>>>>  - memmap=nn[KMG]@ss[KMG]: force usage of a specific region of memory;
>>
>>>> Could you explain which problem you are solving here? ACPI implies
>>>> UEFI on arm64, and so these reservations could be made by a boot
>>>> component instead, if it requires a fixed memory reservation. If this
>>>> is a reservation for, e.g., OP-TEE, we should not rely on the command
>>>> line to communicate this information.
>>>>
>>> We just want to reserve some memory for a driver and I just not so familiar
>>> with how to reserve memory with UEFI. So doubt about whether it is suitable
>>> to reserve memory with cmdline like "memmap=xxx", which had appeared in x86
>>> for a long time.
>>
>> Could you please explain for what purpose this is necessary?
>>
>> Does the driver need a specific region of memory? Or just some contiguous
>> region? Or something else?
>>
> Yes, we want to use a specific region of memory.
>
>> For the former, this is not an appropriate solution; firmware must absolutely
>> mark the memory as reserved for a particular purpose.
>>

Indeed. The reason is that UEFI performs memory allocations itself,
and so putting memmap=xxx on the command line does not prevent the
region from being occupied when the kernel boots.

> I see, so just forget about this patch. sorry for disturbing.
>

No worries.

Thanks for the patch,
Ard.

[toc] | [prev] | [next] | [standalone]

#1588633

Hi,

On Mon, Feb 27, 2017 at 11:48:50AM +0800, Yisheng Xie wrote:
> On 2017/2/26 18:46, Ard Biesheuvel wrote:
> > On 25 February 2017 at 06:47, Yisheng Xie <xieyisheng1@huawei.com> wrote:

> >> To make user reserve memory for some specific use more convenient,
> >> this patch implement the following memmap variants:
> >>  - memmap=nn[KMG]$ss[KMG]: mark specified memory as reserved;
> >>  - memmap=nn[KMG]@ss[KMG]: force usage of a specific region of memory;

> > Could you explain which problem you are solving here? ACPI implies
> > UEFI on arm64, and so these reservations could be made by a boot
> > component instead, if it requires a fixed memory reservation. If this
> > is a reservation for, e.g., OP-TEE, we should not rely on the command
> > line to communicate this information.
> > 
> We just want to reserve some memory for a driver and I just not so familiar
> with how to reserve memory with UEFI. So doubt about whether it is suitable
> to reserve memory with cmdline like "memmap=xxx", which had appeared in x86
> for a long time.

Could you please explain for what purpose this is necessary?

Does the driver need a specific region of memory? Or just some contiguous
region? Or something else?

For the former, this is not an appropriate solution; firmware must absolutely
mark the memory as reserved for a particular purpose.

If you just need contiguous physical memory, I believe it would be better to
use CMA, and request CMA reserve a larger area if necessary.

Thanks,
Mark.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web