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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
