KVM: nVMX: RFC: Eliminate vmcs02?

KVM: nVMX: RFC: Eliminate vmcs02?

[Jim Mattson]

Is anyone particularly attached to using the vmcs02 for L2 execution?
I'm working on checkpoint/restore for nested VMs, and I find that this
construct is a bit of a headache.

On restore, I'd really like to be able to set pieces of the vCPU state
in any order. However, because KVM_SET_REGS, KVM_SET_SREGS and
KVM_SET_MSRS write to the current VMCS, I either have to require that
the "guest mode" of the vCPU be restored first, or I have to be able
to transfer the just-restored L2 state from the vmcs01 to the vmcs02
when the "guest mode" is restored.

The vmcs02 construct has never lived up to its original design goals.
Five years after its introduction, the vmcs02 pool still has just one
entry.

If we eliminate the vmcs02 (and use the same VMCS for both L1 and L2),
we do have to reset the L0->L1 VM execution controls on emulated
VM-exit, but we can avoid setting  the constant host state fields on
emulated VM-entry, so it's probably a wash in terms of execution time.
(Admittedly, there are other ways of eliminating the call to
vmx_set_constant_host_state for most emulated VM-enrties.) The
resulting code simplification seems like a win, particularly when
checkpointing/restoring nested VMs.

However, if eliminating the vmcs02 would be met with disapproval, I
will explore other alternatives for checkpoint/restore.

Re: KVM: nVMX: RFC: Eliminate vmcs02?

[Paolo Bonzini]

On 12/08/2016 22:47, Jim Mattson wrote:
> If we eliminate the vmcs02 (and use the same VMCS for both L1 and L2),
> we do have to reset the L0->L1 VM execution controls on emulated
> VM-exit, but we can avoid setting  the constant host state fields on
> emulated VM-entry, so it's probably a wash in terms of execution time.
> (Admittedly, there are other ways of eliminating the call to
> vmx_set_constant_host_state for most emulated VM-enrties.) The
> resulting code simplification seems like a win, particularly when
> checkpointing/restoring nested VMs.
> 
> However, if eliminating the vmcs02 would be met with disapproval, I
> will explore other alternatives for checkpoint/restore.

I agree that the naming of the concepts (vmcs01, vmcs02, vmcs12) is
useful and it's also useful to have it in the function names, but it
does introduce some complication.

Actually I've never really cared much about VMCS02 pools.  My plan
behind the VMCS02 was more to limit the work done in prepare_vmcs02 by
caching what's been dirtied by VMWRITEs.  I'd definitely not care if you
want to get rid of the (one-element) pool, but I wonder if the separate
VMCS02 could help optimizing vmentry a bit more.

Paolo