This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 06/16] vmx: nest: handling VMX instruction exits
From: Qing He <qing.he@xxxxxxxxx>
Date: Wed, 15 Sep 2010 15:17:06 +0800
Cc: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Delivery-date: Wed, 15 Sep 2010 00:21:12 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C8B628F9.22F79%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1A42CE6F5F474C41B63392A5F80372B22A8C201F@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C8B628F9.22F79%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.20 (2009-06-14)
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?


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>