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:30:14 -0800 Message-ID: <4B16B236.8000306@goop.org> References: <4B16AF4E.3050105@goop.org> <20091202182025.GA4866@zanzibar.quuxuum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20091202182025.GA4866@zanzibar.quuxuum.com> 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@eu.citrix.com, 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:20, Brendan Cully wrote: > What signal do you have in mind for telling the control stack that the > guest has completed its resume procedure and is running normally > again? > Hm, point. I was thinking of waiting for the "I'm suspended" hypercall, but that doesn't help. It has always worried me that the suspend protocol is very brittle. For example, there's no way for a guest to reject a suspend attempt, either because it doesn't support suspending, or it isn't convenient right now, or it tried but failed. A backchannel xenstore entry would allow the guest to indicate what stage its up to to the control stack, including holding off suspend attempts until it is ready to accept new ones. But that doesn't help much if you want to eliminate the xenstore overhead from the process... J