Xen devel - Nov 2006 - RE: Re: Getting rid of xenbus_suspend(): tpmfrontdriver impacted?

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

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

> 	> 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?
Can't you implement the 'exactly-once' semantics you want using some
higher-level protocol?

The suspend hook clearly can't be called in the case of restarting a driver
domain. Maybe you don't ever want to do this with tpm, but we do with all
the other backends.

Ian

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

On 6/11/06 08:09, "Tian, Kevin" <kevin.tian@intel.com> wrote:
> 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?
No, there would still be a connection through to the xenstored. I guess we
do take a few mutexes and so on, so we would need a bit of undo code. So
xenbus_suspend_cancel() is probably the way to go. But full re-connection is
not required.

 -- Keir



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

Keir Fraser wrote:
>
> On 6/11/06 08:09, "Tian, Kevin" <kevin.tian@intel.com>
wrote:
>
>   
>> 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?
>>     
>
> No, there would still be a connection through to the xenstored. I guess we
> do take a few mutexes and so on, so we would need a bit of undo code. So
> xenbus_suspend_cancel() is probably the way to go. But full re-connection
is
> not required.
>   
if no full re-connection, how does everything across different layer 
work together?

look at PV driver in HVM domain for example.
xen-platform-pci, xenbus and xen-vbd enable pseudo device, 
shared_info/evtchn/xenbus and vbd respectively.  when vbd driver found a 
broken state when restore, it should reconnect the lower layers first, 
since everything is lost.


>  -- Keir
>
>   


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