Message-ID: <CALYGNiO6PEPoHDrcLRZxQVT2=-1upyh6E-TWBCMB0MR8u5Sx6w@mail.gmail.com>
Date:	Mon, 28 Jul 2014 23:57:16 +0400
From:	Konstantin Khlebnikov <koct9i@...il.com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Will Deacon <will.deacon@....com>,
	Konstantin Khlebnikov <k.khlebnikov@...sung.com>,
	Vitaly Andrianov <vitalya@...com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Cyril Chemparathy <cyril@...com>
Subject: Re: [PATCH 2/2] ARM: LPAE: reduce damage caused by idmap to virtual
 memory layout

On Mon, Jul 28, 2014 at 11:42 PM, Russell King - ARM Linux
<linux@....linux.org.uk> wrote:
> 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.

I know. I mean "logically".

>
> 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.

Sorry but I'm really look so dumb? Maybe it's true, it's almost
midnight at my side.

>
>> 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.

In my case it's been overwritten.
And it always happens when PHYS_OFFSET >= PAGE_OFFSET
because in case of LPAE idmap always overwrites 1Gb at once.

>
> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists