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