From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joerg Roedel Subject: Re: Nested SVM and migration Date: Sun, 21 Feb 2010 13:41:41 +0100 Message-ID: <20100221124141.GA26465@8bytes.org> References: <4B80347E.7000003@redhat.com> <20100220201822.GG20833@8bytes.org> <4B806FB9.20009@redhat.com> <20100221121008.GI20833@8bytes.org> <4B8125E2.8050309@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Zachary Amsden , Joerg Roedel , kvm To: Avi Kivity Return-path: Received: from 8bytes.org ([88.198.83.132]:41656 "EHLO 8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751025Ab0BUMln (ORCPT ); Sun, 21 Feb 2010 07:41:43 -0500 Content-Disposition: inline In-Reply-To: <4B8125E2.8050309@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Sun, Feb 21, 2010 at 02:24:02PM +0200, Avi Kivity wrote: > 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. This will work almost always but its not architecturally correct because the memory contents may have changed since the last vmrun instruction. On the other hand we already have this problem with the current nested msr intercept handling... >> The rest comes down to >> the nested intercept masks > > These are in the vmcb, which is in guest memory. Same as with the MSR permission map here. >> 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. Yes, this has possible issues too. If we reconstruct the nested state from the nested vmcb there is not much state left which needs migration. But we should keep in mind that this is not how real hardware works. Joerg