WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] sparse M2P table

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] sparse M2P table
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Wed, 16 Sep 2009 11:04:02 +0100
Delivery-date: Wed, 16 Sep 2009 03:07:42 -0700
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
I'm in the process of putting together patches to eliminate undue overhead
resulting from Xen's current assumption on a non-sparse machine address
map. After removing large holes (symmetric across all nodes) from the
machine address map and after also mapping the resulting (much smaller)
frame table sparsely (to account for smaller holes distinct for one or more
nodes), I intended to also map the P2M table sparsely. However, there's
a tools side assumption (for domain save) on this table being contiguously
populated.

While this could be relatively easily fixed in tools, I'm wondering if there
are other dependencies on this table (or its read-only equivalent readable
by all guests) to be non-sparse. In particular, while I can easily see that
Linux has always been careful to access the read-only copy of the table
with exception fixup, I don't know whether that would also apply to the
other PV OSes (Solaris, NetBSD, ???).

One alternative would be to dedicate a zero-filled 2M page for all these
holes, but I have to admit that this doesn't seem very attractive.

Another option would be to use a made-up MFN to represent the holes,
allowing Xen (once they get fed back into mmu_update) to recognize
this and simply ignore the mapping request (after all the tools should
not access these ranges anyway). This wouldn't address potential
issues of non-Linux guests with a sparse R/O M2P table though.

Other thoughts?

Jan


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

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