From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Nested SVM and migration Date: Sun, 21 Feb 2010 14:24:02 +0200 Message-ID: <4B8125E2.8050309@redhat.com> References: <4B80347E.7000003@redhat.com> <20100220201822.GG20833@8bytes.org> <4B806FB9.20009@redhat.com> <20100221121008.GI20833@8bytes.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Zachary Amsden , Joerg Roedel , kvm To: Joerg Roedel Return-path: Received: from mx1.redhat.com ([209.132.183.28]:44174 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751025Ab0BUMYH (ORCPT ); Sun, 21 Feb 2010 07:24:07 -0500 In-Reply-To: <20100221121008.GI20833@8bytes.org> Sender: kvm-owner@vger.kernel.org List-ID: On 02/21/2010 02:10 PM, Joerg Roedel wrote: > On Sat, Feb 20, 2010 at 01:26:49PM -1000, Zachary Amsden wrote: > >> The infrastructure is already there to import / export and migrate MSR >> settings. MSRs are also 64-bit, and hold "model-specific" settings, so >> if you don't mind thinking of the nested feature as a model-specific >> feature of the KVM-SVM CPU, it's even somewhat well defined in terms of >> the architecture. >> > There is a lot of additional state to migrate if the vcpu is running > nested. To be architecturally correct you need to transfer 6kb of data > through MSRs only for the msr permission bitmap. The msr permission bitmap is in guest memory, so it is already migrated. > The rest comes down to > the nested intercept masks These are in the vmcb, which is in guest memory. > and some small bits like the global interrupt > flag and the nested vmcb address. We need to migrate GIF regardless, it is toggled outside guest mode. > It is doable but I still think its > complicated to get this right. The simplest approach would be to > disallow migration when the vcpu is running in guest mode. > Agree, though I dislike the need to introduce a "force vmexit" ioctl. -- error compiling committee.c: too many arguments to function