Re: [PATCH 0/3] KVM: VMX: Support hosted VMM coexsitence.

[Avi Kivity <avi@redhat.com>]

On 03/18/2010 11:49 AM, Xu, Dongxiao wrote:
> 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.
>    

My worry is that newer processors will cache more and more VMCS contents 
on-chip, so the VMCLEAR/VMXOFF will cause a greater loss with newer 
processors.

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

Is that the only motivation?  It seems like an odd use-case.  If there 
was no performance impact (current or future), I wouldn't mind, but the 
design of VMPTRLD/VMCLEAR/VMXON/VMXOFF seems to indicate that we want to 
keep a VMCS loaded as much as possible on the processor.

-- 
error compiling committee.c: too many arguments to function