From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: feature flags use Date: Fri, 10 Nov 2006 15:16:54 +0100 Message-ID: <455497E6.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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