Messages in this thread | | | Date | Mon, 28 Jul 2014 23:34:12 +0400 | Subject | Re: [PATCH 2/2] ARM: LPAE: reduce damage caused by idmap to virtual memory layout | From | Konstantin Khlebnikov <> |
| |
On Mon, Jul 28, 2014 at 11:29 PM, Konstantin Khlebnikov <koct9i@gmail.com> wrote: > On Mon, Jul 28, 2014 at 11:13 PM, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: >> 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. > > Ok, before switching from identity mapping to normal mapping kernel must > switch instruction pointer from physical address to virtual. 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). > > 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.
Oh, my bad. That was response to Will Deacon's
> Ok. I think we need more specifics to progress with this patch. It's not > clear to me what's going wrong or why your platform is causing the issues > you're seeing.
> >> >>> 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.
| |