On Fri, Apr 27, 2018 at 01:30:37PM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Apr 27, 2018 at 10:01:10AM -0700, Jim Mattson wrote:
> > Changing the VMCS12 layout breaks save/restore compatibility with
> > older kvm releases (and should induce a change of the VMCS12 revision
> > identifier).
> >
> > The new VMCS12 fields added in 2017 should be relocated so that the
> > offsets of previously existing fields do not change.
> >
> > Fixes: c5f983f6e8455 ("nVMX: Implement emulated Page Modification Logging")
> > Fixes: 27c42a1bb8674 ("KVM: nVMX: Enable VMFUNC for the L1 hypervisor")
> > Fixes: 41ab93727467c ("KVM: nVMX: Emulate EPTP switching for the L1 hypervisor")
> > Signed-off-by: Jim Mattson <jmattson@xxxxxxxxxx>
>
>
> So how does this work with vendors who have piggy backed on those patches
> and are already releasing this? Should this go to stable@xxxxxxxxxxxxxxx ?
<Heads swim>
c5f983f6e8455 shows up from 4.12 and further. Which means that you wouldn't
be able to migrate from a host running v4.12 to this newer kernel right?
Or am I silly b/c you wouldn't be able to migrate in the first place
as the savevm/restorevm does not do any VMX states so it would crash
anyhow?
If so, perhaps the commit should be amended to say this? That you can't
do migration until the new IOCTLs are added for the VMX states?
