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] feature flags use

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] feature flags use
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Fri, 10 Nov 2006 15:16:54 +0100
Delivery-date: Fri, 10 Nov 2006 06:16:04 -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
Following the need to allocate a new feature flag I soon realized that
currently there is not even a place to store them - this to me is
particularly puzzling for XENFEAT_pae_pgdir_above_4gb, as I would
have expected that the CR3 handling in PAE mode gets adjusted
according to whether the guest has that flag set. Any reason for that
(other than *assuming* that guests without that flag will always pass
the low 12 bits of CR3 clear)? Namely, what's the purpose of having
the guest specify that flag if it doesn't really change anything?

So, in turn, it seems to me that I'll first have to create a domctl to
allow setting feature flags reported by the guest (and manually fill
them for dom0), and the tools then would have to follow. The
problematic part with this is that this must happen early enough to
make sure the hv didn't use any of the flag values, yet - much like
the (un-)setting of the compatibility mode flag, and that the hv has
to verify the call isn't made too late.

Such a new domctl could certainly be combined with the one setting
the mode (native or compat) of the (pv) guest - would that be
considered desirable?

Jan


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

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