arm64: mm: add support for memmap kernel parameters

Commit Message

Song Bao Hua (Barry Song) Nov. 18, 2020, 6:33 a.m. UTC

memmap should be an useful kernel parameter which has been supported by
x86, mips and xtensa. This patch adds support for ARM64. At this stage,
the below two modes are supported only:
memmap=nn[KMG]@ss[KMG]
Force usage of a specific region of memory

memmap=nn[KMG]$ss[KMG]
Region of memory to be reserved is from ss to ss+nn

If users set memmap=exactmap before memmap=nn[KMG]@ss[KMG], they will
get the exact memory specified by memmap=nn[KMG]@ss[KMG]. For example,
on one machine with 4GB memory, "memmap=exactmap memmap=1G@1G" will
make kernel use the memory from 1GB to 2GB only.

Signed-off-by: Barry Song <[e-mail]>
---
 arch/arm64/mm/init.c | 59 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 59 insertions(+)

Comments

Mike Rapoport Nov. 18, 2020, 5:38 p.m. UTC | #1

Hi Barry,

On Wed, Nov 18, 2020 at 07:33:14PM +1300, Barry Song wrote:
> memmap should be an useful kernel parameter which has been supported by
> x86, mips and xtensa.

Why is this parameter should be useful for ARM64? 
My understanding is that it is required only to work around really
broken bootloaders, isn't it?

> This patch adds support for ARM64. At this stage,
> the below two modes are supported only:
> memmap=nn[KMG]@ss[KMG]
> Force usage of a specific region of memory
> 
> memmap=nn[KMG]$ss[KMG]
> Region of memory to be reserved is from ss to ss+nn
> 
> If users set memmap=exactmap before memmap=nn[KMG]@ss[KMG], they will
> get the exact memory specified by memmap=nn[KMG]@ss[KMG]. For example,
> on one machine with 4GB memory, "memmap=exactmap memmap=1G@1G" will
> make kernel use the memory from 1GB to 2GB only.
> 
> Signed-off-by: Barry Song <[e-mail]>
> ---
>  arch/arm64/mm/init.c | 59 ++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 59 insertions(+)
> 
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 095540667f0f..f1c6bfdbc953 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -235,6 +235,65 @@ static int __init early_mem(char *p)
>  }
>  early_param("mem", early_mem);
>  
> +static int need_remove_real_memblock __initdata;
> +
> +static void __init parse_memmap_one(char *p)
> +{
> +	char *oldp;
> +	unsigned long start_at, mem_size;
> +
> +	if (!p)
> +		return;
> +
> +	if (!strncmp(p, "exactmap", 8)) {
> +		need_remove_real_memblock = 1;
> +		return;
> +	}
> +
> +	oldp = p;
> +	mem_size = memparse(p, &p);
> +	if (p == oldp)
> +		return;
> +
> +	switch (*p) {
> +	case '@':
> +		start_at = memparse(p + 1, &p);
> +		/*
> +		 * use the exactmap defined by nn[KMG]@ss[KMG], remove
> +		 * memblock populated by DT etc.
> +		 */
> +		if (need_remove_real_memblock) {
> +			need_remove_real_memblock = 0;
> +			memblock_remove(0, ULLONG_MAX);
> +		}
> +		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);
> +
>  static int __init early_init_dt_scan_usablemem(unsigned long node,
>  		const char *uname, int depth, void *data)
>  {
> -- 
> 2.25.1
>

Will Deacon Nov. 18, 2020, 7:15 p.m. UTC | #2

On Wed, Nov 18, 2020 at 07:38:54PM +0200, Mike Rapoport wrote:
> On Wed, Nov 18, 2020 at 07:33:14PM +1300, Barry Song wrote:
> > memmap should be an useful kernel parameter which has been supported by
> > x86, mips and xtensa.
> 
> Why is this parameter should be useful for ARM64? 
> My understanding is that it is required only to work around really
> broken bootloaders, isn't it?

Agreed, I can't see this being something we really want to support. If it
turns out that it is generally useful, then the implementation should
probably be somewhere outside of arch/ where I don't have to look at it :)

Will

Song Bao Hua (Barry Song) Nov. 18, 2020, 8:25 p.m. UTC | #3

> -----Original Message-----
> From: Will Deacon [mailto:[e-mail]]
> Sent: Thursday, November 19, 2020 8:15 AM
> To: Mike Rapoport <[e-mail]>
> Cc: Song Bao Hua (Barry Song) <[e-mail]>;
> [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; Linuxarm <[e-mail]>
> Subject: Re: [PATCH] arm64: mm: add support for memmap kernel parameters
> 
> On Wed, Nov 18, 2020 at 07:38:54PM +0200, Mike Rapoport wrote:
> > On Wed, Nov 18, 2020 at 07:33:14PM +1300, Barry Song wrote:
> > > memmap should be an useful kernel parameter which has been supported
> by
> > > x86, mips and xtensa.
> >
> > Why is this parameter should be useful for ARM64?
> > My understanding is that it is required only to work around really
> > broken bootloaders, isn't it?
> 

Good question. Originally I wrote this patch to debug and verify the vmemmap
leak issue reported in this patch:
[PATCH v2] arm64: mm: free unused memmap for sparse memory model that define VMEMMAP
https://lore.kernel.org/linux-arm-kernel/[e-mail]/
I don't have a machine which really has holes in memory_section to debug, but memmap
can help. With memmap, I could specified a machine with various holds in mem_sections.

After that, I figured out this is not only useful for debugging purpose. it can have some real user cases.
For example:

1. DAX on DRAM.
kernel parameter memmap=XG!YG specifies a range of RAM to emulate pmem. Then we are able
to run DAX and filesystem on top of it. Furthermore, this will probably also benefit the case
this big patchset wants to "fix" via direct access to memory:
https://lore.kernel.org/lkml/[e-mail]/T/#m1a77074b8e1dadc590a5f45a52d9c3cda69c0780
as the comments have clearly shown.

2. reserve some memory for userspace to manage via /dev/mem


> Agreed, I can't see this being something we really want to support. If it
> turns out that it is generally useful, then the implementation should
> probably be somewhere outside of arch/ where I don't have to look at it :)
> 

What stops this becoming common code is that each platform has different ways
and boot sequences to populate memblock.
For example, on Arm64, while early_param is populated, dt has populated
memblock before that. Other platforms might been much different.

> Will

Thanks
Barry

Ard Biesheuvel Nov. 18, 2020, 10:38 p.m. UTC | #4

On Wed, 18 Nov 2020 at 21:27, Song Bao Hua (Barry Song)
<[e-mail]> wrote:
>
>
>
> > -----Original Message-----
> > From: Will Deacon [mailto:[e-mail]]
> > Sent: Thursday, November 19, 2020 8:15 AM
> > To: Mike Rapoport <[e-mail]>
> > Cc: Song Bao Hua (Barry Song) <[e-mail]>;
> > [e-mail]; [e-mail];
> > [e-mail]; [e-mail];
> > [e-mail]; Linuxarm <[e-mail]>
> > Subject: Re: [PATCH] arm64: mm: add support for memmap kernel parameters
> >
> > On Wed, Nov 18, 2020 at 07:38:54PM +0200, Mike Rapoport wrote:
> > > On Wed, Nov 18, 2020 at 07:33:14PM +1300, Barry Song wrote:
> > > > memmap should be an useful kernel parameter which has been supported
> > by
> > > > x86, mips and xtensa.
> > >
> > > Why is this parameter should be useful for ARM64?
> > > My understanding is that it is required only to work around really
> > > broken bootloaders, isn't it?
> >
>
> Good question. Originally I wrote this patch to debug and verify the vmemmap
> leak issue reported in this patch:
> [PATCH v2] arm64: mm: free unused memmap for sparse memory model that define VMEMMAP
> https://lore.kernel.org/linux-arm-kernel/[e-mail]/
> I don't have a machine which really has holes in memory_section to debug, but memmap
> can help. With memmap, I could specified a machine with various holds in mem_sections.
>
> After that, I figured out this is not only useful for debugging purpose. it can have some real user cases.
> For example:
>
> 1. DAX on DRAM.
> kernel parameter memmap=XG!YG specifies a range of RAM to emulate pmem. Then we are able
> to run DAX and filesystem on top of it. Furthermore, this will probably also benefit the case
> this big patchset wants to "fix" via direct access to memory:
> https://lore.kernel.org/lkml/[e-mail]/T/#m1a77074b8e1dadc590a5f45a52d9c3cda69c0780
> as the comments have clearly shown.
>
> 2. reserve some memory for userspace to manage via /dev/mem
>

Apologies for the bluntness, but what you are saying here is that you
need a hack to pile those other hacks onto.

Currently, we use the NOMAP attribute in memblock to describe memory
that is omitted from the direct map. Removing memory from memblock
entirely also strips it of this annotation, which means that
phys_mem_access_prot() will identify it as device memory not DRAM, and
use the wrong attributes when using /dev/mem.

There are likely other places where this distinction matters, and so I
am not buying the justification that we can make meaningful use of
this memory in the general case, and anything that relies on it will
be fragile, and probably only limited to very specific debug
scenarios.

So I don't think we should merge this.


>
> > Agreed, I can't see this being something we really want to support. If it
> > turns out that it is generally useful, then the implementation should
> > probably be somewhere outside of arch/ where I don't have to look at it :)
> >
>
> What stops this becoming common code is that each platform has different ways
> and boot sequences to populate memblock.
> For example, on Arm64, while early_param is populated, dt has populated
> memblock before that. Other platforms might been much different.
>
> > Will
>
> Thanks
> Barry
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> [e-mail]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Song Bao Hua (Barry Song) Nov. 18, 2020, 11:55 p.m. UTC | #5

> -----Original Message-----
> From: Ard Biesheuvel [mailto:[e-mail]]
> Sent: Thursday, November 19, 2020 11:38 AM
> To: Song Bao Hua (Barry Song) <[e-mail]>
> Cc: Will Deacon <[e-mail]>; Mike Rapoport <[e-mail]>;
> [e-mail]; [e-mail]; Linuxarm
> <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: [PATCH] arm64: mm: add support for memmap kernel parameters
> 
> On Wed, 18 Nov 2020 at 21:27, Song Bao Hua (Barry Song)
> <[e-mail]> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Will Deacon [mailto:[e-mail]]
> > > Sent: Thursday, November 19, 2020 8:15 AM
> > > To: Mike Rapoport <[e-mail]>
> > > Cc: Song Bao Hua (Barry Song) <[e-mail]>;
> > > [e-mail]; [e-mail];
> > > [e-mail]; [e-mail];
> > > [e-mail]; Linuxarm <[e-mail]>
> > > Subject: Re: [PATCH] arm64: mm: add support for memmap kernel
> parameters
> > >
> > > On Wed, Nov 18, 2020 at 07:38:54PM +0200, Mike Rapoport wrote:
> > > > On Wed, Nov 18, 2020 at 07:33:14PM +1300, Barry Song wrote:
> > > > > memmap should be an useful kernel parameter which has been
> supported
> > > by
> > > > > x86, mips and xtensa.
> > > >
> > > > Why is this parameter should be useful for ARM64?
> > > > My understanding is that it is required only to work around really
> > > > broken bootloaders, isn't it?
> > >
> >
> > Good question. Originally I wrote this patch to debug and verify the
> vmemmap
> > leak issue reported in this patch:
> > [PATCH v2] arm64: mm: free unused memmap for sparse memory model that
> define VMEMMAP
> >
> https://lore.kernel.org/linux-arm-kernel/20200812010655.96339-1-liwei213@
> huawei.com/
> > I don't have a machine which really has holes in memory_section to debug,
> but memmap
> > can help. With memmap, I could specified a machine with various holds in
> mem_sections.
> >
> > After that, I figured out this is not only useful for debugging purpose. it can
> have some real user cases.
> > For example:
> >
> > 1. DAX on DRAM.
> > kernel parameter memmap=XG!YG specifies a range of RAM to emulate
> pmem. Then we are able
> > to run DAX and filesystem on top of it. Furthermore, this will probably also
> benefit the case
> > this big patchset wants to "fix" via direct access to memory:
> >
> https://lore.kernel.org/lkml/[e-mail]/T
> /#m1a77074b8e1dadc590a5f45a52d9c3cda69c0780
> > as the comments have clearly shown.
> >
> > 2. reserve some memory for userspace to manage via /dev/mem
> >
> 
> Apologies for the bluntness, but what you are saying here is that you
> need a hack to pile those other hacks onto.
> 
> Currently, we use the NOMAP attribute in memblock to describe memory
> that is omitted from the direct map. Removing memory from memblock
> entirely also strips it of this annotation, which means that
> phys_mem_access_prot() will identify it as device memory not DRAM, and
> use the wrong attributes when using /dev/mem.
> 
> There are likely other places where this distinction matters, and so I
> am not buying the justification that we can make meaningful use of
> this memory in the general case, and anything that relies on it will
> be fragile, and probably only limited to very specific debug
> scenarios.

Yep. originally I did that for debugging purpose to emulate a machine with
some holes in mem_section. I guess it should be also useful to other people
if they need the same thing for debugging.

> 
> So I don't think we should merge this.

It should be in the same situation for other platforms like x86, mips and xtensa
but they have enabled this kernel parameter.

maybe the emulated pmem by DRAM is an useful scenario other than debugging.

Later, https://lore.kernel.org/lkml/[e-mail]/T/#m1a77074b8e1dadc590a5f45a52d9c3cda69c0780
might be able to use this parameter.

Anyway, I don't mind keeping it local for debugging at this stage and waiting for a
more convincing use case.

> 
> 
> >
> > > Agreed, I can't see this being something we really want to support. If it
> > > turns out that it is generally useful, then the implementation should
> > > probably be somewhere outside of arch/ where I don't have to look at it :)
> > >
> >
> > What stops this becoming common code is that each platform has different
> ways
> > and boot sequences to populate memblock.
> > For example, on Arm64, while early_param is populated, dt has populated
> > memblock before that. Other platforms might been much different.
> >
> > > Will
> >

Thanks
Barry

Mike Rapoport Nov. 19, 2020, 7:57 a.m. UTC | #6

On Wed, Nov 18, 2020 at 11:55:33PM +0000, Song Bao Hua (Barry Song) wrote:
> > From: Ard Biesheuvel [mailto:[e-mail]]
> > 
> > On Wed, 18 Nov 2020 at 21:27, Song Bao Hua (Barry Song)
> > <[e-mail]> wrote:
> > >
> > > Good question. Originally I wrote this patch to debug and verify the
> > vmemmap
> > > leak issue reported in this patch:
> > > [PATCH v2] arm64: mm: free unused memmap for sparse memory model that
> > define VMEMMAP
> > >
> > https://lore.kernel.org/linux-arm-kernel/20200812010655.96339-1-liwei213@
> > huawei.com/
> > > I don't have a machine which really has holes in memory_section to debug,
> > but memmap
> > > can help. With memmap, I could specified a machine with various holds in
> > mem_sections.
> > >
> > > After that, I figured out this is not only useful for debugging purpose. it can
> > have some real user cases.
> > > For example:
> > >
> > > 1. DAX on DRAM.
> > > kernel parameter memmap=XG!YG specifies a range of RAM to emulate
> > pmem. Then we are able
> > > to run DAX and filesystem on top of it. Furthermore, this will probably also
> > benefit the case
> > > this big patchset wants to "fix" via direct access to memory:
> > >
> > https://lore.kernel.org/lkml/[e-mail]/T
> > /#m1a77074b8e1dadc590a5f45a52d9c3cda69c0780
> > > as the comments have clearly shown.
> > >
> > > 2. reserve some memory for userspace to manage via /dev/mem
> > >
> > 
> > Apologies for the bluntness, but what you are saying here is that you
> > need a hack to pile those other hacks onto.
> > 
> > Currently, we use the NOMAP attribute in memblock to describe memory
> > that is omitted from the direct map. Removing memory from memblock
> > entirely also strips it of this annotation, which means that
> > phys_mem_access_prot() will identify it as device memory not DRAM, and
> > use the wrong attributes when using /dev/mem.
> > 
> > There are likely other places where this distinction matters, and so I
> > am not buying the justification that we can make meaningful use of
> > this memory in the general case, and anything that relies on it will
> > be fragile, and probably only limited to very specific debug
> > scenarios.
> 
> Yep. originally I did that for debugging purpose to emulate a machine with
> some holes in mem_section. I guess it should be also useful to other people
> if they need the same thing for debugging.
> 
> > 
> > So I don't think we should merge this.
> 
> It should be in the same situation for other platforms like x86, mips and xtensa
> but they have enabled this kernel parameter.

I didn't check mips and xtensa, but x86 carries this from nineties when
they needed a way to work around broken BIOSes.
I really doubt x86 maintainers would merge such feature these days.
 
> maybe the emulated pmem by DRAM is an useful scenario other than debugging.
> 
> Later, https://lore.kernel.org/lkml/[e-mail]/T/#m1a77074b8e1dadc590a5f45a52d9c3cda69c0780
> might be able to use this parameter.

Using kernel parameters to describe complex memory configuration does
not seem scalable and maintainable. 
A simple mem=X should be enough for features like dmemfs to start with
and if/when anything more complex will be required I doubt a kernel
parameter would fit that purpose.

Another thing as as soon as we expose this parameter to the user we'd
have to make sure they can always get the memory layout they defined
with it. Keeping the kernel parameter in sync with other means of memory
detection would complicate things on both sides. Ard mentioned NOMAP
property, there may be some NUMA considerations that could create a
conflict between what user asked and what is possible and other things
that may come up in the future. 

> Anyway, I don't mind keeping it local for debugging at this stage and waiting for a
> more convincing use case.
> 
> Thanks
> Barry
>

Song Bao Hua (Barry Song) Nov. 19, 2020, 8:37 a.m. UTC | #7

> -----Original Message-----
> From: Mike Rapoport [mailto:[e-mail]]
> Sent: Thursday, November 19, 2020 8:57 PM
> To: Song Bao Hua (Barry Song) <[e-mail]>
> Cc: Ard Biesheuvel <[e-mail]>; Will Deacon <[e-mail]>;
> [e-mail]; [e-mail]; Linuxarm
> <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: [PATCH] arm64: mm: add support for memmap kernel parameters
> 
> On Wed, Nov 18, 2020 at 11:55:33PM +0000, Song Bao Hua (Barry Song)
> wrote:
> > > From: Ard Biesheuvel [mailto:[e-mail]]
> > >
> > > On Wed, 18 Nov 2020 at 21:27, Song Bao Hua (Barry Song)
> > > <[e-mail]> wrote:
> > > >
> > > > Good question. Originally I wrote this patch to debug and verify the
> > > vmemmap
> > > > leak issue reported in this patch:
> > > > [PATCH v2] arm64: mm: free unused memmap for sparse memory model
> that
> > > define VMEMMAP
> > > >
> > >
> https://lore.kernel.org/linux-arm-kernel/20200812010655.96339-1-liwei213@
> > > huawei.com/
> > > > I don't have a machine which really has holes in memory_section to
> debug,
> > > but memmap
> > > > can help. With memmap, I could specified a machine with various holds in
> > > mem_sections.
> > > >
> > > > After that, I figured out this is not only useful for debugging purpose. it
> can
> > > have some real user cases.
> > > > For example:
> > > >
> > > > 1. DAX on DRAM.
> > > > kernel parameter memmap=XG!YG specifies a range of RAM to emulate
> > > pmem. Then we are able
> > > > to run DAX and filesystem on top of it. Furthermore, this will probably
> also
> > > benefit the case
> > > > this big patchset wants to "fix" via direct access to memory:
> > > >
> > >
> https://lore.kernel.org/lkml/[e-mail]/T
> > > /#m1a77074b8e1dadc590a5f45a52d9c3cda69c0780
> > > > as the comments have clearly shown.
> > > >
> > > > 2. reserve some memory for userspace to manage via /dev/mem
> > > >
> > >
> > > Apologies for the bluntness, but what you are saying here is that you
> > > need a hack to pile those other hacks onto.
> > >
> > > Currently, we use the NOMAP attribute in memblock to describe memory
> > > that is omitted from the direct map. Removing memory from memblock
> > > entirely also strips it of this annotation, which means that
> > > phys_mem_access_prot() will identify it as device memory not DRAM, and
> > > use the wrong attributes when using /dev/mem.
> > >
> > > There are likely other places where this distinction matters, and so I
> > > am not buying the justification that we can make meaningful use of
> > > this memory in the general case, and anything that relies on it will
> > > be fragile, and probably only limited to very specific debug
> > > scenarios.
> >
> > Yep. originally I did that for debugging purpose to emulate a machine with
> > some holes in mem_section. I guess it should be also useful to other people
> > if they need the same thing for debugging.
> >
> > >
> > > So I don't think we should merge this.
> >
> > It should be in the same situation for other platforms like x86, mips and
> xtensa
> > but they have enabled this kernel parameter.
> 
> I didn't check mips and xtensa, but x86 carries this from nineties when
> they needed a way to work around broken BIOSes.
> I really doubt x86 maintainers would merge such feature these days.
> 
> > maybe the emulated pmem by DRAM is an useful scenario other than
> debugging.
> >
> > Later,
> https://lore.kernel.org/lkml/[e-mail]/T
> /#m1a77074b8e1dadc590a5f45a52d9c3cda69c0780
> > might be able to use this parameter.
> 
> Using kernel parameters to describe complex memory configuration does
> not seem scalable and maintainable.
> A simple mem=X should be enough for features like dmemfs to start with
> and if/when anything more complex will be required I doubt a kernel
> parameter would fit that purpose.
> 
> Another thing as as soon as we expose this parameter to the user we'd
> have to make sure they can always get the memory layout they defined
> with it. Keeping the kernel parameter in sync with other means of memory
> detection would complicate things on both sides. Ard mentioned NOMAP
> property, there may be some NUMA considerations that could create a
> conflict between what user asked and what is possible and other things
> that may come up in the future.
> 

I agree with you in general. I made this patch for debugging purpose to
emulate all kinds of memory holes in memory section of SPARSE_VMEMMAP. 
memmap is documented in kernel, so I believed that was the way for me to
seek for a generic debug method. This "memmap=" patch on arm64 has helped
me much for debugging. so I guess someone else might have the same
requirement someday, then they can use it. For myself, I haven't used it for
any purpose other than debugging.

So I won't try to convince people to merge this patch any more :-)

Regarding the sync issue between the parameter and the users who need
the memory, pmem emulated by DRAM is doing like this:
each "memmap=A!B" will become a /dev/pmem<index>, users just use
the /dev/pmem0, /dev/pmem1 things and don't need to know the real
address. Of course, it seems this is not that decent too.

> > Anyway, I don't mind keeping it local for debugging at this stage and waiting
> for a
> > more convincing use case.
> >

Thanks
Barry

Patch

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 095540667f0f..f1c6bfdbc953 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -235,6 +235,65 @@  static int __init early_mem(char *p)
 }
 early_param("mem", early_mem);
 
+static int need_remove_real_memblock __initdata;
+
+static void __init parse_memmap_one(char *p)
+{
+	char *oldp;
+	unsigned long start_at, mem_size;
+
+	if (!p)
+		return;
+
+	if (!strncmp(p, "exactmap", 8)) {
+		need_remove_real_memblock = 1;
+		return;
+	}
+
+	oldp = p;
+	mem_size = memparse(p, &p);
+	if (p == oldp)
+		return;
+
+	switch (*p) {
+	case '@':
+		start_at = memparse(p + 1, &p);
+		/*
+		 * use the exactmap defined by nn[KMG]@ss[KMG], remove
+		 * memblock populated by DT etc.
+		 */
+		if (need_remove_real_memblock) {
+			need_remove_real_memblock = 0;
+			memblock_remove(0, ULLONG_MAX);
+		}
+		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);
+
 static int __init early_init_dt_scan_usablemem(unsigned long node,
 		const char *uname, int depth, void *data)
 {