linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: Frank van der Linden <fllinden@amazon.com>
Cc: linux-arm-kernel@lists.infradead.org, robh+dt@kernel.org,
	frowand.list@gmail.com, ardb@kernel.org, linux-mm@kvack.org,
	devicetree@vger.kernel.org, linux-efi@vger.kernel.org,
	linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
	catalin.marinas@arm.com, will@kernel.org,
	geert+renesas@glider.be
Subject: Re: [PATCH 1/3] memblock: define functions to set the usable memory range
Date: Thu, 13 Jan 2022 19:33:11 +0200	[thread overview]
Message-ID: <YeBiV8fuCCLWyHYb@kernel.org> (raw)
In-Reply-To: <20220111204441.GA36458@dev-dsk-fllinden-2c-d7720709.us-west-2.amazon.com>

On Tue, Jan 11, 2022 at 08:44:41PM +0000, Frank van der Linden wrote:
> On Tue, Jan 11, 2022 at 12:31:58PM +0200, Mike Rapoport wrote:
> > > --- a/include/linux/memblock.h
> > > +++ b/include/linux/memblock.h
> > > @@ -481,6 +481,8 @@ phys_addr_t memblock_reserved_size(void);
> > >  phys_addr_t memblock_start_of_DRAM(void);
> > >  phys_addr_t memblock_end_of_DRAM(void);
> > >  void memblock_enforce_memory_limit(phys_addr_t memory_limit);
> > > +void memblock_set_usable_range(phys_addr_t base, phys_addr_t size);
> > > +void memblock_enforce_usable_range(void);
> > >  void memblock_cap_memory_range(phys_addr_t base, phys_addr_t size);
> > >  void memblock_mem_limit_remove_map(phys_addr_t limit);
> > 
> > We already have 3 very similar interfaces that deal with memory capping.
> > Now you suggest to add fourth that will "generically" solve a single use
> > case of DT, EFI and kdump interaction on arm64.
> > 
> > Looks like a workaround for a fundamental issue of incompatibility between
> > DT and EFI wrt memory registration.
> 
> Yep, I figured this would be the main argument against this - arm64
> already added several other more-or-less special cased interfaces over
> time.
> 
> I'm more than happy to solve this in a different way.
> 
> What would you suggest:
> 
> 1) Try to merge the similar interfaces in to one.
> 2) Just deal with it at a lower (arm64) level?
> 3) Some other way?

We've discussed this with Ard on IRC, and our conclusion was that on arm64
kdump kernel should have memblock.memory exactly the same as the normal
kernel. Then, the memory outside usable-memory-range should be reserved so
that kdump kernel won't step over it.

With that, simple (untested) patch below could be what we need:

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index bdca35284ceb..371418dffaf1 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -1275,7 +1275,8 @@ void __init early_init_dt_scan_nodes(void)
 	of_scan_flat_dt(early_init_dt_scan_memory, NULL);
 
 	/* Handle linux,usable-memory-range property */
-	memblock_cap_memory_range(cap_mem_addr, cap_mem_size);
+	memblock_reserve(0, cap_mem_addr);
+	memblock_reserve(cap_mem_addr + cap_mem_size, PHYS_ADDR_MAX);
 }
 
 bool __init early_init_dt_scan(void *params)

> Thanks,
> 
> - Frank
> 

-- 
Sincerely yours,
Mike.


  parent reply	other threads:[~2022-01-13 17:33 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-10 21:08 [PATCH 0/3] usable memory range fixes (arm64/fdt/efi) Frank van der Linden
2022-01-10 21:08 ` [PATCH 1/3] memblock: define functions to set the usable memory range Frank van der Linden
2022-01-11 10:31   ` Mike Rapoport
2022-01-11 20:44     ` Frank van der Linden
2022-01-12 18:05       ` Mike Rapoport
2022-01-13 17:33       ` Mike Rapoport [this message]
2022-01-14  0:10         ` Frank van der Linden
2022-01-14  0:22           ` Frank van der Linden
2022-01-14 23:27         ` Frank van der Linden
2022-01-24 21:05     ` Frank van der Linden
2022-01-29 16:19       ` Ard Biesheuvel
2022-01-10 21:08 ` [PATCH 2/3] of: fdt: use memblock usable range interface Frank van der Linden
2022-01-10 21:08 ` [PATCH 3/3] efi: enforce usable memory range after reserving regions Frank van der Linden

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YeBiV8fuCCLWyHYb@kernel.org \
    --to=rppt@kernel.org \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=fllinden@amazon.com \
    --cc=frowand.list@gmail.com \
    --cc=geert+renesas@glider.be \
    --cc=kexec@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=robh+dt@kernel.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox