RE: Re: Getting rid of xenbus_suspend(): tpmfrontdriver impacted?

RE: Re: Getting rid of xenbus_suspend(): tpmfrontdriver impacted?

[Tian, Kevin]

[-- Attachment #1: Type: text/plain, Size: 949 bytes --]

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

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

RE: Re: Getting rid of xenbus_suspend(): tpmfrontdriverimpacted?

[Ian Pratt]

[-- Attachment #1: Type: text/plain, Size: 522 bytes --]

> 	> 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

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Re: Getting rid of xenbus_suspend(): tpmfrontdriver impacted?

[Keir Fraser]

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

Re: Re: Getting rid of xenbus_suspend(): tpmfrontdriver impacted?

[Zhai, Edwin]

[-- Attachment #1.1: Type: text/plain, Size: 1096 bytes --]

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
>
>   


[-- Attachment #1.2: Type: text/html, Size: 1712 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Re: Getting rid of xenbus_suspend(): tpmfrontdriver impacted?

[Keir Fraser]

[-- Attachment #1.1: Type: text/plain, Size: 427 bytes --]




On 6/11/06 09:38, "Zhai, Edwin" <edwin.zhai@intel.com> wrote:

> 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.

If migration fails then devices will not have been disconnected.

 -- Keir


[-- Attachment #1.2: Type: text/html, Size: 923 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

RE: Re: Getting rid of xenbus_suspend(): tpmfrontdriver impacted?

[Tian, Kevin]

>From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk]
>Sent: 2006年11月6日 16:52
>
>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

For the migration case, the connection may still exist to the xenstored. 
However for save/restore case, we destroy the domain once saved, 
right? In that case, the connection is broken and next time you still 
need to re-bind inter-domain xenbus channel (although local event 
port is same) after resume, just like what's done for xenconsole. 
Xenbus_suspend_cancel can save local state resume, but inter-
domain re-connection is inevitable, IMO. :-)

Thanks,
Kevin

Re: Re: Getting rid of xenbus_suspend(): tpmfrontdriver impacted?

[Keir Fraser]

On 6/11/06 13:15, "Tian, Kevin" <kevin.tian@intel.com> wrote:

> For the migration case, the connection may still exist to the xenstored.
> However for save/restore case, we destroy the domain once saved,
> right? In that case, the connection is broken and next time you still
> need to re-bind inter-domain xenbus channel (although local event
> port is same) after resume, just like what's done for xenconsole.
> Xenbus_suspend_cancel can save local state resume, but inter-
> domain re-connection is inevitable, IMO. :-)

Yes, we continue to require full re-connection if the save/restore or
migration is successful and the guest is resumed in a new domain context.
There's no question about that. Our aim here is to allow a save/restore or
migration to fail gracfully by resuming execution in the original domain
context. Currently that is simply not possible, but it's not hard to fix.

 -- Keir

RE: Re: Getting rid of xenbus_suspend(): tpmfrontdriver impacted?

[Tian, Kevin]

>From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk]
>Sent: 2006年11月6日 21:40
>On 6/11/06 13:15, "Tian, Kevin" <kevin.tian@intel.com> wrote:
>
>> For the migration case, the connection may still exist to the xenstored.
>> However for save/restore case, we destroy the domain once saved,
>> right? In that case, the connection is broken and next time you still
>> need to re-bind inter-domain xenbus channel (although local event
>> port is same) after resume, just like what's done for xenconsole.
>> Xenbus_suspend_cancel can save local state resume, but inter-
>> domain re-connection is inevitable, IMO. :-)
>
>Yes, we continue to require full re-connection if the save/restore or
>migration is successful and the guest is resumed in a new domain
>context.
>There's no question about that. Our aim here is to allow a save/restore or
>migration to fail gracfully by resuming execution in the original domain
>context. Currently that is simply not possible, but it's not hard to fix.
>
> -- Keir

I see, and it's a good enhancement. :-)

Thanks,
Kevin