On Wed, Nov 7, 2018 at 4:13 PM, Liran Alon <liran.alon@xxxxxxxxxx> wrote: > Ping on my last reply. > I would like to reach to an agreement on how v3 should look like before just implementing what I think is right. > > Thanks, > -Liran I have no attachments to the current design. I had used a data[] blob, because I didn't think userspace would have any need to know what was in there. However, I am now seeing the error of my ways. For example, the userspace instruction emulator needs to know the contents of the vmcs12 to emulate instructions when in guest mode. I had been in favor of KVM_CAPs, because they are one way to ensure that the guest doesn't dynamically enter a state that isn't backwards compatible. But other gates are also possible. If you have to support destination kernels that don't know about the shadow vmcs12 component of the nested state, userspace can just clear bit 46 of L1's IA32_VMX_PROCBASED_CTLS2 MSR. For the VMX preemption timer, clear bit 38 of L1's IA32_VMX_PINBASED_CTLS MSR. KVM_CAPs can be reserved for incompatible changes due to bug-fixes, like KVM_CAP_EXCEPTION_PAYLOAD, where there isn't another gate available. If, for example, we hadn't realized ahead of time that migration of the VMX preemption timer isn't yet supported, some userspace implementation may not have cleared bit 38 of L1's IA32_VMX_PINBASED_CTLS MSR, and then we would have to gate the new nested state component behind a KVM_CAP. As long as userspace can ensure that the kernel will only produce backwards compatible save-state when it has to, my basic requirements are met.
