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
|
Home