From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Configuration of nestedhvm Date: Fri, 08 Oct 2010 09:22:44 +0100 Message-ID: References: <1A42CE6F5F474C41B63392A5F80372B22DBEA5AA@shsmsx501.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1A42CE6F5F474C41B63392A5F80372B22DBEA5AA@shsmsx501.ccr.corp.intel.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: "Dong, Eddie" Cc: Xen-devel List-Id: xen-devel@lists.xenproject.org On 08/10/2010 08:56, "Dong, Eddie" wrote: >> What's the point when a per-domain config option is going to be >> implemented? You can then simply not configure nestedhvm for a domain >> you want to test without that capability? I suppose it makes your >> second patch make a bit more sense than it would in total isolation. > > I want double-lock (AND) like other components such as IOMMU. > If the global switch is off, even per domain configuration is turned on, the > final effect is "OFF". > > The point here is to avoid manual mistake when the nested code is built in as > formal release but targeting for pilot. Relying on HVM guest configuration > only may cause the host crash or performance impact if the code has a bug and > a guest enables nested virtualization feature. > > This switch is mainly for developer only at least for now. Well, at least it should only be disallowing toolstack to set the per-domain config option. Then it won't need to be accessed on every use of is_nestedhvm(). So again it depends on that, mainly tool-side, patch. -- Keir