Xen 
 
Home About Xen.org Xen Xen Summit Wiki Mailing List Bug Tracker Xen Downloads
 
   
 

xen-devel

RE: [Xen-devel] P2M Top Level Page Table

To: "Keir Fraser" <keir@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, "Tim Deegan" <Tim.Deegan@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] P2M Top Level Page Table
From: "Huang2, Wei" <Wei.Huang2@xxxxxxx>
Date: Thu, 29 Mar 2007 11:46:46 -0500
Delivery-date: Thu, 29 Mar 2007 17:48:30 +0100
Envelope-to: Keir.Fraser@xxxxxxxxxxxx
In-reply-to: <C231AAE0.C8A4%keir@xxxxxxxxxxxxx>
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: <7D748C767B7FA541A8AC5504A4C89A23015685FC@xxxxxxxxxxxxxxxxx> <C231AAE0.C8A4%keir@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcdyHBl6ROin1Ah6Tnm0i91fEIxX9gABQ2wVAAAJnUA=
Thread-topic: [Xen-devel] P2M Top Level Page Table
My question is about h_cr3 in VMCB under hap mode. It points to the top level of P2M table, which might be located in memory space beyond 4GB. It can cause problem potentially.
 
-Wei


From: Keir Fraser [mailto:keir@xxxxxxxxxxxxx]
Sent: Thursday, March 29, 2007 11:42 AM
To: Huang2, Wei; xen-devel@xxxxxxxxxxxxxxxxxxx; Tim Deegan
Subject: Re: [Xen-devel] P2M Top Level Page Table

PAE shadow mode always points CR3 at v->arch.paging.shadow.l3table[], which is guaranteed below 4GB and is a cache of the shadow entries. So it does not matter at all whether the P2M root table is above 4GB.

 -- Keir

On 29/3/07 17:05, "Huang2, Wei" <Wei.Huang2@xxxxxxx> wrote:

Current P2M table are allocated through alloc_domheap_pages(), which can potentially allocate memory with physical address > 4G under PAE mode. However, for top level P2M table (under PAE mode), its physical address should be below 4G because CR3 has only 32 bits. I noticed that mm.c relies on pae_l3_cache to solve this problem in make_cr3(). Do we plan to have similar solution for P2M table? Another solution might use xmalloc; but I just wonder whether it always returns memory below 4G.

Any though?

Thanks,

-Wei


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>