Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933392AbXKOWoh (ORCPT ); Thu, 15 Nov 2007 17:44:37 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1762230AbXKOWo2 (ORCPT ); Thu, 15 Nov 2007 17:44:28 -0500 Received: from terminus.zytor.com ([198.137.202.10]:58608 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759439AbXKOWo1 (ORCPT ); Thu, 15 Nov 2007 17:44:27 -0500 Message-ID: <473CCB66.2080601@zytor.com> Date: Thu, 15 Nov 2007 14:42:46 -0800 From: "H. Peter Anvin" User-Agent: Thunderbird 2.0.0.5 (X11/20070727) MIME-Version: 1.0 To: Linus Torvalds CC: Jeremy Fitzhardinge , William Lee Irwin III , Andi Kleen , Ingo Molnar , Thomas Gleixner , Nick Piggin , Linux Kernel Mailing List Subject: Re: Why preallocate pmd in x86 32-bit PAE? References: <473CC0AC.3020500@goop.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 938 Lines: 24 Linus Torvalds wrote: > > IIRC, the present bit is ignored in the magic 4-entry PGD. All entries > have to be present. > This is true, although you could point a PGD to an all-zero page if you really wanted to. You have to re-load CR3 after modifying the top-level entries. > What earlier CPU's did was to basically load all four values into the CPU > when you loaded %cr3. There was no "three-level page table walker" at all: > it was still a two-level page table walker, there were just for magic > internal page tables that were indexed off the two high bits. They still are. Loading CR3 in PAE really loads four registers from memory. x86-64 is different, of course. -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/