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:18:14 +0100 Message-ID: <20100221121814.GK20833@8bytes.org> References: <4B80347E.7000003@redhat.com> <20100220201822.GG20833@8bytes.org> <4B80DF7C.6000109@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]:50697 "EHLO 8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751868Ab0BUMSP (ORCPT ); Sun, 21 Feb 2010 07:18:15 -0500 Content-Disposition: inline In-Reply-To: <4B80DF7C.6000109@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Sun, Feb 21, 2010 at 09:23:40AM +0200, Avi Kivity wrote: > On 02/20/2010 10:18 PM, Joerg Roedel wrote: >> I think we should introduce a flag to indicate userspace if a vcpu is in >> a state that could be migrated in a save way together with a way for >> userspace to request that the vcpu enters a migratable state. In the >> kernel we could do something like that: >> >> nested_svm_vmrun(...) >> { >> /* ... */ >> kvm_migration_disable(vcpu); >> /* ... */ >> } >> >> nested_svm_vmexit(...) >> { >> /* ... */ >> kvm_migration_enable(vcpu); >> /* ... */ >> } >> >> and somewhere in the vcpu_run loop: >> >> if (vcpu->arch.migration_win_req) >> nested_svm_vmexit(INTR); >> >> This might be helpful in other situations too. Thoughts? >> > > This doesn't work if the guest disables INTR intercepts, or if the guest > checks that an interrupt was actually received. Of course no sane guest > does this. We could just wait for an intercept if the guest does not intercept INTR (which is unlikely). Problem is that this might allow the guest to protect itself from migration. I'll check if there is another intercept which could be used here. Joerg