WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] xc_save: ignore the first suspend event channel

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] xc_save: ignore the first suspend event channel notification
From: Brendan Cully <brendan@xxxxxxxxx>
Date: Sun, 7 Sep 2008 00:15:20 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sun, 07 Sep 2008 00:15:44 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C4E93D34.1CEAA%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Mail-followup-to: keir.fraser@xxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx
References: <C4E93BE9.1CEA7%keir.fraser@xxxxxxxxxxxxx> <C4E93D34.1CEAA%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.18 (2008-08-30)
On Sunday, 07 September 2008 at 08:11, Keir Fraser wrote:
> On 7/9/08 08:06, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:
> 
> >> I could certainly code this up as well (it'd need a static flag in
> >> evtchn_suspend as well to avoid resignalling the domain, I think). But
> >> generally without clearing the event channel before signalling the
> >> guest, the first suspend attempt will always return early. I'm not
> >> really clear on the scenario that results in the domain not being
> >> suspended after *suspend has succesfully returned. Could you clarify?
> > 
> > I don't like the forced initial consumption of a single evtchn signal. I'd
> > like rid of that and change the retry loop to call (*suspend) instead. Add
> > an extra boolean to the static suspend_info structure to detect first
> > invocation of (*suspend) versus repeated invocations.
> 
> Actually I can knock these changes together myself, so I'll do that, taking
> whatever bits of your patch are appropriate.

Ok, sure. I still think it's a bit unfortunate that the suspend
function will return without waiting for the domain to suspend, and
not just because of the extra round trip. At the end of the suspend
function, xend is under the impression that the guest has suspended
and it can perform device migration stage 2. I wonder if it's
dangerous to do this before confirming that the guest has actually
suspended.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel