From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH 06/16] vmx: nest: handling VMX instruction exits Date: Wed, 15 Sep 2010 12:46:36 +0100 Message-ID: References: <1A42CE6F5F474C41B63392A5F80372B22A8C230F@shsmsx501.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1A42CE6F5F474C41B63392A5F80372B22A8C230F@shsmsx501.ccr.corp.intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Dong, Eddie" , Tim Deegan Cc: "xen-devel@lists.xensource.com" , "He, Qing" List-Id: xen-devel@lists.xenproject.org On 15/09/2010 10:56, "Dong, Eddie" 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