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 0 of 3] Remus: control tool

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "pasik@xxxxxx" <pasik@xxxxxx>, "konrad.wilk@xxxxxxxxxx" <konrad.wilk@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "andy@xxxxxxxxx" <andy@xxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0 of 3] Remus: control tool
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Wed, 02 Dec 2009 08:07:40 +0000
Delivery-date: Wed, 02 Dec 2009 00:08:07 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B15A111.1050004@xxxxxxxx>
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: Acpy2sA7IjDodxQXQluLpqdDpAge9QAS8Qge
Thread-topic: [Xen-devel] [PATCH 0 of 3] Remus: control tool
User-agent: Microsoft-Entourage/
On 01/12/2009 23:04, "Jeremy Fitzhardinge" <jeremy@xxxxxxxx> wrote:

> What's the bug?  I don't see a reentrancy issue there because the
> suspend happens synchronously in the xenwatch thread under
> xenwatch_mutex.  Or race for that matter.
> Am I missing something?
> Of course, if you start triggering suspends via event channels, we'll
> need to work out something else.

The issue in 2.6.18 was that, if doing back-to-back save/restores, the next
event-channel notification could come in before domU was finished with
previous s/r cycle, and then the notification got dropped. There are a
number of ways of dealing with that of course: I implemented a little state
machine; or you could probably do it with some kind of ticket-based scheme;
or perhaps have the evtchn irq handler spawn a kthread which blocks on the
mutex (I liked that one least as it needs to allocate resources).

 -- Keir

Xen-devel mailing list