Xu, Dongxiao wrote:
quoted text > VMX: Support for coexistence of KVM and other hosted VMMs.
>
> The following NOTE is picked up from Intel SDM 3B 27.3 chapter,
> MANAGING VMCS REGIONS AND POINTERS.
>
> ----------------------
> NOTE
> As noted in Section 21.1, the processor may optimize VMX operation
> by maintaining the state of an active VMCS (one for which VMPTRLD
> has been executed) on the processor. Before relinquishing control to
> other system software that may, without informing the VMM, remove
> power from the processor (e.g., for transitions to S3 or S4) or leave
> VMX operation, a VMM must VMCLEAR all active VMCSs. This ensures
> that all VMCS data cached by the processor are flushed to memory
> and that no other software can corrupt the current VMM's VMCS data.
> It is also recommended that the VMM execute VMXOFF after such
> executions of VMCLEAR.
> ----------------------
>
> Currently, VMCLEAR is called at VCPU migration. To support hosted
> VMM coexistence, this patch modifies the VMCLEAR/VMPTRLD and
> VMXON/VMXOFF usages. VMCLEAR will be called when VCPU is
> scheduled out of a physical CPU, while VMPTRLD is called when VCPU
> is scheduled in a physical CPU. Also this approach could eliminates
> the IPI mechanism for original VMCLEAR. As suggested by SDM,
> VMXOFF will be called after VMCLEAR, and VMXON will be called
> before VMPTRLD.
>
> With this patchset, KVM and VMware Workstation 7 could launch
> serapate guests and they can work well with each other. Besides, I
> measured the performance for this patch, there is no visable
> performance loss according to the test results.
>
> The following performance results are got from a host with 8 cores.
>
> 1. vConsolidate benchmarks on KVM
>
> Test Round WebBench SPECjbb SysBench LoadSim GEOMEAN
> 1 W/O patch 2,614.72 28,053.09 1,108.41 16.30 1,072.95
> W/ patch 2,691.55 28,145.71 1,128.41 16.47 1,089.28
> 2 W/O patch 2,642.39 28,104.79 1,096.99 17.79 1,097.19
> W/ patch 2,699.25 28,092.62 1,116.10 15.54 1,070.98
> 3 W/O patch 2,571.58 28,131.17 1,108.43 16.39 1,070.70
> W/ patch 2,627.89 28,090.19 1,110.94 17.00 1,086.57
>
> Average
> W/O patch 2,609.56 28,096.35 1,104.61 16.83 1,080.28
> W/ patch 2,672.90 28,109.51 1,118.48 16.34 1,082.28
>
> 2. CPU overcommitment tests for KVM
>
> A) Run 8 while(1) in host which pin with 8 cores.
> B) Launch 6 guests, each has 8 VCPUs, pin each VCPU with one core.
> C) Among the 6 guests, 5 of them are running 8*while(1).
> D) The left guest is doing kernel build "make -j9" under ramdisk.
>
> In this case, the overcommitment ratio for each core is 7:1.
> The VCPU schedule frequency on all cores is totally ~15k/sec.
> l record the kernel build time.
>
> While doing the average, the first round data is treated as invalid,
> which isn't counted into the final average result.
>
> Kernel Build Time (second)
> Round w/o patch w/ patch
> 1 541 501
> 2 488 490
> 3 488 492
> 4 492 493
> 5 489 491
> 6 494 487
> 7 497 494
> 8 492 492
> 9 493 496
> 10 492 495
> 11 490 496
> 12 489 494
> 13 489 490
> 14 490 491
> 15 494 497
> 16 495 496
> 17 496 496
> 18 493 492
> 19 493 500
> 20 490 499
>
> Average 491.79 493.74
>
So the general message here is:
It does get slower, but not by much.
I think this should be a module option. By default we can probably go
with the non-coexist behavior. If users really want to run two VMMs on
the same host, they can always flip the module parameter.
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to
majordomo@vger.kernel.org
More majordomo info at
http://vger.kernel.org/majordomo-info.html
