Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754150AbYAYCaZ (ORCPT ); Thu, 24 Jan 2008 21:30:25 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752362AbYAYCaM (ORCPT ); Thu, 24 Jan 2008 21:30:12 -0500 Received: from terminus.zytor.com ([198.137.202.10]:40645 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751295AbYAYCaL (ORCPT ); Thu, 24 Jan 2008 21:30:11 -0500 Message-ID: <479948A1.7010607@zytor.com> Date: Thu, 24 Jan 2008 18:25:37 -0800 From: "H. Peter Anvin" User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: "Eric W. Biederman" CC: Pavel Machek , "Rafael J. Wysocki" , Jeremy Fitzhardinge , Ian Campbell , Ingo Molnar , =?ISO-8859-1?Q?Mika_Penttil=E4?= , linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar Subject: Re: [PATCH] x86: Construct 32 bit boot time page tables in native format. References: <1201121530.30671.15.camel@cthulhu.hellion.org.uk> <4797E487.8010108@goop.org> <1201167544.30671.64.camel@cthulhu.hellion.org.uk> <47990BDC.4070008@zytor.com> <479912B0.2080506@goop.org> <479913BA.8000506@zytor.com> <47991809.9060903@goop.org> <47991A6C.8060007@zytor.com> <479921F5.9020902@goop.org> <4799247C.6090008@zytor.com> <20080125002054.GA2059@elf.ucw.cz> <47992D0E.2070700@zytor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1673 Lines: 36 Eric W. Biederman wrote: > > We already do this on the 64bit side. We reuse the kernel and the > identity parts from the core kernel page tables but it is actually > a distinct page table. > > x86_64 has not had the identity mappings mapped in any of the > normal page tables since the relocatable kernel support was merged > a while ago. > > Only on the 32bit side does this still remain an issue. I don't know > if what we can do optimization wise there. Emulating the 64bit code > and having a dedicated top level pgd (as part of the trampoline) > and then a mapping into it the kernel identity mapping and the kernel > mapping (which are the same on 32bit) should work fairly easily. > > It is just a handful of pgd entries, and then in the actual kernel > entry code we reload %cr3 with the appropriate kernel page table > and we should be fine. No need for an explicit zap there at all. > That's pretty much what I figure. The one issue is that on non-PAE 32-bit (or if we actually have to deal with unsharable PMDs on PAE kernels) then the PGD (PMD) kernel mappings at least formally should really be put in sync. This could be done either by the same code which keeps the PGDs of various processes in sync already or on demand; I believe my personal preference would be to have all that in the same place, since we have to do it anyway, and this is nothing different except for the offset. -hpa -- 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/