From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Egger Subject: Re: [PATCH 05/15] Nested Virtualization: core Date: Thu, 19 Aug 2010 12:38:09 +0200 Message-ID: <201008191238.10341.Christoph.Egger@amd.com> References: <1A42CE6F5F474C41B63392A5F80372B229188BD4@shsmsx501.ccr.corp.intel.com> <1A42CE6F5F474C41B63392A5F80372B22A3E5C0B@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: <1A42CE6F5F474C41B63392A5F80372B22A3E5C0B@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" , Keir Fraser List-Id: xen-devel@lists.xenproject.org On Thursday 19 August 2010 04:46:50 Dong, Eddie wrote: > Keir Fraser wrote: > > On 18/08/2010 09:27, "Dong, Eddie" wrote: > >>> +enum nestedhvm_vmexits > >>> +nestedhvm_vcpu_vmexit(struct vcpu *v, struct cpu_user_regs *regs, > >>> + uint64_t exitcode) +{ > >> > >> I doubt about the necessary of this kind of wrapper. > >> > >> In single layer virtualization, SVM and VMX have its own handler for > >> each VM exit. Only when certain common function is invoked, the > >> control goes from SVM/VMX to common one, because they have quit many > >> differences and the savings by wrapping that function is really > >> small, however we pay with additional complexity in both SVM and VMX > >> side as well as readability and performance. Further more, it may > >> limit the flexibility to implement something new for both side. > >> > >> Back to the nested virtualization. I am not fully convinced we need > >> a common handler for the VM_entry/exit, at least not for now. It is > >> basically same situation with above single layer virtualization. > >> Rather we prefer to jump from SVM/VMX to common code when certain > >> common service is requested. > >> > >> Will that be easier? > > > > I'm sure there ahs to be conversion-and-demux anyway in > > SVM-VMX-specific code. At which point you may as well break out to > > individual common handler functions just where that makes sense, as > > you say. Also I agree this model fits better with what we do in the > > non-nested case. I see the arch specific code as the backend and the hvm code as the frontend. Not the other way around. The vmentry/vmexit code is invoked from the arch-specific exit code. That's not do-able the other way around due to the way the hardware works. The vmentry/vmexit calls out to arch specific code where access to the vmcb/vmcs is needed. Where I need Eddie's help is in finding the nuances in the common vmentry/vmexit code that prevents him to make the VMX specific code working from the algorithm point of view. Christoph -- ---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