Re: [Xen-devel] [PATCH 0 of 3] Remus: control tool

[Brendan Cully <brendan@xxxxxxxxx>]

On Wednesday, 02 December 2009 at 10:17, Jeremy Fitzhardinge 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?

What signal do you have in mind for telling the control stack that the
guest has completed its resume procedure and is running normally
again?

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