linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] arm64: set MAX_MEMBLOCK_ADDR according to linear region size
Date: Thu, 20 Aug 2015 10:17:45 +0100	[thread overview]
Message-ID: <20150820091745.GA2972@e104818-lin.cambridge.arm.com> (raw)
In-Reply-To: <CAKv+Gu8BVJF9MEsRRonprEkyhvrbTsWdUnz0wQyi2zUNAd_bpg@mail.gmail.com>

On Thu, Aug 20, 2015 at 07:09:25AM +0200, Ard Biesheuvel wrote:
> On 18 August 2015 at 19:39, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > On Tue, Aug 18, 2015 at 12:04:27PM +0200, Ard Biesheuvel wrote:
> >> On 18 August 2015 at 12:00, Will Deacon <will.deacon@arm.com> wrote:
> >> > On Tue, Aug 18, 2015 at 10:34:42AM +0100, Ard Biesheuvel wrote:
> >> >> The linear region size of a 39-bit VA kernel is only 256 GB, which
> >> >> may be insufficient to cover all of system RAM, even on platforms
> >> >> that have much less than 256 GB of memory but which is laid out
> >> >> very sparsely.
> >> >>
> >> >> So make sure we clip the memory we will not be able to map before
> >> >> installing it into the memblock memory table, by setting
> >> >> MAX_MEMBLOCK_ADDR accordingly.
> >> >>
> >> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >> >> ---
> >> >>  arch/arm64/include/asm/memory.h | 8 ++++++++
> >> >>  1 file changed, 8 insertions(+)
> >> >>
> >> >> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> >> >> index f800d45ea226..44a59c20e773 100644
> >> >> --- a/arch/arm64/include/asm/memory.h
> >> >> +++ b/arch/arm64/include/asm/memory.h
> >> >> @@ -114,6 +114,14 @@ extern phys_addr_t               memstart_addr;
> >> >>  #define PHYS_OFFSET          ({ memstart_addr; })
> >> >>
> >> >>  /*
> >> >> + * The maximum physical address that the linear direct mapping
> >> >> + * of system RAM can cover. (PAGE_OFFSET can be interpreted as
> >> >> + * a 2's complement signed quantity and negated to derive the
> >> >> + * maximum size of the linear mapping.)
> >> >> + */
> >> >> +#define MAX_MEMBLOCK_ADDR    ({ memstart_addr - PAGE_OFFSET - 1; })
> >> >
> >> > If we initialised memory_limit to this value and changed early_mem to
> >> > use min (i.e. only restrict the limit further), would that avoid the
> >> > need to change the of code? It looks like PPC uses
> >> > memblock_enforce_memory_limit for similar reasons.
> >>
> >> Yes, that would be yet another way of doing things. But since Catalin
> >> explicitly requested that both checks (i.e., bottom end and top end)
> >> occur in the same place, and indicated his preference not to override
> >> early_init_dt_add_memory_arch() if we can avoid it, the only way is to
> >> hack it in there.
> >
> > Talking to Will, we decided to go for a quick fix with cc stable that
> > does something like:
> >
> >         memblock_enforce_memory_limit(min(memory_limit, ~PAGE_OFFSET));
> 
> Actually, this won't work. The function limits the /amount/ of memory,
> and disregards holes when doing so.

Ah, we missed this (but its behaviour makes sense, it's meant for mem=
arguments).

-- 
Catalin

  reply	other threads:[~2015-08-20  9:17 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-18  9:34 [PATCH 0/2] arm64: ignore memory outside of the linear range Ard Biesheuvel
2015-08-18  9:34 ` [PATCH 1/2] of/fdt: make memblock maximum physical address arch configurable Ard Biesheuvel
2015-08-20  9:18   ` Catalin Marinas
2015-08-23 22:01   ` Rob Herring
2015-08-18  9:34 ` [PATCH 2/2] arm64: set MAX_MEMBLOCK_ADDR according to linear region size Ard Biesheuvel
2015-08-18 10:00   ` Will Deacon
2015-08-18 10:04     ` Ard Biesheuvel
2015-08-18 17:39       ` Catalin Marinas
2015-08-18 17:44         ` Ard Biesheuvel
2015-08-19  9:15           ` Catalin Marinas
2015-08-20  5:09         ` Ard Biesheuvel
2015-08-20  9:17           ` Catalin Marinas [this message]
2015-08-18 14:24     ` Catalin Marinas
2015-08-18 14:31       ` Ard Biesheuvel
2015-08-18 14:38         ` Ard Biesheuvel
2015-08-18 14:51       ` Russell King - ARM Linux
2015-08-18 16:16         ` Catalin Marinas
2015-08-20  9:19   ` Catalin Marinas
2015-08-20 11:54     ` Ard Biesheuvel
2015-08-20 12:50       ` Catalin Marinas
2015-08-18 14:18 ` [PATCH 0/2] arm64: ignore memory outside of the linear range Stuart Yoder
2015-08-24  8:00   ` Ard Biesheuvel
2015-08-24  9:22     ` Will Deacon
2015-08-24 13:58       ` Stuart Yoder
2015-08-24 14:08         ` Will Deacon
2015-08-24 22:34           ` Stuart Yoder
2015-08-25  9:45             ` Ard Biesheuvel
2015-08-25  9:54               ` Russell King - ARM Linux
2015-08-25 10:02               ` Will Deacon
2015-08-25 10:10                 ` Ard Biesheuvel

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=20150820091745.GA2972@e104818-lin.cambridge.arm.com \
    --to=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).