From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1JoQzg-0007v2-U4
	for qemu-devel@nongnu.org; Tue, 22 Apr 2008 18:29:44 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1JoQze-0007uf-H9
	for qemu-devel@nongnu.org; Tue, 22 Apr 2008 18:29:43 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1JoQze-0007uc-Bi
	for qemu-devel@nongnu.org; Tue, 22 Apr 2008 18:29:42 -0400
Received: from mail.codesourcery.com ([65.74.133.4])
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <paul@codesourcery.com>) id 1JoQzd-0000JH-UN
	for qemu-devel@nongnu.org; Tue, 22 Apr 2008 18:29:42 -0400
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [4239] x86/x86-64 MMU PAE fixes
Date: Tue, 22 Apr 2008 23:29:36 +0100
References: <E1JoPFI-0006oi-2m@cvs.savannah.gnu.org>
	<200804222157.12963.paul@codesourcery.com>
	<20080422221924.GA23201@miranda.arrow>
In-Reply-To: <20080422221924.GA23201@miranda.arrow>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="ansi_x3.4-1968"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200804222329.36908.paul@codesourcery.com>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

On Tuesday 22 April 2008, Stuart Brady wrote:
> On Tue, Apr 22, 2008 at 09:57:12PM +0100, Paul Brook wrote:
> > On Tuesday 22 April 2008, Aurelien Jarno wrote:
> > > -#define PHYS_ADDR_MASK 0xfffff000
> > > +#define PHYS_ADDR_MASK (~0xfff)
> >
> > I think this is wrong. According to my docs physical addresses have an
> > architectural limit of 52 bits. Bits 52-62 of a PTE are reserved (must be
> > zero), and bit 63 is the NX bit.
>
> The documentation I'm using:
>
> "Intel 64 and IA-32 Architectures Software Development Manual,
>  Volume 3A: System Programming Guide, Part 1"
>
> "3.8 36-Bit Physical Addressing Using The PAE Paging Mechanism"
>
>   Lists bits 36-63 as "must be zero".

This disagrees with the AMD docs, which allow full 52-bit addresses in legacy 
mode. This may be a historical thing.

> "3.10 PAE-Enabled Paging in IA-32e Mode"
>
>   Lists bits 40-51 as "must be zero".

The AMD docs define a 52-bit physical address space. I'm not sure what the 
behavior is on CPUs that only implement a smaller physical address bus.

>   Lists bits 52 to 62 as "available".

The AMD docs, and some versions of the Intel docs list these as must be zero.
This may be annother case of Intel screwing up the architecture. I wouldn't be 
surprised if future CPUs define these bits to have some meaning.

Paul