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