On Mon, Jul 28, 2014 at 11:42 PM, Russell King - ARM Linux <[email protected]> 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
