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:43:24 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sun, 07 Sep 2008 00:43:27 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20080907071520.GB36704@xxxxxxxxxxxxxxxxx>
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: AckQvWg1poLqMnywEd2cRgAWy6hiGQ==
Thread-topic: [Xen-devel] [PATCH] xc_save: ignore the first suspend event channel notification
User-agent: Microsoft-Entourage/
On 7/9/08 08:15, "Brendan Cully" <brendan@xxxxxxxxx> wrote:

>>> 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.

Ah, I hadn't spotted that bit. I'll think about it - maybe your approach is
simplest after all.

 -- Keir

Xen-devel mailing list