All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: kexec@lists.infradead.org
Subject: [PATCH 1/3] memblock: define functions to set the usable memory range
Date: Wed, 12 Jan 2022 20:05:41 +0200	[thread overview]
Message-ID: <Yd8Yda7oadoB1E+w@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.

This could be a nice cleanup regardless of how we handle
"linux,usable-memory-range".

> 2) Just deal with it at a lower (arm64) level?

Probably it will be the simplest solution in the short term.

> 3) Some other way?

I'm not expert enough on DT and EFI to see how they communicate the
linux,usable-memory-range property. 

One thought I have is since we already create a DT for kexec/kdump why
can't we add some data to EFI memory description similar to
linux,usable-memore-range?

Another thing is, if we could presume that DT and EFI are consistent in
their view what is the span of the physical memory, we could drop
memblock_remove(EVERYTHIING) and early_init_dt_add_memory_arch() from
efi_init::reserve_regions() and then the loop over EFI memory descriptors
will only take care of reserved and nomap regions.

> Thanks,
> 
> - Frank
> 

-- 
Sincerely yours,
Mike.


WARNING: multiple messages have this Message-ID (diff)
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: Wed, 12 Jan 2022 20:05:41 +0200	[thread overview]
Message-ID: <Yd8Yda7oadoB1E+w@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.

This could be a nice cleanup regardless of how we handle
"linux,usable-memory-range".

> 2) Just deal with it at a lower (arm64) level?

Probably it will be the simplest solution in the short term.

> 3) Some other way?

I'm not expert enough on DT and EFI to see how they communicate the
linux,usable-memory-range property. 

One thought I have is since we already create a DT for kexec/kdump why
can't we add some data to EFI memory description similar to
linux,usable-memore-range?

Another thing is, if we could presume that DT and EFI are consistent in
their view what is the span of the physical memory, we could drop
memblock_remove(EVERYTHIING) and early_init_dt_add_memory_arch() from
efi_init::reserve_regions() and then the loop over EFI memory descriptors
will only take care of reserved and nomap regions.

> Thanks,
> 
> - Frank
> 

-- 
Sincerely yours,
Mike.

WARNING: multiple messages have this Message-ID (diff)
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: Wed, 12 Jan 2022 20:05:41 +0200	[thread overview]
Message-ID: <Yd8Yda7oadoB1E+w@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.

This could be a nice cleanup regardless of how we handle
"linux,usable-memory-range".

> 2) Just deal with it at a lower (arm64) level?

Probably it will be the simplest solution in the short term.

> 3) Some other way?

I'm not expert enough on DT and EFI to see how they communicate the
linux,usable-memory-range property. 

One thought I have is since we already create a DT for kexec/kdump why
can't we add some data to EFI memory description similar to
linux,usable-memore-range?

Another thing is, if we could presume that DT and EFI are consistent in
their view what is the span of the physical memory, we could drop
memblock_remove(EVERYTHIING) and early_init_dt_add_memory_arch() from
efi_init::reserve_regions() and then the loop over EFI memory descriptors
will only take care of reserved and nomap regions.

> Thanks,
> 
> - Frank
> 

-- 
Sincerely yours,
Mike.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-01-12 18:05 UTC|newest]

Thread overview: 39+ 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 ` Frank van der Linden
2022-01-10 21:08 ` 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-10 21:08   ` Frank van der Linden
2022-01-10 21:08   ` Frank van der Linden
2022-01-11 10:31   ` Mike Rapoport
2022-01-11 10:31     ` Mike Rapoport
2022-01-11 10:31     ` Mike Rapoport
2022-01-11 20:44     ` Frank van der Linden
2022-01-11 20:44       ` Frank van der Linden
2022-01-11 20:44       ` Frank van der Linden
2022-01-12 18:05       ` Mike Rapoport [this message]
2022-01-12 18:05         ` Mike Rapoport
2022-01-12 18:05         ` Mike Rapoport
2022-01-13 17:33       ` Mike Rapoport
2022-01-13 17:33         ` Mike Rapoport
2022-01-13 17:33         ` Mike Rapoport
2022-01-14  0:10         ` Frank van der Linden
2022-01-14  0:10           ` Frank van der Linden
2022-01-14  0:10           ` Frank van der Linden
2022-01-14  0:22           ` Frank van der Linden
2022-01-14  0:22             ` Frank van der Linden
2022-01-14  0:22             ` Frank van der Linden
2022-01-14 23:27         ` Frank van der Linden
2022-01-14 23:27           ` Frank van der Linden
2022-01-14 23:27           ` Frank van der Linden
2022-01-24 21:05     ` Frank van der Linden
2022-01-24 21:05       ` Frank van der Linden
2022-01-24 21:05       ` Frank van der Linden
2022-01-29 16:19       ` Ard Biesheuvel
2022-01-29 16:19         ` Ard Biesheuvel
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   ` Frank van der Linden
2022-01-10 21:08   ` Frank van der Linden
2022-01-10 21:08 ` [PATCH 3/3] efi: enforce usable memory range after reserving regions Frank van der Linden
2022-01-10 21:08   ` Frank van der Linden
2022-01-10 21:08   ` 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=Yd8Yda7oadoB1E+w@kernel.org \
    --to=rppt@kernel.org \
    --cc=kexec@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.