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

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

Xen-devel mailing list