From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [GSoC 2010][RESEND] Completing Nested VMX Date: Tue, 06 Apr 2010 00:29:16 +0300 Message-ID: <4BBA562C.1000608@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm-devel , Luiz Capitulino To: Mohammed Gamal Return-path: Received: from mx1.redhat.com ([209.132.183.28]:36195 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756364Ab0DEV3V (ORCPT ); Mon, 5 Apr 2010 17:29:21 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 04/05/2010 09:34 PM, Mohammed Gamal wrote: > Hello All, > I'm interested in adding nested VMX support to KVM in GSoC 2010 (among > other things). I see that Orit Wasserman has done some work in this > area, but it didn't get merged yet. The last patches were a few months > ago and I have not seen any substantial progress in that front ever > since. > > I wonder whether the previous work can be used as a starting ground > for any future effort? What is missing from it? What are the current > limitations of that implementation? And how can it be extended? > The biggest problem of the existing code is maintainablity. vmx is complicated, and nested vmx is much more so. If it is to be merged, it must be in a form that doesn't impact additional work on vmx (i.e. unrelated features or optimizations) and that doesn't break each time we modify the code. Other problems are security and correctness. > And within the scopr of GSoC, what do you think the achievments of > such a project should be? > A minimal goal would be to merge something that allows running kvm and another hypervisor on kvm. However, I don't think it is realistic for a GSoC project; vmx is incredibly complicated, and the bar for merging will be set fairly high because of the impact on day-to-day maintenance. Nested svm took several release cycles to get right (and some bits are still missing), and it's much, much simpler than nested vmx. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.