From mboxrd@z Thu Jan 1 00:00:00 1970 From: Qing He Subject: Re: [PATCH 06/16] vmx: nest: handling VMX instruction exits Date: Wed, 15 Sep 2010 15:17:06 +0800 Message-ID: <20100915071706.GA23507@qhe2-db> References: <1A42CE6F5F474C41B63392A5F80372B22A8C201F@shsmsx501.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: Tim Deegan , "xen-devel@lists.xensource.com" , "Dong, Eddie" List-Id: xen-devel@lists.xenproject.org On Wed, 2010-09-15 at 14:40 +0800, Keir Fraser wrote: > On 15/09/2010 05:55, "Dong, Eddie" wrote: > > >>> +enum x86_segment sreg_to_index[] = { > >>> + [VMX_SREG_ES] = x86_seg_es, > >>> + [VMX_SREG_CS] = x86_seg_cs, > >>> + [VMX_SREG_SS] = x86_seg_ss, > >>> + [VMX_SREG_DS] = x86_seg_ds, > >>> + [VMX_SREG_FS] = x86_seg_fs, > >>> + [VMX_SREG_GS] = x86_seg_gs, > >>> +}; > >> > >> Since you dislike adding new namespaces and translations, I'm sure you > >> can get rid of these. :) It might even simplify some of the macros > >> below. > > > > True, some dupcation here. Regarding following definition in x86_emulate.c, we > > can reuse. > > AFAICS if you must have your own extra instruction decoder, a few register > translation definitions and arrays is the least of it really. I'd rather > keep x86_emulate clean and separate rather than become intertwined with > another emulator. > > What is wrong with simply extending x86_emulate to handle these VMX-related > instructions? We've dealt with emulators provided by Intel guys in the past > and frankly they were full of holes. That needs additional callback when handling vmcs and state change, doesn't it? I'm a little worried that it's too vmx-specific to get into x86_emulate, and that's why we used a separate decoder in the first place (I know it's ugly, though). And if we are to use x86_emulate, is it possible to avoid redecoding the opcode, because exit reason is already there? Thanks, Qing