Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762766AbdLSMZ0 (ORCPT ); Tue, 19 Dec 2017 07:25:26 -0500 Received: from mx1.redhat.com ([209.132.183.28]:38568 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1762742AbdLSMZS (ORCPT ); Tue, 19 Dec 2017 07:25:18 -0500 From: Vitaly Kuznetsov To: Jim Mattson Cc: kvm list , "the arch\/x86 maintainers" , Paolo Bonzini , Radim =?utf-8?B?S3LEjW3DocWZ?= , "K. Y. Srinivasan" , Haiyang Zhang , Stephen Hemminger , "Michael Kelley \(EOSG\)" , Mohammed Gamal , Cathy Avery , Bandan Das , Roman Kagan , LKML , devel@linuxdriverproject.org Subject: Re: [PATCH RFC 2/7] KVM: nVMX: modify vmcs12 fields to match Hyper-V enlightened VMCS References: <20171218171742.5765-1-vkuznets@redhat.com> <20171218171742.5765-3-vkuznets@redhat.com> Date: Tue, 19 Dec 2017 13:25:11 +0100 In-Reply-To: (Jim Mattson's message of "Mon, 18 Dec 2017 13:28:37 -0800") Message-ID: <87zi6elxaw.fsf@vitty.brq.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 19 Dec 2017 12:25:18 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1051 Lines: 26 Jim Mattson 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