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: Tim Deegan <Tim.Deegan@xxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH 06/16] vmx: nest: handling VMX instruction exits
From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Wed, 15 Sep 2010 17:56:47 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>, "He, Qing" <qing.he@xxxxxxxxx>
Delivery-date: Wed, 15 Sep 2010 03:02:42 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20100915092626.GB11387@xxxxxxxxxxxxxxxxxxxxxxx>
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: <1A42CE6F5F474C41B63392A5F80372B22A8C2219@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C8B63F24.22FD4%keir.fraser@xxxxxxxxxxxxx> <20100915092626.GB11387@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: ActUuBVZ1BtW90qoTSSeiBzOgS6AGQAA7Q8A
Thread-topic: [Xen-devel] [PATCH 06/16] vmx: nest: handling VMX instruction exits
>> 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. 
> Fair enough, but I'd like the memory leak fixed too (svmcs and vvmcs
> are only freed if the N1 guest executes VMXOFF).
Sure. Fixed it locally at vmx_destroy_vmcs.

BTW, how do you like CONFIG_VVMCS_MAPPING ? I feel a little bit more 

And how about rename vvmcs to vmcs12 (VMCS used by L1 VMM for L2 guest), and
rename svmcs as vmcs02 (VMCS used by L0 VMM for L2 guest).
Of course hvmcs becomes vmcs01 then, (VMCS used by L0 VMM for L1 guest).

Thx, Eddie
Xen-devel mailing list