From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 5/24] Introduce vmcs12: a VMCS structure for L1 Date: Wed, 16 Jun 2010 16:10:59 +0300 Message-ID: <4C18CD63.8090604@redhat.com> References: <1276431753-nyh@il.ibm.com> <201006131225.o5DCP79H012922@rice.haifa.ibm.com> <4C15E95D.9000300@redhat.com> <20100616122427.GB11896@fermat.math.technion.ac.il> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: "Nadav Har'El" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:64716 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753573Ab0FPNLF (ORCPT ); Wed, 16 Jun 2010 09:11:05 -0400 In-Reply-To: <20100616122427.GB11896@fermat.math.technion.ac.il> Sender: kvm-owner@vger.kernel.org List-ID: On 06/16/2010 03:24 PM, Nadav Har'El wrote: > 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? > It's a way of adding a barrier to changing it, and of determining which versions are compatible with which other versions. > 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. > Right, it's only migration, not for guest use. Or perhaps for someone debugging a hypervisor. > 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. > Live migration will not work without ioctls to save/load the vmptr and vmxon state. nsvm has a hack where they force an exit before existing to host userspace, so host userspace never sees guest mode. I don't like it much, and in any case it can't work for nvmx since you need to migrate the vmxon state. -- error compiling committee.c: too many arguments to function