From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: KVM call minutes for Nov 30 Date: Wed, 01 Dec 2010 12:28:59 +0200 Message-ID: <4CF6236B.4080308@redhat.com> References: <20101130155355.GJ24841@x200.localdomain> <20101201092730.GB29486@fermat.math.technion.ac.il> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Chris Wright , kvm@vger.kernel.org To: "Nadav Har'El" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:25645 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751484Ab0LAK3I (ORCPT ); Wed, 1 Dec 2010 05:29:08 -0500 In-Reply-To: <20101201092730.GB29486@fermat.math.technion.ac.il> Sender: kvm-owner@vger.kernel.org List-ID: On 12/01/2010 11:27 AM, Nadav Har'El wrote: > I really want to get nested VMX into KVM, and I'm already doing whatever I > can to make this a reality. But unfortunately, I am not yet a seasoned KVM or > VMX expert (I'm trying to become one...), and it wasn't I who wrote the > original nested VMX code, so every new issue and every new feature that I am > asked to fix is new to me, and takes me considerable time to learn, debug, > and fix. > > I hope to continue working on nested VMX, next year as well, but IBM's (my > employer's) plans for next year are not yet set in stone. In any case, I > firmly believe that the nested VMX feature will be better, and be available > more quickly, if I am not the only person working on it. I will be very happy > if somebody reading this wants to work on this with me. This is the main > reason why I wanted to put nested VMX in the main tree (even before it is > 100% bug-free and feature-complete), because that would make it much easier > for more people to try this feature, and hopefully to help me fix problems > which bother them. I am reluctant to lower the bar on entry. Things like SMP and host EPT support are really basic IMO. Good integration into KVM is also important. If you would like to get more people participating, I suggest publishing a git tree. People can then post patches against the tree, which you can merge into the relevant commits. It would also get more testing done by interested parties. -- error compiling committee.c: too many arguments to function