From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: [PATCH 06/16] vmx: nest: handling VMX instruction exits Date: Wed, 15 Sep 2010 10:26:26 +0100 Message-ID: <20100915092626.GB11387@whitby.uk.xensource.com> References: <1A42CE6F5F474C41B63392A5F80372B22A8C2219@shsmsx501.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: "xen-devel@lists.xensource.com" , "Dong, Eddie" , "He, Qing" List-Id: xen-devel@lists.xenproject.org At 09:15 +0100 on 15 Sep (1284542116), Keir Fraser wrote: > On 15/09/2010 08:56, "Dong, Eddie" wrote: > > >> that the partial decode from vmexit reason saves you much at all, and > >> you might as well go the whole hog and do full decode. I don't see > >> much saving from a hacky middle-ground. > > > > So how about we reuse some functions in x86 emulate like this one? > > Ah, well, now I look at your patch 06/16 properly, I think it's clear and > self-contained as it is. Your private enumerations within nest.c simply > serve to document the format of the decoded instruction provided to you via > fields in the VMCS. I wouldn't be inclined to change it at all, unless Tim > really has strong objections about it. No, that's OK. > It's not like you're defining > namespaces for new abstractions you have conjured from thin air -- they > correspond directly to a hardware-defined decode format. Defining > enumerations on top of that is *good*, imo. I would take 06/16 as it stands. Fair enough, but I'd like the memory leak fixed too (svmcs and vvmcs are only freed if the N1 guest executes VMXOFF). Cheers, Tim. > > static enum x86_segment > > decode_segment(uint8_t modrm_reg) > > { > > switch ( modrm_reg ) > > { > > case 0: return x86_seg_es; > > case 1: return x86_seg_cs; > > case 2: return x86_seg_ss; > > case 3: return x86_seg_ds; > > case 4: return x86_seg_fs; > > case 5: return x86_seg_gs; > > default: break; > > } > > return decode_segment_failed; > > } > > > > Thx, Eddie > > -- Tim Deegan Principal Software Engineer, XenServer Engineering Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)