From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Nested SVM and migration Date: Sun, 21 Feb 2010 10:12:27 +0200 Message-ID: <4B80EAEB.5040209@redhat.com> References: <4B80347E.7000003@redhat.com> <20100220201822.GG20833@8bytes.org> <4B80DF7C.6000109@redhat.com> <20100221074633.GM14767@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Joerg Roedel , Zachary Amsden , Joerg Roedel , kvm To: Gleb Natapov Return-path: Received: from mx1.redhat.com ([209.132.183.28]:37078 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753902Ab0BUIMj (ORCPT ); Sun, 21 Feb 2010 03:12:39 -0500 In-Reply-To: <20100221074633.GM14767@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 02/21/2010 09:46 AM, Gleb Natapov wrote: > On Sun, Feb 21, 2010 at 09:23:40AM +0200, Avi Kivity wrote: > >> On 02/20/2010 10:18 PM, Joerg Roedel wrote: >> >>> >>>> Actually, looking deeper, there doesn't even appear to be any way to >>>> export the nested CPU data at all, meaning basic features like >>>> suspending and restoring the VM are not possible. Is there any plan to >>>> make it work in the near future? I'm not complaining; if my >>>> understanding is correct, this actually makes my current task easier. >>>> >>> 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. >> >> > Malicious guest may do this on purpose just to prevent migration. > We #vmexit unconditionally; the malicious guest will break if it doesn't handle INTR intercepts even when it did not enable them, but migration will succeed. > Relying on vcpu state controllable by a guest for migration is not a > good idea. > I agree, but that is not the case here. Regardless, I'd prefer to migrate the guest in its original state (and not force a #vmexit), so long as it isn't horribly complicated. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.