From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Egger Subject: Re: [PATCH 07/14] Nested Virtualization: trap Date: Thu, 19 Aug 2010 12:32:00 +0200 Message-ID: <201008191232.00338.Christoph.Egger@amd.com> References: <1A42CE6F5F474C41B63392A5F80372B22A3E5B97@shsmsx501.ccr.corp.intel.com> <1A42CE6F5F474C41B63392A5F80372B22A3E5C06@shsmsx501.ccr.corp.intel.com> <20100819083552.GF20252@whitby.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20100819083552.GF20252@whitby.uk.xensource.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: Tim Deegan Cc: "xen-devel@lists.xensource.com" , "Dong, Eddie" List-Id: xen-devel@lists.xenproject.org On Thursday 19 August 2010 10:35:52 Tim Deegan wrote: > At 03:44 +0100 on 19 Aug (1282189499), Dong, Eddie wrote: > > > +int hvm_inject_exception(unsigned int trapnr, int errcode, unsigned > > > long cr2) +{ > > > + uint64_t exitcode; > > > + bool_t is_intercepted; > > > + struct vcpu *v = current; > > > + struct nestedhvm *hvm = &VCPU_NESTEDHVM(v); > > > + > > > + if ( !nestedhvm_enabled(v->domain) ) { > > > + hvm_funcs.inject_exception(trapnr, errcode, cr2); > > > + return 0; > > > + } > > > > If it is not nested, we go from here to vendor specific injection code. > > If it is nested, I think we'd better to go to another vendor specific > > handler too. > > That's exactly what this wrapper does. It's basically: > if ( in L2 and L1 intercepts ) > force vmexit > else > inject directly. > > It calls out to arch-specific code to do the intercept check and the > vmexit. It could be tidied up a bit and the interfaces could change but > this looks like about the least amount of sharing there could be on > this path. I can't see anything objectionable. Correct. The key to make this possible is the generic exitcode mechanism. Eddie: In an other mail you said, that the generic exitcode is overcomplicated. I have the impression that you do not realise that the unification of the exitcodes makes that much code shareable at all. No, I do not unified *all* exitcodes - I don't know if that is even possible. I only unified a subset that is actually used in the generic code. (I also have the feeling Keir didn't realize that either given to his last comments to patch 5/15) 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