On Wed, Jun 29, 2022, Vitaly Kuznetsov wrote: > Turns out Enlightened VMCS can gain new fields without version change > and KVM_CAP_HYPERV_ENLIGHTENED_VMCS which KVM currently has cant's > handle this reliably. In particular, just updating the current definition > of eVMCSv1 with the new fields and adjusting the VMX MSR filtering will > inevitably break live migration to older KVMs. Note: enabling eVMCS and > setting VMX feature MSR can happen in any order. > > Introduce a notion of KVM internal "Enlightened VMCS revision" and add > a new capability allowing to add fields to Enlightened VMCS while keeping > its version. Bumping a "minor" version number in KVM is going to be a nightmare. KVM is going to be stuck "supporting" old revisions in perpetuity, and userspace will be forced to keep track of which features are available with which arbitrary revision (is that information even communicated to userspace?). I think a more maintainable approach would be to expose the "filtered" VMX MSRs to userspace, e.g. add KVM_GET_EVMCS_VMX_MSRS. Then KVM just needs to document what the "filters" are for KVM versions that don't support KVM_GET_EVMCS_VMX_MSRS. KVM itself doesn't need to maintain version information because it's userspace's responsibility to ensure that userspace doesn't try to migrate to a KVM that doesn't support the desired feature set. That also avoids messes like unnecessarily blocking migration from "incompatible" revisions when running on hardware that doesn't even support the control.
