On 15.05.2009, at 10:22, Alexander Graf wrote:
Now that we have nested SVM in place, let's make use of it and
virtualize
something non-kvm.
The first interesting target that came to my mind here was Hyper-V.
This patchset makes Windows Server 2008 boot with Hyper-V, which runs
the "dom0" in virtualized mode already. I haven't been able to run a
second VM within for now though, but maybe I just wasn't patient
enough ;-).
In order to find out why things were slow with nested SVM I hacked
intercept reporting into debugfs in my local tree and found pretty
interesting results (using NPT):
SVM_EXIT_CLGI 3888080 0
SVM_EXIT_CPUID 3460 0
SVM_EXIT_CR0_SEL_WRI 0 0
SVM_EXIT_ERR 0 0
SVM_EXIT_FERR_FREEZE 0 0
SVM_EXIT_GDTR_READ 0 0
SVM_EXIT_GDTR_WRITE 0 0
SVM_EXIT_HLT 40186 0
SVM_EXIT_ICEBP 0 0
SVM_EXIT_IDTR_READ 0 0
SVM_EXIT_IDTR_WRITE 0 0
SVM_EXIT_INIT 0 0
SVM_EXIT_INTR 193173 0
SVM_EXIT_INVD 0 0
SVM_EXIT_INVLPG 1 0
SVM_EXIT_INVLPGA 536994 0
SVM_EXIT_IOIO 3450484 0
SVM_EXIT_IRET 0 0
SVM_EXIT_LDTR_READ 0 0
SVM_EXIT_LDTR_WRITE 0 0
SVM_EXIT_MONITOR 0 0
SVM_EXIT_MSR 124614 0
SVM_EXIT_MWAIT 0 0
SVM_EXIT_MWAIT_COND 0 0
SVM_EXIT_NMI 0 0
SVM_EXIT_NPF 1040416 0
SVM_EXIT_PAUSE 0 0
SVM_EXIT_POPF 0 0
SVM_EXIT_PUSHF 0 0
SVM_EXIT_RDPMC 0 0
SVM_EXIT_RDTSC 0 0
SVM_EXIT_RDTSCP 0 0
SVM_EXIT_RSM 0 0
SVM_EXIT_SHUTDOWN 0 0
SVM_EXIT_SKINIT 0 0
SVM_EXIT_SMI 20 0
SVM_EXIT_STGI 3888080 0
SVM_EXIT_SWINT 0 0
SVM_EXIT_TASK_SWITCH 0 0
SVM_EXIT_TR_READ 0 0
SVM_EXIT_TR_WRITE 0 0
SVM_EXIT_VINTR 402865 0
SVM_EXIT_VMLOAD 3888096 0
SVM_EXIT_VMMCALL 767288 0
SVM_EXIT_VMRUN 3888096 0
SVM_EXIT_VMSAVE 3888096 0
SVM_EXIT_WBINVD 64 0
So apparently the most intercepts come from the SVM helper calls
(clgi, stgi, vmload, vmsave). I guess I need to get back to the
"emulate when GIF=0" approach to get things fast.
Alex
--
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
