From: Keir Fraser
Sent: 2006年11月6日 2:00
> bit cheesy as far as I can see, so something more integrated in the
> tpmfront/back protocol would be nice.
In terms of time needed for migration there won't be a difference. Is supporting that .suspend really so problematic?
Well, we are going to handle save/restore and migration failure by continuing execution of the original domain. In this case xenbus_resume() will not be executed, so tpmfront will (I think) hang.
I suppose we could keep suspend() and also introduce a suspend_cancelled() hook...
 -- Keir
When you said "xenbus_resume" will not be executed, could I suppose that only
per-PV drivers' resume handler won't be invoked, while instead xb_init_comms and
xs_resume are still invoked just after resuming point? In any case, we still need
rebuild xenbus channel first, and then to let PV drivers detecting re-connect, am I
right?
Thanks,
Kevin
Sent: 2006年11月6日 2:00
> bit cheesy as far as I can see, so something more integrated in the
> tpmfront/back protocol would be nice.
In terms of time needed for migration there won't be a difference. Is supporting that .suspend really so problematic?
Well, we are going to handle save/restore and migration failure by continuing execution of the original domain. In this case xenbus_resume() will not be executed, so tpmfront will (I think) hang.
I suppose we could keep suspend() and also introduce a suspend_cancelled() hook...
 -- Keir
When you said "xenbus_resume" will not be executed, could I suppose that only
per-PV drivers' resume handler won't be invoked, while instead xb_init_comms and
xs_resume are still invoked just after resuming point? In any case, we still need
rebuild xenbus channel first, and then to let PV drivers detecting re-connect, am I
right?
Thanks,
Kevin