| Message ID | 1488005245-54811-1-git-send-email-xieyisheng1@huawei.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 >
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
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.
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. > > . >
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.
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;
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(+)