From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 RESEND 05/17] ARM: LPAE: support 64-bit virt_to_phys patching
Date: Tue, 25 Sep 2012 14:53:43 +0100 [thread overview]
Message-ID: <20120925135343.GD14924@arm.com> (raw)
In-Reply-To: <alpine.LFD.2.02.1209241826260.6667@xanadu.home>
On Mon, Sep 24, 2012 at 11:32:22PM +0100, Nicolas Pitre wrote:
> On Mon, 24 Sep 2012, Catalin Marinas wrote:
>
> > On 24 September 2012 22:20, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > > On Mon, 24 Sep 2012, Cyril Chemparathy wrote:
> > >
> > >> On 9/24/2012 11:56 AM, Nicolas Pitre wrote:
> > >> > On Mon, 24 Sep 2012, Catalin Marinas wrote:
> > >> >
> > >> > > On Fri, Sep 21, 2012 at 04:56:03PM +0100, Cyril Chemparathy wrote:
> > >> > > > This patch adds support for 64-bit physical addresses in virt_to_phys()
> > >> > > > patching. This does not do real 64-bit add/sub, but instead patches in
> > >> > > > the
> > >> > > > upper 32-bits of the phys_offset directly into the output of
> > >> > > > virt_to_phys.
> > >> > >
> > >> > > So this assumes that for the kernel linear mapping, all the physical
> > >> > > addresses have the same upper 32-bit. That's a good optimisation but I
> > >> > > haven't seen this check when calculating lowmem in sanity_check_meminfo.
> > >> > > Someone may build platform with memory starting at 3GB and going across
> > >> > > the 4GB limit.
> > >> >
> > >> > Good point. We better get an early warning if that happens.
> > >> >
> > >>
> > >> Thanks.
> > >>
> > >> I'm thinking of splitting the bank at the 32-bit boundary in such an event,
> > >> assuming that the remaining memory should be usable as highmem.
> > >
> > > No. That's not the point here.
> > >
> > > Let's suppose a system with 1GB of physical RAM starting at 0xe0000000.
> > >
> > > In this case there is no need for highmem. However the v2p patching
> > > code in the LPAE case assumes the high bits of a physical address are
> > > always the same which wouldn't be the case in this hypothetical example.
> > >
> > > We want to make sure the kernel won't boot if a system with physical RAM
> > > crossing the 4GB address mark is encountered.
> >
> > I think that's too restrictive. The case with 1 or 2GB below 4GB limit
> > and the rest of the RAM above is a valid one.
>
> Valid: sure. Likely: probably not. That would complicate address
> decoding in hardware for little gain.
You could have a block of 4GB RAM at 0x100000000 but the top 2GB aliased
at 0x80000000. It is also possible that the top 2GB are not visible to
software directly but only via the 0x80000000 alias.
But with Russell's proposal for full 64-bit address patching, no
limitations are needed.
--
Catalin
next prev parent reply other threads:[~2012-09-25 13:53 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-21 15:55 [PATCH v3 RESEND 00/17] LPAE fixes and extensions for Keystone Cyril Chemparathy
2012-09-21 15:55 ` [PATCH v3 RESEND 01/17] ARM: add mechanism for late code patching Cyril Chemparathy
2012-09-22 15:10 ` Nicolas Pitre
2012-09-22 21:41 ` Cyril Chemparathy
2012-09-24 12:06 ` Dave Martin
2012-09-24 14:49 ` Cyril Chemparathy
2012-09-24 15:54 ` Dave Martin
2012-09-21 15:56 ` [PATCH v3 RESEND 02/17] ARM: add self test for runtime patch mechanism Cyril Chemparathy
2012-09-21 15:56 ` [PATCH v3 RESEND 03/17] ARM: use late patch framework for phys-virt patching Cyril Chemparathy
2012-09-21 15:56 ` [PATCH v3 RESEND 04/17] ARM: LPAE: use phys_addr_t on virt <--> phys conversion Cyril Chemparathy
2012-09-24 13:09 ` Catalin Marinas
2012-09-24 13:57 ` Cyril Chemparathy
2012-09-21 15:56 ` [PATCH v3 RESEND 05/17] ARM: LPAE: support 64-bit virt_to_phys patching Cyril Chemparathy
2012-09-22 15:24 ` Nicolas Pitre
2012-09-24 15:13 ` Catalin Marinas
2012-09-24 15:56 ` Nicolas Pitre
2012-09-24 20:59 ` Cyril Chemparathy
2012-09-24 21:20 ` Nicolas Pitre
2012-09-24 21:52 ` Catalin Marinas
2012-09-24 22:32 ` Nicolas Pitre
2012-09-24 22:40 ` Russell King - ARM Linux
2012-09-24 22:53 ` Cyril Chemparathy
2012-09-24 23:03 ` Nicolas Pitre
2012-09-24 23:08 ` Russell King - ARM Linux
2012-09-24 22:55 ` Nicolas Pitre
2012-09-25 12:55 ` Dave Martin
2012-09-25 13:53 ` Catalin Marinas [this message]
2012-09-24 21:53 ` Cyril Chemparathy
2012-09-24 22:06 ` Russell King - ARM Linux
2012-09-24 16:31 ` Dave Martin
2012-09-24 16:51 ` Nicolas Pitre
2012-09-21 15:56 ` [PATCH v3 RESEND 06/17] ARM: LPAE: use signed arithmetic for mask definitions Cyril Chemparathy
2012-09-24 13:09 ` Catalin Marinas
2012-09-24 13:54 ` Russell King - ARM Linux
2012-09-21 15:56 ` [PATCH v3 RESEND 07/17] ARM: LPAE: use phys_addr_t in alloc_init_pud() Cyril Chemparathy
2012-09-24 13:10 ` Catalin Marinas
2012-09-21 15:56 ` [PATCH v3 RESEND 08/17] ARM: LPAE: use phys_addr_t in free_memmap() Cyril Chemparathy
2012-09-24 13:29 ` Catalin Marinas
2012-09-24 13:41 ` Russell King - ARM Linux
2012-09-24 15:09 ` Cyril Chemparathy
2012-09-24 15:22 ` Russell King - ARM Linux
2012-09-24 16:41 ` Cyril Chemparathy
2012-09-24 16:51 ` Catalin Marinas
2012-09-24 17:06 ` Cyril Chemparathy
2012-09-24 17:14 ` Russell King - ARM Linux
2012-09-25 13:08 ` Catalin Marinas
2012-09-25 13:30 ` Russell King - ARM Linux
2012-09-24 16:55 ` Russell King - ARM Linux
2012-09-24 17:03 ` Catalin Marinas
2012-09-21 15:56 ` [PATCH v3 RESEND 09/17] ARM: LPAE: use phys_addr_t for initrd location and size Cyril Chemparathy
2012-09-24 13:30 ` Catalin Marinas
2012-09-24 13:38 ` Russell King - ARM Linux
2012-09-24 14:00 ` Cyril Chemparathy
2012-09-21 15:56 ` [PATCH v3 RESEND 10/17] ARM: LPAE: use phys_addr_t in switch_mm() Cyril Chemparathy
2012-09-24 14:05 ` Catalin Marinas
2012-09-24 14:32 ` Cyril Chemparathy
2012-09-21 15:56 ` [PATCH v3 RESEND 11/17] ARM: LPAE: use 64-bit accessors for TTBR registers Cyril Chemparathy
2012-09-24 14:10 ` Catalin Marinas
2012-09-21 15:56 ` [PATCH v3 RESEND 12/17] ARM: LPAE: define ARCH_LOW_ADDRESS_LIMIT for bootmem Cyril Chemparathy
2012-09-24 14:16 ` Catalin Marinas
2012-09-21 15:56 ` [PATCH v3 RESEND 13/17] ARM: LPAE: factor out T1SZ and TTBR1 computations Cyril Chemparathy
2012-09-24 14:45 ` Catalin Marinas
2012-09-24 14:58 ` Cyril Chemparathy
2012-09-21 15:56 ` [PATCH v3 RESEND 14/17] ARM: LPAE: accomodate >32-bit addresses for page table base Cyril Chemparathy
2012-09-24 15:17 ` Catalin Marinas
2012-09-21 15:56 ` [PATCH v3 RESEND 15/17] ARM: mm: use physical addresses in highmem sanity checks Cyril Chemparathy
2012-09-24 15:18 ` Catalin Marinas
2012-09-21 15:56 ` [PATCH v3 RESEND 16/17] ARM: mm: cleanup checks for membank overlap with vmalloc area Cyril Chemparathy
2012-09-21 15:56 ` [PATCH v3 RESEND 17/17] ARM: mm: clean up membank size limit checks Cyril Chemparathy
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=20120925135343.GD14924@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).