From: Keir Fraser Subject: Re: [PATCH 01/18] Nested Virtualization: tools Date: Fri, 16 Apr 2010 18:44:43 +0100 Message-ID: References: <20100416104343.GC31304@whitby.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20100416104343.GC31304@whitby.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Tim Deegan , Christoph Egger Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 16/04/2010 11:43, "Tim Deegan" wrote: >>> typedef struct xen_domctl_createdomain xen_domctl_createdomain_t; >>> DEFINE_XEN_GUEST_HANDLE(xen_domctl_createdomain_t); >> >> Does this need its own hyperacll flag? Couldn't we just gate it on >> whether the cpuid policy allows SVM? > > Actually, more generally: Keir, can you give us an opinion on which > things like this belong in DOMCTL_CDF_ and which in HVM_PARAM_ (and > which in their own hypercalls or not at all?) Yes, this should be hooked off CPUID configuration, or an HVM_PARAM. We only allocate DOMCTL_CDF flags for things which need for whatever reason to be configured/enabled really early. Shadow stuff is a good example, as the shadow logic is hard enough without switching modes after a domain is created - hence there we have DOMCTL_CDF flags so it can just be set up right all in one go. I don't think nestedhvm has such difficulties. -- Keir