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

RE: [Xen-devel] 32/64-bit hypercall interface

To: "Hollis Blanchard" <hollisb@xxxxxxxxxx>
Subject: RE: [Xen-devel] 32/64-bit hypercall interface
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Date: Mon, 3 Oct 2005 23:03:16 +0100
Cc: Jeremy Katz <katzj@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
Delivery-date: Mon, 03 Oct 2005 22:00:49 +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: AcXIXyOhC0eEnmckRleX3+ENoqvTVgAAi6zA
Thread-topic: [Xen-devel] 32/64-bit hypercall interface
 > However, doesn't that same argument apply to correcting the 
> ABI in the first place? Shadow page tables will overshadow 
> the performance impact of making the ABI 32/64-bit clean.
> 
> In fact, even a plain old hypercall will also overshadow that 
> performance impact, both in terms of cycle count and cache footprint.
> 
> So if your choice then is between a compatibility translation 
> layer and altering the interface, I think it's pretty clear 
> that changing the interface will result in the least amount 
> of additional code (and associated long-term code maintenance).

This would result in doubling the size of the all the p2m and m2p
tables, which I really don't think would be sensible: the physcial
memory consumed would be somewhat annoying, but we'd also have to rejig
the virtual memory layout to accommodate the larger tables (consuming
more lowmem) and this really doesn't make sense this late in the 3.0 dev
cycle. We'd also double the cache foot print of some quite performance
critical operations. You don't need many cache misses to dominate the
cost of a system call...


Ian

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