qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paul Brook <paul@codesourcery.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [4239] x86/x86-64 MMU PAE fixes
Date: Tue, 22 Apr 2008 23:29:36 +0100	[thread overview]
Message-ID: <200804222329.36908.paul@codesourcery.com> (raw)
In-Reply-To: <20080422221924.GA23201@miranda.arrow>

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

  reply	other threads:[~2008-04-22 22:29 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-22 20:37 [Qemu-devel] [4239] x86/x86-64 MMU PAE fixes Aurelien Jarno
2008-04-22 20:57 ` Paul Brook
2008-04-22 22:19   ` Stuart Brady
2008-04-22 22:29     ` Paul Brook [this message]
2008-04-22 22:37     ` Stuart Brady

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200804222329.36908.paul@codesourcery.com \
    --to=paul@codesourcery.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).