Hi Avi, Do you have other comments on this version of patch? Thanks, Dongxiao Xu, Dongxiao wrote: > Hi all, > > This is hosted VMM coexistence support v3. > > Main changes from v2: > 1) Change vmm_coexistence to vmm_exclusive. > 2) Some code structure changes. Split the original 3 patches to 4. > 3) Address some comments from Avi. > > Main changes from v1: > 1) Add an module option "vmm_coexistence" to decide whether to > enable this feature. Currently it is off defaultly. > 2) Each time when a KVM vcpu is scheduled in, it will invalidate EPT > and VPID TLBs to avoid conflict between different VMMs. > > 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. -- 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
