Re: [PATCH 5/24] Introduce vmcs12: a VMCS structure for L1

From: Avi Kivity <avi@redhat.com>
To: "Nadav Har'El" <nyh@math.technion.ac.il>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH 5/24] Introduce vmcs12: a VMCS structure for L1
Date: Wed, 16 Jun 2010 16:10:59 +0300	[thread overview]
Message-ID: <4C18CD63.8090604@redhat.com> (raw)
In-Reply-To: <20100616122427.GB11896@fermat.math.technion.ac.il>

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