Re: [Xen-devel] [PATCH 06/16] vmx: nest: handling VMX instruction exits

[Qing He <qing.he@xxxxxxxxx>]

On Wed, 2010-09-15 at 14:40 +0800, Keir Fraser wrote:
> On 15/09/2010 05:55, "Dong, Eddie" <eddie.dong@xxxxxxxxx> 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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel