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] Is machine_to_phys_mapping a 4MB 'superpage'?

To: "Jacob Gorm Hansen" <jacobg@xxxxxxx>, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] Is machine_to_phys_mapping a 4MB 'superpage'?
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Date: Thu, 31 Mar 2005 11:44:38 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 31 Mar 2005 10:44:50 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcU1zoxf5TiBW9pYSFixmIlc2AIKigADtXOg
Thread-topic: [Xen-devel] Is machine_to_phys_mapping a 4MB 'superpage'?
> > It doesn't *have* to be mapped as a superpage -- control 
> tools don't 
> > when doing suspend/resume, for example. Fixing the 
> permission checking 
> > so that other than domain0 can remap the m2p table 
> shouldn't be very 
> > hard, but I'm not sure what the cleanest method would be.
> actually I would just like for domUs to be able to map it in 
> different locations, in order to get a little more flexible 
> memory layout.
> I will probably just try and hack something up for my immediate needs.

I'd like to see this as part of a wider campaign to make the virtual
memory layout more flexible ahead of PAE. I think we should make the
hypervisor 'hole' variable size. This is perhaps best done by moving
fixmap from the top of memory to the top of the bottom. If we do this I
don't think we'll need to turn any of the current constants into

As regards where the m2p table, that will need to be variable sized too.
It woul be interesting to run some lmbench numbers just to check that
nothing bad happens if we do away with the 4MB mapping.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>