Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751462AbaG1TeQ (ORCPT ); Mon, 28 Jul 2014 15:34:16 -0400 Received: from mail-ie0-f172.google.com ([209.85.223.172]:55793 "EHLO mail-ie0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750708AbaG1TeN (ORCPT ); Mon, 28 Jul 2014 15:34:13 -0400 MIME-Version: 1.0 In-Reply-To: References: <20140722153623.25088.37742.stgit@buzz> <20140722153635.25088.14197.stgit@buzz> <20140728181456.GO15536@arm.com> <20140728184107.GR15536@arm.com> <20140728191305.GA30282@n2100.arm.linux.org.uk> Date: Mon, 28 Jul 2014 23:34:12 +0400 Message-ID: Subject: Re: [PATCH 2/2] ARM: LPAE: reduce damage caused by idmap to virtual memory layout From: Konstantin Khlebnikov To: Russell King - ARM Linux Cc: Will Deacon , Konstantin Khlebnikov , Vitaly Andrianov , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Cyril Chemparathy Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 28, 2014 at 11:29 PM, Konstantin Khlebnikov wrote: > On Mon, Jul 28, 2014 at 11:13 PM, Russell King - ARM Linux > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/