* [PATCH RFC] arm64/mm: handle memmap kernel option
@ 2017-02-25 6:47 Yisheng Xie
2017-02-26 10:46 ` Ard Biesheuvel
0 siblings, 1 reply; 6+ messages in thread
From: Yisheng Xie @ 2017-02-25 6:47 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 6+ messages in thread* [PATCH RFC] arm64/mm: handle memmap kernel option
2017-02-25 6:47 [PATCH RFC] arm64/mm: handle memmap kernel option Yisheng Xie
@ 2017-02-26 10:46 ` Ard Biesheuvel
2017-02-27 3:48 ` Yisheng Xie
0 siblings, 1 reply; 6+ messages in thread
From: Ard Biesheuvel @ 2017-02-26 10:46 UTC (permalink / raw)
To: linux-arm-kernel
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
>
^ permalink raw reply [flat|nested] 6+ messages in thread* [PATCH RFC] arm64/mm: handle memmap kernel option
2017-02-26 10:46 ` Ard Biesheuvel
@ 2017-02-27 3:48 ` Yisheng Xie
2017-02-27 8:48 ` Mark Rutland
0 siblings, 1 reply; 6+ messages in thread
From: Yisheng Xie @ 2017-02-27 3:48 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH RFC] arm64/mm: handle memmap kernel option
2017-02-27 3:48 ` Yisheng Xie
@ 2017-02-27 8:48 ` Mark Rutland
2017-02-27 10:24 ` Yisheng Xie
0 siblings, 1 reply; 6+ messages in thread
From: Mark Rutland @ 2017-02-27 8:48 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH RFC] arm64/mm: handle memmap kernel option
2017-02-27 8:48 ` Mark Rutland
@ 2017-02-27 10:24 ` Yisheng Xie
2017-02-27 11:42 ` Ard Biesheuvel
0 siblings, 1 reply; 6+ messages in thread
From: Yisheng Xie @ 2017-02-27 10:24 UTC (permalink / raw)
To: linux-arm-kernel
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.
>
> .
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH RFC] arm64/mm: handle memmap kernel option
2017-02-27 10:24 ` Yisheng Xie
@ 2017-02-27 11:42 ` Ard Biesheuvel
0 siblings, 0 replies; 6+ messages in thread
From: Ard Biesheuvel @ 2017-02-27 11:42 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-02-27 11:42 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-02-25 6:47 [PATCH RFC] arm64/mm: handle memmap kernel option Yisheng Xie
2017-02-26 10:46 ` Ard Biesheuvel
2017-02-27 3:48 ` Yisheng Xie
2017-02-27 8:48 ` Mark Rutland
2017-02-27 10:24 ` Yisheng Xie
2017-02-27 11:42 ` Ard Biesheuvel
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox