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/
Home Products Support Community News


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

To: Brendan Cully <brendan@xxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] xc_save: ignore the first suspend event channel notification
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Sun, 07 Sep 2008 08:06:01 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sun, 07 Sep 2008 00:06:04 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20080907022833.GA36704@xxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AckQuC9Hba5oCHyrEd2cRgAWy6hiGQ==
Thread-topic: [Xen-devel] [PATCH] xc_save: ignore the first suspend event channel notification
User-agent: Microsoft-Entourage/
On 7/9/08 03:28, "Brendan Cully" <brendan@xxxxxxxxx> wrote:

>> To do this, call (*suspend) from within the retry loop: the evtchn case can
>> do what it always does (basically sleep on the evtchn device until its
>> evtchn of interest appears); the compat case should change behaviour after
>> its first invocation so that it sleeps 10ms (stash a static variable in the
>> function or in suspendinfo for this purpose, to remember whether it was
>> already invoked).
> 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.

 -- Keir

Xen-devel mailing list