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

[Jeremy Fitzhardinge <jeremy@xxxxxxxx>]

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?

    J

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