From mboxrd@z Thu Jan 1 00:00:00 1970 From: BVK Chaitanya Subject: Re: [PATCH] serialize suspend-resume process Date: Fri, 01 Aug 2008 11:01:06 +0530 Message-ID: <48929F9A.2050504@symantec.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > > On 31/7/08 16:27, "BVK Chaitanya" wrote: > >> It is doing a busy-wait loop till suspend-resume cycle completes, if >> any. I found that it may go more than 25 msec sometimes. > > It's not a busy-wait loop. As long as shutdown_state does not change under > its feet, it will complete in no more than two iterations. > Yep, my mistake :-( I still have a concern, but it may not be important for xen-3.3 as of now. Let me explain: Dom0 can trigger a suspend-resume cycle and can wait for suspended notification back through event channel (and subscribe domctl). When dom0 is done with its checkpoint-ing or any work it can resume the domU. But resuming the domU doesn't complete suspend-resume cycle. Suspend-resume cycle is completed only after domU completes the xenbus_suspend_cancel function (I saw it taking more than 25msec.) Suspend requests sent during this suspend-cancel time are _lost_. If we assume dom0 shouldn't send suspend requests during suspend-cancel, there must be some way for dom0 to know when suspend-cancel is completed. AFAIK this doesn't exists in the current state. Does it clarify my concern? Shall i bring this issue back after xen-3.3 is release work is done? -- bvk-chaitanya