From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 0/30] nVMX: Nested VMX, v9 Date: Mon, 23 May 2011 17:32:43 +0300 Message-ID: <4DDA700B.2040400@redhat.com> References: <20110512154228.GA7943@fermat.math.technion.ac.il> <20110512155727.GA20193@redhat.com> <20110512163115.GA13138@fermat.math.technion.ac.il> <20110512165157.GC20193@redhat.com> <20110522193239.GA13130@fermat.math.technion.ac.il> <4DDA2E72.8070907@redhat.com> <20110523130226.GC23407@8bytes.org> <4DDA5C30.10107@redhat.com> <20110523134052.GD23407@8bytes.org> <4DDA66AF.7020505@redhat.com> <20110523141000.GA20428@fermat.math.technion.ac.il> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Joerg Roedel , Gleb Natapov , kvm@vger.kernel.org, abelg@il.ibm.com To: "Nadav Har'El" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:2773 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754377Ab1EWOcz (ORCPT ); Mon, 23 May 2011 10:32:55 -0400 In-Reply-To: <20110523141000.GA20428@fermat.math.technion.ac.il> Sender: kvm-owner@vger.kernel.org List-ID: On 05/23/2011 05:10 PM, Nadav Har'El wrote: > On Mon, May 23, 2011, Avi Kivity wrote about "Re: [PATCH 0/30] nVMX: Nested VMX, v9": > > I think for Intel there is no hidden state apart from in-guest-mode > > (there is the VMPTR, but it is an actual register accessible via > > instructions). > > is_guest_mode(vcpu), vmx->nested.vmxon, vmx->nested.current_vmptr are the > only three things I can think of. Vmxon is actually more than a boolean > (there's also a vmxon pointer). > > What do you mean by the current_vmptr being available through an instruction? > It is (VMPTRST), but this would be an instruction run on L1 (emulated by L0). > How would L0's user space use that instruction? I mean that it is an architectural register rather than "hidden state". It doesn't mean that L0 user space can use it. > > I agree it's a benefit. But I don't like making the fake vmexit part of > > live migration, if it turns out the wrong choice it's hard to undo it. > > If you don't do this "fake vmexit", you'll need to migrate both vmcs01 and > the current vmcs02 - the fact that vmcs12 is in guest memory will not be > enough, because vmcs02 isn't copied back to vmcs12 until the nested exit. > vmcs01 and vmcs02 will both be generated from vmcs12. -- error compiling committee.c: too many arguments to function