From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [PATCH 10/27] nVMX: Implement VMCLEAR Date: Sun, 17 Oct 2010 16:14:33 +0200 Message-ID: <20101017141433.GA16865@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> <4CBB0453.6050002@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Nadav Har'El" , kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:25904 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757099Ab0JQOOi (ORCPT ); Sun, 17 Oct 2010 10:14:38 -0400 Content-Disposition: inline In-Reply-To: <4CBB0453.6050002@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Sun, Oct 17, 2010 at 04:12:35PM +0200, Avi Kivity wrote: > 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()?) > Yes, haven't done that because my patch set does not have use for it. > Sorry about repeating old arguments, I kunmap_atomic() everything > immediately after I review it. > > -- > error compiling committee.c: too many arguments to function -- Gleb.