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] more shadow vs. 32-on-64

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] more shadow vs. 32-on-64
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Thu, 09 Nov 2006 17:41:57 +0100
Delivery-date: Thu, 09 Nov 2006 08:41:11 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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
sh_update_paging_modes() seems to nominate 3-on-4 for this environment,
yet there apparently aren't provisions to support it once enabled (I first
thought it could be that simple). While by conditionalizing upon
pv_32bit_guest() I can address some, I got really uncertain when
encountering the callback table in shadow_remove_write_access() (and I
didn't go further) - I'd have to create a second table and conditionalize the
use(s), which seems ugly at best. I therefore assume it's going to be
better to leave this to the shadow writers, unless I can get a much better
understanding of this code.

Jan

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

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] more shadow vs. 32-on-64, Jan Beulich <=