This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] PAE, Elf headers, and Extended CR3 registers

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] PAE, Elf headers, and Extended CR3 registers
From: Randy Thelen <rthelen@xxxxxxxxxx>
Date: Fri, 15 Sep 2006 12:40:02 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 18 Sep 2006 02:18:16 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C13033A7.1471%Keir.Fraser@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C13033A7.1471%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Keir Fraser wrote:

'Extended CR3' means that, on PAE, we fold the higher-order bits of the page directory address into the low-order bits of the 32-bit virtual CR3 value.

See the xen_pfn_to_cr3() and xen_cr3_to_pfn() macros in

In general the guest OS does not manipulate CR3 values at the hypercall
interface, so this is not an issue (e.g., the hypercall for switching
pagetable base pointer takes a page frame number). The one exception in Linux was that SMP booting required writing a CR3 value into a vcpu_context structure. So that's the only place we use those two conversion macros.

Thanks, Keir.

Interesting encoding of the virtual CR3 value:

#define xen_pfn_to_cr3(pfn) (((unsigned)(pfn) << 12) | ((unsigned) (pfn) >> 20))

This comment in the Xen code clarifies my thinking on this:

/* Only PDPTs above 4GB boundary need to be shadowed in low memory. */
#define l3tab_needs_shadow(mfn) ((mfn) >= 0x100000)

My concern had been that 'extended CR3' implied hardware support for a 64 bit CR3 register. Instead it means that I shouldn't really care if the mfn of my Page Table Directory Pointer is above 4GB, Xen will handle the condition for me. And, the way I'll decode the mfn, if necessary (which I would agree should be rare), would be with those macros.

-- Randy

Xen-devel mailing list