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: "Dong, Eddie" <eddie.dong@xxxxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, "He, Qing" <qing.he@xxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 06/16] vmx: nest: handling VMX instruction exits
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Wed, 15 Sep 2010 07:40:41 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 14 Sep 2010 23:41:39 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1A42CE6F5F474C41B63392A5F80372B22A8C201F@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: ActTNEZ5CcR+hpA2QfCxDoBGzzlciwBTwKVQAAdoRo4=
Thread-topic: [Xen-devel] [PATCH 06/16] vmx: nest: handling VMX instruction exits
User-agent: Microsoft-Entourage/
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.

 -- Keir

Xen-devel mailing list

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