From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH 0/5] KVM paravirt_ops implementation Date: Wed, 20 Jun 2007 17:08:15 -0500 Message-ID: <4679A54F.5020908@codemonkey.ws> References: <4675F462.1010708@codemonkey.ws> <4675F9DE.6080806@goop.org> <4675FDCA.4040006@codemonkey.ws> <4676084F.3090901@goop.org> <46787325.30804@vmware.com> <4679381E.9090404@codemonkey.ws> <46794899.6070708@goop.org> <46798174.2060304@vmware.com> <46798597.4020903@codemonkey.ws> <4679882B.7070605@vmware.com> <46798B16.5090407@goop.org> <46798D9B.5000400@codemonkey.ws> <46798F1A.4090901@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <46798F1A.4090901-TSDbQ3PG+2Y@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Jeremy Fitzhardinge Cc: Zachary Amsden , kvm-devel , virtualization List-Id: virtualization@lists.linuxfoundation.org Jeremy Fitzhardinge wrote: > Anthony Liguori wrote: >> I've been thinking about this wrt the hypercall page in KVM. The >> problem is that in a model like KVM (or presumably VMI), migration >> gets really difficult if you have anything but a trivial hypercall >> page since the hypercall page will change after migration. >> >> If you cannot guarantee the guest isn't executing code within the >> hypercall page (or in your case, doing something with paravirt_ops), >> then you cannot safely migrate. > > Hm, you need to quiesce the kernel in some way when you do a migrate, > so making sure it isn't in a hypercall would be just part of that. In > general you'd make sure all but one CPU is parked somewhere, and the > remaining CPU is doing the suspend, right? The real trick is doing it without the guest being involved at all. Right now, it won't be a problem in KVM since the hypercall page only differs by a single instruction across platforms. In the future, we'll have to be smarter and wait for all VCPUs to leave the hypercall page. > The tricky part for Xen in all this is how to make sure all mfn > references are visible to the hypervisor/toolstack so they can be > remapped; hypercall page contents are not a concern by comparison. I don't know HVM save/resume all that well but I think it's a similar model where the guest isn't involved. They may have a similar issue when using PV drivers. Regards, Anthony Liguori > J > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/