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:56:28 -1000 Message-ID: <4B82B73C.6030600@redhat.com> References: <4B806FB9.20009@redhat.com> <20100221121008.GI20833@8bytes.org> <4B8125E2.8050309@redhat.com> <20100221124141.GA26465@8bytes.org> <4B812CE9.2070107@redhat.com> <20100221130915.GB26465@8bytes.org> <4B8131A5.5060600@redhat.com> <4B8137E7.4030001@redhat.com> <20100221144352.GC26465@8bytes.org> <4B814C41.7010105@redhat.com> <20100221155624.GD26465@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]:1244 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752330Ab0BVQ4c (ORCPT ); Mon, 22 Feb 2010 11:56:32 -0500 In-Reply-To: <20100221155624.GD26465@8bytes.org> Sender: kvm-owner@vger.kernel.org List-ID: On 02/21/2010 05:56 AM, Joerg Roedel wrote: > On Sun, Feb 21, 2010 at 05:07:45PM +0200, Avi Kivity wrote: > >> On 02/21/2010 04:43 PM, Joerg Roedel wrote: >> >>> Difficult. We could use an instruction intercept which has no side >>> effect on guest state (invlpg for example). >>> >> Especially as the guest might disable it and BUG() if npt is enabled. >> >> >>> But thats a lot more >>> dangerous than an INTR intercept. What about PENDING_INTERRUPT? Are >>> there hypervisors that may get confused getting this intercept without >>> asking for it? >>> >>> >> That will likely confuse kvm, it means interrupts are not blocked so it >> is okay to inject one, and if the guest is running with interrupts >> disabled then the next entry will fail. >> > Completly different idea: > > 1. Give userspace an ioctl to freeze the complete VM (all vcpus must be > stopped afterwards) > 2. The freeze routine does the following: > > freeze_vm(...) > { > stop_all_vcpus(); > for_each_vcpu(vcpu) > kvm_x86_ops->freeze_vcpu(vcpu); > } > > The module specific freeze_vcpu function can save the nested state > inside the guests memory (vmcs area for nested-vmx and hsave area for > nested-svm). When no vcpu is running anymore this is save. > > After migration the information is restored from there before any vcpu > is started again. > > unfreeze_vm(...) > { > for_each_vcpu(vcpu) > kvm_x86_ops->unfreeze_vcpu(vcpu); > restart_all_vcpus(); > } > This is exactly the ioctl approach, yes? > In the SVM case this still leaves the problem that the MSR bitmap must > be read again from guests memory on unfreeze but that is not a real > problem. > This is easily solved by shadowing the MSR bitmap. Too bad we have to do it, but at least the state isn't hidden in a non-extractable field inside the processor. Zach