From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joerg Roedel Subject: Re: Nested SVM and migration Date: Sun, 21 Feb 2010 14:09:15 +0100 Message-ID: <20100221130915.GB26465@8bytes.org> 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> 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]:47082 "EHLO 8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751181Ab0BUNJQ (ORCPT ); Sun, 21 Feb 2010 08:09:16 -0500 Content-Disposition: inline In-Reply-To: <4B812CE9.2070107@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. > 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? Joerg