From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Nested SVM and migration Date: Sun, 21 Feb 2010 15:14:13 +0200 Message-ID: <4B8131A5.5060600@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: Zachary Amsden , Joerg Roedel , kvm To: Joerg Roedel Return-path: Received: from mx1.redhat.com ([209.132.183.28]:60431 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751398Ab0BUNOU (ORCPT ); Sun, 21 Feb 2010 08:14:20 -0500 In-Reply-To: <20100221130915.GB26465@8bytes.org> Sender: kvm-owner@vger.kernel.org List-ID: On 02/21/2010 03:09 PM, Joerg Roedel wrote: > >> 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? > (Either synthetic msrs, or an new state ioctl). The state would contain a bit that says whether the guest is in guest or host mode. However, since we're breaking the architecture one way or another, let's just go with the synthetic INTR intercept. -- error compiling committee.c: too many arguments to function