From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] ARM: LPAE: reduce damage caused by idmap to virtual memory layout
Date: Mon, 28 Jul 2014 20:13:05 +0100 [thread overview]
Message-ID: <20140728191305.GA30282@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <CALYGNiNaMMv9itJ_+cvPDn1_Yo4GTPQJ-Cy9zBzJzfaDLfkvmg@mail.gmail.com>
On Mon, Jul 28, 2014 at 10:57:00PM +0400, Konstantin Khlebnikov wrote:
> Also I seen comment somewhere in the code which tells that idrmap pgd is
> always below 4gb which isn't quite true.
"idmap" means "identity map". It's a region which maps the same value of
physical address to the same value of virtual address.
Since the virtual address space is limited to 4GB, there is /no way/ that
the physical address can be above 4GB, and it still be called an
"identity map".
The reason for this is that code in the identity map will be fetched with
the MMU off. While this code is running, it will enable the MMU using the
identity map page table pointer, and the CPU must see _no_ change in the
instructions/data fetched from that region. It will then branch to the
kernel proper, and the kernel will then switch away from the identity page
table.
Once the kernel has switched away from the identity page table, interrupts
and other exceptions can then be taken on the CPU - but not before.
Neither is it expected that the CPU will access any devices until it has
switched away from the identity page table.
What this also means is that the code in the identity map must remain
visible in the low 4GB of physical address space.
> Moreover, I had some experiments with
> mapping ram to random places in qemu and seen that kernel cannot boot if
> PHYS_OFFSET isn't alligned to 128mb which is strange.
That is intentional. PHYS_OFFSET has a number of restrictions, one of
them is indeed that the physical offset /will/ be aligned to 128MB.
That was decided after looking at the platforms we have and is now
fixed at that value with platform-breaking consequences if it needs
changing.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
next prev parent reply other threads:[~2014-07-28 19:13 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-22 15:36 [PATCH 1/2] ARM: LPAE: load upper bits of early TTBR0/TTBR1 Konstantin Khlebnikov
2014-07-22 15:36 ` [PATCH 2/2] ARM: LPAE: reduce damage caused by idmap to virtual memory layout Konstantin Khlebnikov
2014-07-28 18:14 ` Will Deacon
2014-07-28 18:25 ` Konstantin Khlebnikov
2014-07-28 18:41 ` Will Deacon
2014-07-28 18:57 ` Konstantin Khlebnikov
2014-07-28 19:06 ` Will Deacon
2014-07-28 19:13 ` Russell King - ARM Linux [this message]
2014-07-28 19:29 ` Konstantin Khlebnikov
2014-07-28 19:34 ` Konstantin Khlebnikov
2014-07-28 19:42 ` Russell King - ARM Linux
2014-07-28 19:57 ` Konstantin Khlebnikov
2014-07-29 10:57 ` Russell King - ARM Linux
2014-07-29 12:37 ` Konstantin Khlebnikov
2014-07-28 18:12 ` [PATCH 1/2] ARM: LPAE: load upper bits of early TTBR0/TTBR1 Will Deacon
2014-07-28 18:40 ` Konstantin Khlebnikov
2014-07-28 18:47 ` Will Deacon
2014-07-29 11:15 ` Will Deacon
2014-07-29 12:29 ` Konstantin Khlebnikov
2014-08-27 15:26 ` Jassi Brar
2014-08-27 15:31 ` Konstantin Khlebnikov
2014-08-27 15:33 ` Konstantin Khlebnikov
2014-08-27 15:45 ` Jassi Brar
2014-08-28 11:03 ` Will Deacon
2014-08-28 11:50 ` Konstantin Khlebnikov
2014-08-05 15:42 ` Konstantin Khlebnikov
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=20140728191305.GA30282@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--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).