From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 10/27] nVMX: Implement VMCLEAR Date: Sun, 17 Oct 2010 16:12:35 +0200 Message-ID: <4CBB0453.6050002@redhat.com> References: <1287309814-nyh@il.ibm.com> <201010171008.o9HA8g4E029408@rice.haifa.ibm.com> <4CBAF4B2.5000505@redhat.com> <20101017132522.GD14069@fermat.math.technion.ac.il> <4CBAF9D2.20100@redhat.com> <20101017133700.GE14069@fermat.math.technion.ac.il> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, gleb@redhat.com To: "Nadav Har'El" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:62425 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756983Ab0JQOMo (ORCPT ); Sun, 17 Oct 2010 10:12:44 -0400 In-Reply-To: <20101017133700.GE14069@fermat.math.technion.ac.il> Sender: kvm-owner@vger.kernel.org List-ID: On 10/17/2010 03:37 PM, Nadav Har'El wrote: > On Sun, Oct 17, 2010, Avi Kivity wrote about "Re: [PATCH 10/27] nVMX: Implement VMCLEAR": > > Is something preventing you from changing all kmap()s to kmap_atomic()s > > (like guest memory access in the mapped section)? > > Yes. We've discussed this before, and I know you suggested other alternatives, > but the way we currently work with vmcs12 (the page of memory that L1 maintains > as its VMCS for its L2 guest) is this: When L1 uses VMPTRLD to set the current > VMCS, we pin this page and kmap it, and keep a pointer to it immediately > accessible throughout the code. The page is only unmapped and released when > L1 is done with this VMCS (i.e., calls VMPTRLD again, or VMCLEAR, or of course > terminates). > > The nice thing about this approach, over the alternatives, is that it is > more efficient than special guest_read/write calls (accesses to vmcs12 are > ordinary memory accesses) and the code is simpler than it was previously > with map/unmap pairs around every access. > > Obviously, I can't use kmap_atomic() when the mapping is to live a long time, > also outside atomic constant. This could lead to bugs if two parts of the > Kernel use the same kmap_atomic() "slot" :( > Ok. Let's keep it for now. But look at http://thread.gmane.org/gmane.comp.emulators.kvm.devel/60920 for a much nicer way to to this (y, can you add kvm_read_guest_cached()?) Sorry about repeating old arguments, I kunmap_atomic() everything immediately after I review it. -- error compiling committee.c: too many arguments to function