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