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

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0 of 3] Remus: control tool
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Wed, 02 Dec 2009 18:25:29 +0000
Cc: "andy@xxxxxxxxx" <andy@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "konrad.wilk@xxxxxxxxxx" <konrad.wilk@xxxxxxxxxx>
Delivery-date: Wed, 02 Dec 2009 10:25:53 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B16AF4E.3050105@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: Acpze8VwWLoNN0AFQfmK4sw0mCnuXgAAQ3CI
Thread-topic: [Xen-devel] [PATCH 0 of 3] Remus: control tool
User-agent: Microsoft-Entourage/12.23.0.091001
On 02/12/2009 18:17, "Jeremy Fitzhardinge" <jeremy@xxxxxxxx> wrote:

> On 12/02/09 00:07, Keir Fraser wrote:
>> 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).
> 
> Hm, my first thought is "why does that matter?".  But I guess the
> host/guest save protocol is fairly brittle, and if the guest doesn't
> respond to a particular save it will get wedged.  But then, should the
> control stack be sending back to back save requests?  Shouldn't it wait
> until the previous save has finished?

>From the tools p.o.v. the restore has finished when it kicks off execution
of the guest. It's not that hard to handle this in the guest; you just need
to do it. ;-)

 -- Keir



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