From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Egger Subject: Re: [PATCH 0/14] Nested Virtualization: Overview Date: Tue, 17 Aug 2010 12:33:29 +0200 Message-ID: <201008171233.30154.Christoph.Egger@amd.com> References: <201008051659.38272.Christoph.Egger@amd.com> <1A42CE6F5F474C41B63392A5F80372B2291435E0@shsmsx501.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1A42CE6F5F474C41B63392A5F80372B2291435E0@shsmsx501.ccr.corp.intel.com> Content-Disposition: inline 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@lists.xensource.com" , Tim Deegan List-Id: xen-devel@lists.xenproject.org On Tuesday 17 August 2010 08:04:20 Dong, Eddie wrote: > Hi, Chris: > > Christoph Egger wrote: > > Hi! > > > > This patch series brings Nested Virtualization to Xen. > > This is the third patch series. Improvements to the > > previous patch submission: > > > > - implement HVM-on-HVM (instead of SVM-on-HVM) > > Given that we don't have consensus on cross architecture nested > virtualization support, I am doubting why this is urgent for now. The reason to be "urgent" is not the time. This is the best way from the software engineering side. > I would prefer we make SVM-on-SVM and VMX-on-VMX work first. After that, > if you prove SVM-on-VMX has real performance gain (which I doubt), we can > see how to make a much generic effort to accomodate both natively nested > virtualization and cross architecture nested virtualization. Tim and Keir made clear they don't want to have two implementations after I submitted my patch series the *first* time. > Drawing a picture which doesn't have a real usage with massive common code > change is a kind of too much load for us now. Xen hvm_function table is a > good example. Intel enabled VMX at very beginning of Xen HVM support, and > SVM comes later on with a lot of code reuse from VMX side. Then the > community and both side work together to make an API wrapper to reuse > common code better and accomodate both architecture. I think we have to go > similar path to make it work first. Tim remembers on this and said in this mail http://lists.xensource.com/archives/html/xen-devel/2010-04/msg00812.html "With HVM it has turned out to be quite a lot, but it's taken years of reshuffling to pull code out into common HVM routines (and we're not there yet)." If I understand Tim correctly, the way you suggest is a "no". (Added Tim on CC) Christoph > > > - move cpuid handling into tools (per Keir's request) > > > > There might still be some nuances to fiddle with to make it > > fit for VMX. Feedback from Intel is appreciated, therefore. > > Thx, Eddie -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632