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] [RFC PATCH 14/35] subarch modify CPU capabilities

To: Chris Wright <chrisw@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [RFC PATCH 14/35] subarch modify CPU capabilities
From: Zachary Amsden <zach@xxxxxxxxxx>
Date: Wed, 22 Mar 2006 00:35:23 -0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Ian Pratt <ian.pratt@xxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, virtualization@xxxxxxxxxxxxxx, Pratap Subrahmanyam <pratap@xxxxxxxxxx>, Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>
Delivery-date: Wed, 22 Mar 2006 08:38:21 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20060322063751.151430000@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>
References: <20060322063040.960068000@xxxxxxxxxxxxxxxxxx> <20060322063751.151430000@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5 (X11/20051201)
Chris Wright wrote:
+void __devinit machine_specific_modify_cpu_capabilities(struct cpuinfo_x86 *c)
+{
+       clear_bit(X86_FEATURE_VME, c->x86_capability);
+       clear_bit(X86_FEATURE_DE, c->x86_capability);
+       clear_bit(X86_FEATURE_PSE, c->x86_capability);
+       clear_bit(X86_FEATURE_PGE, c->x86_capability);
+       clear_bit(X86_FEATURE_SEP, c->x86_capability);
+       clear_bit(X86_FEATURE_MWAIT, c->x86_capability);
+       if (!(xen_start_info->flags & SIF_PRIVILEGED))
+               clear_bit(X86_FEATURE_MTRR, c->x86_capability);
+       c->hlt_works_ok = 0;
That's pretty heinous.  Suppose Xen decides to start supporting any of 
these features.  Now, you need to change all of the Xen modified kernels 
to remove pieces of this.
You've effectively introduced completely arbitrary, but most 
importantly, static constraints into Linux based on what features Xen 
currently supports.  This is not productive on either end.
This is the entire point of the VMI interface.  You can arbitrarily 
enable and disable these features in a hidden layer, call it VMI, call 
it Xen-bridge, call it hypercall page, whatever.   Using this layer, you 
can automatically abstract away exactly this type of nasty, deliberately 
deprecating extraneous code.  We use this feature exactly to strip away 
these bits, completely hidden from the guest, by "trapping" the CPUID 
instruction in the VMI layer.  The VMI interface as it stands today is 
unimportant - it has and will continue to change to accommodate Xen.  
But the principles of it are important for maintainability, flexibility, 
and future compatibility.  One of these principles is to avoid 
unbalanced changes like this to the guest kernel.
And we certainly support VME, DE, PSE, PGE, and SEP features, and really 
would not like them disabled unconditionally in a virtual environment.
Zach

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

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