| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH 0 of 3] Remus: control tool
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
|
|
|
| |
|
Home