From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zachary Amsden Subject: Re: Nested SVM and migration Date: Mon, 22 Feb 2010 06:46:19 -1000 Message-ID: <4B82B4DB.1090703@redhat.com> References: <4B80347E.7000003@redhat.com> <20100220201822.GG20833@8bytes.org> <4B806FB9.20009@redhat.com> <20100221121008.GI20833@8bytes.org> <4B8125E2.8050309@redhat.com> <20100221124141.GA26465@8bytes.org> <4B812CE9.2070107@redhat.com> <20100221130915.GB26465@8bytes.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Avi Kivity , Joerg Roedel , kvm To: Joerg Roedel Return-path: Received: from mx1.redhat.com ([209.132.183.28]:58483 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752509Ab0BVQqX (ORCPT ); Mon, 22 Feb 2010 11:46:23 -0500 In-Reply-To: <20100221130915.GB26465@8bytes.org> Sender: kvm-owner@vger.kernel.org List-ID: On 02/21/2010 03:09 AM, Joerg Roedel wrote: > On Sun, Feb 21, 2010 at 02:54:01PM +0200, Avi Kivity wrote: > >> So, if some other cpu (or the guest itself, with appropriate >> permissions) modifies the msr permission bitmap, svm will not notice >> this? svm loads the bitmap during entry? >> > Yes. > Ugh. So we have non-reversible architectural state all over again. There are ways around this problem, all ugly, but the easiest is shadowing the MSR permission bitmap. >> I don't think you can tell, unless the host cpu modifying the vmcb is >> synchronized with the guest (or the guest modifies its own vmcb). But >> this is all academic. >> > Hmm, another thing comes to mind. We would need some redesign of the > nested_svm code to allow userspace to put a vcpu directly into nested > state. With the MSR approach, all userspace does is to write MSRs into > the vcpu before the first run? > How does MSR_KVM_NESTED_SVM_ACTIVE not solve this problem?