From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Dong, Eddie" Subject: RE: [PATCH 06/16] vmx: nest: handling VMX instruction exits Date: Wed, 15 Sep 2010 15:56:12 +0800 Message-ID: <1A42CE6F5F474C41B63392A5F80372B22A8C2219@shsmsx501.ccr.corp.intel.com> References: <20100915071706.GA23507@qhe2-db> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Language: en-US 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 , "He, Qing" Cc: Tim Deegan , "xen-devel@lists.xensource.com" , "Dong, Eddie" List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > On 15/09/2010 08:17, "Qing He" wrote: >=20 >>> 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. >>=20 >> 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). >=20 > A few VMX-specific callbacks would be fine. Extra callbacks are > cheap. Just focus on making the callback interface clean and tidy. > I'd *much* rather have VMX-specific callbacks than an extra emulator. >=20 >> And if we are to use x86_emulate, is it possible to avoid redecoding >> the opcode, because exit reason is already there? >=20 > If vmexit reason fully decodes the instruction for you then I would Yes, VM exit reason + VMX_INSTRUCTION_INFO includes everything we needs :) It is mainly because VMX instruction is simple. > agree that skipping x86_emulate could make sense. And then your > instruction emulator would be really simple and fast -- > vmx_io_instruction() is a good example of this. If you still need to Sure, the emulation is very simple and fast, I cab put all privilege check = into one function as well. > parse the instruction to decode ModRM and the like, then I don't see No need to decode ModRM. > 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.=20 So how about we reuse some functions in x86 emulate like this one? 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=