From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Zhai, Edwin" Subject: Re: Re: Getting rid of xenbus_suspend(): tpmfrontdriver impacted? Date: Mon, 06 Nov 2006 17:38:42 +0800 Message-ID: <454F02A2.7060309@intel.com> References: Reply-To: edwin.zhai@intel.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0910033872==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Mime-version: 1.0 Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: "Tian, Kevin" , xen-devel , Stefan Berger , xen-devel-bounces@lists.xensource.com List-Id: xen-devel@lists.xenproject.org This is a multi-part message in MIME format. --===============0910033872== Content-Type: multipart/alternative; boundary="------------020102000506020705060203" This is a multi-part message in MIME format. --------------020102000506020705060203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Keir Fraser wrote: > > On 6/11/06 08:09, "Tian, Kevin" 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 > > --------------020102000506020705060203 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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

--------------020102000506020705060203-- --===============0910033872== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0910033872==--