From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 0/9] [RFC] Add support for nested SVM (kernel) Date: Mon, 01 Sep 2008 17:57:31 +0300 Message-ID: <48BC02DB.5070006@qumranet.com> References: <1220270281-15720-1-git-send-email-agraf@suse.de> <20080901134110.GD2151@redhat.com> <48BBFA8C.6070003@qumranet.com> <369FA656-A309-4959-BBB2-8D0312D18C63@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Daniel P. Berrange" , kvm@vger.kernel.org, joro@8bytes.org, anthony@codemonkey.ws To: Alexander Graf Return-path: Received: from il.qumranet.com ([212.179.150.194]:41814 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751433AbYIAO5d (ORCPT ); Mon, 1 Sep 2008 10:57:33 -0400 In-Reply-To: <369FA656-A309-4959-BBB2-8D0312D18C63@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: Alexander Graf wrote: > > On Sep 1, 2008, at 4:22 PM, Avi Kivity wrote: > >> Alexander Graf wrote: >>> >>> This is completely implementation specific. So for now this is 100% >>> AMD only code. >>> Also I don't really like Intel's design for VMX and while making >>> nested VMX work might not be _that_ hard, getting it fast would >>> probably require a lot of work and hacks. >> >> I've thought of introducing a third, hypercall based, virtualization >> extension and exposing that. We could then optimize it to the hilts. >> >> The advantages of this are that we can live migrate across vendors, >> and of course we have great freedom in the implementation. The >> disadvantage is that a lot of thought needs to go into the design in >> order to accommodate future changes in both the host and guest. > > Not only that, but we'd also only enable running KVM inside the VM for > now. Yes, of course. -- error compiling committee.c: too many arguments to function