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:10:08 +0100 Message-ID: <20100221121008.GI20833@8bytes.org> References: <4B80347E.7000003@redhat.com> <20100220201822.GG20833@8bytes.org> <4B806FB9.20009@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Joerg Roedel , Avi Kivity , kvm To: Zachary Amsden Return-path: Received: from 8bytes.org ([88.198.83.132]:33003 "EHLO 8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751705Ab0BUMKK (ORCPT ); Sun, 21 Feb 2010 07:10:10 -0500 Content-Disposition: inline In-Reply-To: <4B806FB9.20009@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 rest comes down to the nested intercept masks and some small bits like the global interrupt flag and the nested vmcb address. 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. > Mostly the problem is figuring out what chunk of MSR space to use. And hoping that this MSR space is not used by real hardware in the future ;-) Joerg