Mailing List Archive

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
Re: Re: Getting rid of xenbus_suspend(): tpmfrontdriver impacted? [ In reply to ]
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
RE: Re: Getting rid of xenbus_suspend(): tpmfrontdriver impacted? [ In reply to ]
>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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: Re: Getting rid of xenbus_suspend(): tpmfrontdriver impacted? [ In reply to ]
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



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
RE: Re: Getting rid of xenbus_suspend(): tpmfrontdriver impacted? [ In reply to ]
>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

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