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>, "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 09:15:16 +0100
Cc: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 15 Sep 2010 01:16:39 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1A42CE6F5F474C41B63392A5F80372B22A8C2219@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: ActUpneoepGHRb2rQXSLj4NDB6awkwAAof00AAB3VeAAANDxrA==
Thread-topic: [Xen-devel] [PATCH 06/16] vmx: nest: handling VMX instruction exits
User-agent: Microsoft-Entourage/
On 15/09/2010 08:56, "Dong, Eddie" <eddie.dong@xxxxxxxxx> wrote:

>> 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.
> So how about we reuse some functions in x86 emulate like this one?

Ah, well, now I look at your patch 06/16 properly, I think it's clear and
self-contained as it is. Your private enumerations within nest.c simply
serve to document the format of the decoded instruction provided to you via
fields in the VMCS. I wouldn't be inclined to change it at all, unless Tim
really has strong objections about it. It's not like you're defining
namespaces for new abstractions you have conjured from thin air -- they
correspond directly to a hardware-defined decode format. Defining
enumerations on top of that is *good*, imo. I would take 06/16 as it stands.

 -- Keir

> 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

Xen-devel mailing list