From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joerg Roedel Subject: Re: KVM call minutes for Sept 21 Date: Wed, 22 Sep 2010 21:34:18 +0200 Message-ID: <20100922193418.GL15338@8bytes.org> References: <20100921180506.GI28009@x200.localdomain> <20100922000438.GA2844@fermat.math.technion.ac.il> <20100922014841.GP28009@x200.localdomain> <20100922174943.GB12492@fermat.math.technion.ac.il> <4C9A450B.903@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Nadav Har'El , Chris Wright , kvm@vger.kernel.org, avi@redhat.com To: Anthony Liguori Return-path: Received: from 8bytes.org ([88.198.83.132]:36134 "EHLO 8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751942Ab0IVTeT (ORCPT ); Wed, 22 Sep 2010 15:34:19 -0400 Content-Disposition: inline In-Reply-To: <4C9A450B.903@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Sep 22, 2010 at 01:03:55PM -0500, Anthony Liguori wrote: > On 09/22/2010 12:49 PM, Nadav Har'El wrote: >> On Tue, Sep 21, 2010, Chris Wright wrote about "Re: KVM call minutes for Sept 21": >> >>> People keep looking for reasons to justify the cost of the effort, dunno >>> why "because it's cool" isn't good enough ;) At any rate, that was mainly >>> a question of how it might be useful for production kind of environments. >>> >> I gave in my previous mail a long list of examples what you might do with >> nested virtualization, and many of them could be called "production kind of >> enviroments". >> > > I don't think arguing about use cases is very productive. > > The concern is that nested VMX is invasive and presents a long term > maintenance burden. There are two ways to mitigate this burden. The > first is to work extra hard to make things as common as humanly possible > between nested VMX and nested SVM. The second is to make sure that we > have an aggressive set of test cases. This can be stated about nested virtualization support in KVM in general. And since we need to solve this for nested SVM too I don't think these questions should prevent the merge of nested VMX. Okay, nested VMX is very new. I don't know the current state and quality of the patches and the testing they have experienced. But if they are in the same quality state as nested SVM when it was merged I think nested VMX should not be blocked. The code should be disabled by default of course for some time to minimize the risks. One big advantage of merging is that Nadav has a lot more time to improve the code instead of having to rebase it all the time. Joerg