Re: [PATCH 2/2] ARM: LPAE: reduce damage caused by idmap to virtual memory layout

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

On Mon, Jul 28, 2014 at 11:29:39PM +0400, Konstantin Khlebnikov wrote:
> Ok, before switching from identity mapping to normal mapping kernel must
> switch instruction pointer from physical address to virtual.

"switch instruction pointer from physical address to virtual."

There's no such distinction for the instruction pointer.

There is the mode where the MMU is disabled.  The CPU fetches from the
address in the program counter.  The instructions it fetches will
instruct it to perform operations to enable the MMU.

The CPU itself continues fetching instructions (with an unpredictable
number of instructions in the CPU's pipeline) across this boundary.

Hence, it is _impossible_ to know which exact instructions are fetched
with the MMU off, and which are fetched with the MMU on.

This is why we need the identity mapping: so that the CPU's instruction
fetches can continue unaffected by turning the MMU on.

Before the MMU is on, the CPU is fetching from an untranslated (== physical)
view of the address space, which is limited to 4GB in size.

After the MMU is on, the CPU is fetching from a translated (== virtual)
view of the address space, which and the translated version is also
limited to 4GB in size.

> It's a long jump
> out idmap code section to some normal kernel function.
> __secondary_switched in my case. And both physical source and virtual
> destination addresses must present in one same mapping (idmap).

... one which the code already caters for.

> idmap pgd starts as copy of pgd from init_mm, it points to the same pmd pages.
> When it populates identical mapping for that special code section it allocates
> new pages from pmd entries (which covers 1Gb of vm layout) but only few of
> them are filled. In case 3/1GB split If idmap touches somehing above 3Gb it
> kills whole kernel vm layout and as result kernel cannot jump to any
> virtual address.

It doesn't matter, provided the kernel text and data in the virtual
address space are not overwritten by the identity mapping.  If it
ends up in the vmalloc or IO space, that should not be a problem.

It also should not be a problem if the physical memory starts at
PAGE_OFFSET (iow, PHYS_OFFSET == PAGE_OFFSET).  Indeed, we have
some platforms where that is true.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.