From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: [PATCH 0 of 3] Remus: control tool Date: Wed, 02 Dec 2009 10:34:06 -0800 Message-ID: <4B16B31E.800@goop.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: "andy@cs.ubc.ca" , "xen-devel@lists.xensource.com" , "konrad.wilk@oracle.com" List-Id: xen-devel@lists.xenproject.org On 12/02/09 10:25, Keir Fraser wrote: > From the tools p.o.v. the restore has finished when it kicks off execution > of the guest. It's not that hard to handle this in the guest; you just need > to do it. ;-) Well, I think that just happens at the moment; the suspend is happening from the xenstore watch thread, so there's no way it will even notice a subsequent attempt until the suspend/resume cycle is done. When we start triggering suspends from event channels, I'd suggest something along the lines of wrapping the whole thing in a big fat suspend mutex, and running the suspend from a workqueue triggered from the interrupt or watch handler. And then deal with all the edge cases. J