MIME-Version: 1.0
In-Reply-To: <87zi6elxaw.fsf@vitty.brq.redhat.com>
References: <20171218171742.5765-1-vkuznets@redhat.com> <20171218171742.5765-3-vkuznets@redhat.com>
 <CALMp9eT2j3bVnLn1_=x6LiVR=3Akxkt8y0We4rpNOpfgMxCyRg@mail.gmail.com>
 <CALMp9eThLdEUEcVOuyARP59_tv9pu5keGw4N5TCZ7MXjh4OiWg@mail.gmail.com> <87zi6elxaw.fsf@vitty.brq.redhat.com>
From: Jim Mattson <jmattson@google.com>
Date: Tue, 19 Dec 2017 09:44:01 -0800
Message-ID: <CALMp9eTgs=e5W-DvM10kQz-A-MJ3h51vV3A=aRZ4TD6fSD+DPg@mail.gmail.com>
Subject: Re: [PATCH RFC 2/7] KVM: nVMX: modify vmcs12 fields to match Hyper-V
 enlightened VMCS
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: kvm list <kvm@vger.kernel.org>,
        "the arch/x86 maintainers" <x86@kernel.org>,
        Paolo Bonzini <pbonzini@redhat.com>,
        =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= <rkrcmar@redhat.com>,
        "K. Y. Srinivasan" <kys@microsoft.com>,
        Haiyang Zhang <haiyangz@microsoft.com>,
        Stephen Hemminger <sthemmin@microsoft.com>,
        "Michael Kelley (EOSG)" <Michael.H.Kelley@microsoft.com>,
        Mohammed Gamal <mmorsy@redhat.com>, Cathy Avery <cavery@redhat.com>,
        Bandan Das <bsd@redhat.com>, Roman Kagan <rkagan@virtuozzo.com>,
        LKML <linux-kernel@vger.kernel.org>, devel@linuxdriverproject.org
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1408
Lines: 32

You can change the default VMCS12_REVISION and associated layout, as
long as support is maintained for the old layout and userspace has the
ability (e.g. by setting the IA32_VMX_BASIC MSR) to specify that a VM
needs to use the old layout.

On Tue, Dec 19, 2017 at 4:25 AM, Vitaly Kuznetsov <vkuznets@redhat.com> wrote:
> Jim Mattson <jmattson@google.com> writes:
>
>> At this point in time, I don't think you can just blithely change the
>> virtual VMCS layout and revision number. Existing VMs using the old
>> layout and revision number must continue to work on versions of kvm
>> past this point. You could tie the layout and revision number changes
>> to KVM_CAP_HYPERV_ENLIGHTENED_VMCS if you like, but kvm must be able
>> to continue to service VMs using the previous layout and revision
>> number in perpetuity.
>>
>
> I see what you mean. In case we need to keep migration of nested
> workloads working between KVMs of different versions we can't (ever)
> touch vmcs12.
>
> The way to go in this case, I think, is to create a completely separate
> enlightened_vmcs12 struct and use it when appropriate. We can't possibly
> support migrating workloads which use enlightened VMCS to an old KVM
> which doesn't support it.
>
> P.S. "If there are changes in this struct, VMCS12_REVISION must be
> changed." comment needs to be replaced with "Don't even think about
> changing this" :-)
>
> --
>   Vitaly