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>
Subject: Re: [Xen-devel] [PATCH 06/16] vmx: nest: handling VMX instruction exits
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Wed, 15 Sep 2010 12:46:36 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "He, Qing" <qing.he@xxxxxxxxx>
Delivery-date: Wed, 15 Sep 2010 04:47:31 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1A42CE6F5F474C41B63392A5F80372B22A8C230F@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: ActUuBVZ1BtW90qoTSSeiBzOgS6AGQAA7Q8AAAP3P3E=
Thread-topic: [Xen-devel] [PATCH 06/16] vmx: nest: handling VMX instruction exits
User-agent: Microsoft-Entourage/
On 15/09/2010 10:56, "Dong, Eddie" <eddie.dong@xxxxxxxxx> wrote:

>> 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
> complicated.

Ah yes, presumably you will be picking one or the other and getting rid of
ifdefs in a future spin of this patchset? I don't personally care whether
you map or copy, though the former should be faster I guess? Anyway I think
your logic for mapping is too short and simplistic -- look at
hvm_map_entry() to see how it uses gfn_to_mfn_unshare (necessary if you will
be modifying the page) and handles the various return codes from that. You
could even factor out a common helper routine from hvm_map_entry() that you
could then use rather than open-coding very similar logic.

> 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).

No opinion myself. :-)

 -- Keir

Xen-devel mailing list