From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: List of unaccessible x86 states Date: Mon, 26 Oct 2009 12:56:31 +0200 Message-ID: <4AE5805F.6020705@redhat.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> <20091026104527.GI5326@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Graf , Jan Kiszka , kvm-devel list , Marcelo Tosatti , Gleb Natapov To: Joerg Roedel Return-path: Received: from mx1.redhat.com ([209.132.183.28]:22663 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755558AbZJZK4b (ORCPT ); Mon, 26 Oct 2009 06:56:31 -0400 In-Reply-To: <20091026104527.GI5326@amd.com> Sender: kvm-owner@vger.kernel.org List-ID: On 10/26/2009 12:45 PM, Joerg Roedel wrote: > > 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 > Yes, forgot that. We can store it in the hsave area (note the hsave area format becomes an ABI). > * nested hsave msr > That's already saved. > * nested intercepts > These are part of the guest vmcb. The host nested intercepts can be recalculated, no? > * for nested nested paging: guest nested cr3 value > Part of the guest vmcb. > Another state which needs exposure is the last branch record related > state. > Aren't those just more MSRs? > Off-topic question: Will the new migration protocol include some kind > handshake to find out if migration is possible at all? > > It's assumed that migration always works for a newer qemu version, and that the management tools don't attempt backward migration. -- error compiling committee.c: too many arguments to function