From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Nadav Har'El" Subject: Re: [PATCH 5/24] Introduce vmcs12: a VMCS structure for L1 Date: Wed, 16 Jun 2010 15:24:27 +0300 Message-ID: <20100616122427.GB11896@fermat.math.technion.ac.il> References: <1276431753-nyh@il.ibm.com> <201006131225.o5DCP79H012922@rice.haifa.ibm.com> <4C15E95D.9000300@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from mailgw11.technion.ac.il ([132.68.225.11]:21627 "EHLO mailgw11.technion.ac.il" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754402Ab0FPMYa (ORCPT ); Wed, 16 Jun 2010 08:24:30 -0400 Content-Disposition: inline In-Reply-To: <4C15E95D.9000300@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Jun 14, 2010, Avi Kivity wrote about "Re: [PATCH 5/24] Introduce vmcs12: a VMCS structure for L1": > >+struct __attribute__ ((__packed__)) vmcs12 { > >+ /* According to the Intel spec, a VMCS region must start with the > >+ * following two fields. Then follow implementation-specific data. > >+ */ > >+ u32 revision_id; > >+ u32 abort; > >+}; > > > > Note that this structure becomes an ABI, it cannot change except in a > backward compatible way due to the need for live migration. So I'd like > a documentation patch that adds a description of the content to > Documentation/kvm/. It can be as simple as listing the structure > definition. I agree that if struct vmcs12 is changed, this will cause problems for live migration, but why does this mean that the struct's fields or layout an ABI worth documenting? After all, isn't the idea of VMCS that its internal content and layout is opaque for the L1 guest - he can only read/write it with VMREAD/VMWRITE, and those two instructions are the ABI (which is of course documented in the Intel spec) - not the content of the vmcs12 structure. Even if the guest knew the exact layout of this structure, he's not supposed to use it. By the way, we have not actually checked that live migration is working as expected with nested virtualization running. I expect there to be more pitfalls and bugs even before we consider migration between two different versions. We would indeed like to allow live migration of different kinds (of L1 with all its L2 guests; Of all L2 guests of a L1; Of a single L2 guest), but we're trying to finish the more basic functionality first. Thanks, Nadav. -- Nadav Har'El | Wednesday, Jun 16 2010, 4 Tammuz 5770 nyh@math.technion.ac.il |----------------------------------------- Phone +972-523-790466, ICQ 13349191 |It is error alone which needs the support http://nadav.harel.org.il |of government. Truth can stand by itself.