From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joerg Roedel Subject: Re: List of unaccessible x86 states Date: Mon, 26 Oct 2009 11:45:27 +0100 Message-ID: <20091026104527.GI5326@amd.com> References: <4ADDB49B.3010101@siemens.com> <4AE2055A.3050001@web.de> <9D81B6EA-7161-4682-8685-79928C0AC2B3@suse.de> <4AE41F2F.2050700@redhat.com> <20091026091731.GF5326@amd.com> <4AE56A08.5090306@redhat.com> <20091026093020.GG5326@amd.com> <4AE56E62.2050509@redhat.com> <20091026095649.GH5326@amd.com> <4AE57555.7000602@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Alexander Graf , Jan Kiszka , kvm-devel list , Marcelo Tosatti , Gleb Natapov To: Avi Kivity Return-path: Received: from va3ehsobe005.messaging.microsoft.com ([216.32.180.15]:45559 "EHLO VA3EHSOBE005.bigfish.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755540AbZJZKpg (ORCPT ); Mon, 26 Oct 2009 06:45:36 -0400 Content-Disposition: inline In-Reply-To: <4AE57555.7000602@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Oct 26, 2009 at 12:09:25PM +0200, Avi Kivity wrote: > On 10/26/2009 11:56 AM, Joerg Roedel wrote: > >On Mon, Oct 26, 2009 at 11:39:46AM +0200, Avi Kivity wrote: > >>On 10/26/2009 11:30 AM, Joerg Roedel wrote: > >>>>Which host state? As far as I can tell, it can all be regenerated. > >>>The state which is loaded into the vcpu when a #vmexit is emulated. This > >>>includes segments, control registers and the host rip for example. > >>All of this state does not change between nested guest and normal > >>guest mode. > >I am talking about all the state that is saved in svm->nested.hsave. > >When we migrate a guest vcpu while it is running in guest mode itself > >(without forcing a nested #vmexit) this state is required when a #vmexit > >needs to be emulated on this vcpu after migration. > >Same is true for the nested intercept conditions. > > The state that is saved by VMRUN can be saved to guest memory and > migrated. Extra state (like the intercepts for the previous mode) > must be saved to host memory and not migrated; host intercepts can > be regenerated. Ok, parts of the state can be saved in guest memory. But thats currently not done. This will need some care to not introduce a security hole. But it shouldn't be too difficult. The state thats not reproducible in an sane way is the intercept bitmap for the l2 guest. >>From the nested state what needs to be exposed to userspace for migration is: * guest mode flag (as returned by is_nested) * nested vmcb address * nested hsave msr * nested intercepts * for nested nested paging: guest nested cr3 value Another state which needs exposure is the last branch record related state. Off-topic question: Will the new migration protocol include some kind handshake to find out if migration is possible at all? Joerg