Eduardo Habkost <ehabk...@redhat.com> writes: > On Tue, Jun 08, 2021 at 02:08:11PM +0200, Vitaly Kuznetsov wrote: >> Currently, the only eVMCS version, supported by KVM (and described in TLFS) >> is '1'. When Enlightened VMCS feature is enabled, QEMU takes the supported >> eVMCS version range (from KVM_CAP_HYPERV_ENLIGHTENED_VMCS enablement) and >> puts it to guest visible CPUIDs. When (and if) eVMCS ver.2 appears a >> problem on migration is expected: it doesn't seem to be possible to migrate >> from a host supporting eVMCS ver.2 to a host, which only support eVMCS >> ver.1. > > Should we rewrite this as "it wouldn't be possible to migrate", > as this patch fixes the problem and makes it possible?
Yes, no problem with such amendment. Currently, there's no issue as EVMCSv2 just doesn't exist. We, however, expect it to appear some time in the future and this change allows us to re-use KVM_CAP_HYPERV_ENLIGHTENED_VMCS in KVM without (potentially) breaking migrations. Note: the migration will only be broken when we migrate to KVM/QEMU which does not support EVMCSv2 *and* when the guest is already using it. As we expose the range of supported versions, it is possible that guests (esp. older Hyper-V versions) will stick to 'v1' even when 'v2' is supported. > >> >> Hardcode eVMCS ver.1 as the result of 'hv-evmcs' enablement for now. Newer >> eVMCS versions will have to have their own enablement options (e.g. >> 'hv-evmcs=2'). >> >> Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com> > > Reviewed-by: Eduardo Habkost <ehabk...@redhat.com> Thanks! Please let me know if expect v9 with amended commit message or if you're able to alter it upon commit. -- Vitaly
