Gerd Hoffmann wrote: > I've passed in a physical address. The vmx_cr3_cache_msr() function has > a gva_to_page() call which makes me suspect it expects a virtual > address.
Confirmed. When passing in a virtual address it works. And it gives me a nice speedup for kernel builds: rhel5-64 kraxel ~# cat kbench-cr3-* date: Wed Jan 30 09:50:03 CET 2008 host: 2.6.18-53.el5xen x86_64 (cr3-cache) target: linux-2.6.21 i386 vmlinux config: allnoconfig 1: real 184.03 user 96.66 sys 41.30 2: real 137.23 user 91.57 sys 37.93 3: real 136.53 user 90.98 sys 38.39 date: Wed Jan 30 09:37:10 CET 2008 host: 2.6.18-53.el5xen x86_64 (cr3-nocache) target: linux-2.6.21 i386 vmlinux config: allnoconfig 1: real 182.47 user 112.33 sys 41.56 2: real 175.75 user 109.45 sys 40.53 3: real 173.54 user 108.49 sys 41.22 xen pv guests on 64bit do two cr3 switches per syscall due to kernel/userspace separation being done by having two different page table sets. Thus cr3 caching eliminates two vmexits per xen guest system call, and the pgd caching probably helps too. Watching statistics confirms that the number of vmexits goes down significantly. I strongly support cr3 caching being merged (after being cleaned up of course). cheers, Gerd ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
