From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linda Subject: Re: grant tables and driver handshaking Date: Thu, 11 Jun 2015 11:11:37 -0600 Message-ID: <5579C149.5080401@jma3.com> References: <1429117327-6845-1-git-send-email-lindaj@jma3.com> <556F1C21.2010000@jma3.com> <5578E82B.1010601@jma3.com> <20150611104349.GI14606@zion.uk.xensource.com> <55797FC8.8050806@jma3.com> <20150611162451.GK14606@zion.uk.xensource.com> <1434040684.30003.179.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Z361B-0003yl-Bf for xen-devel@lists.xenproject.org; Thu, 11 Jun 2015 17:11:53 +0000 In-Reply-To: <1434040684.30003.179.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , Wei Liu Cc: julien.grall@citrix.com, xen-devel@lists.xenproject.org, lars.kurth.xen@gmail.com List-Id: xen-devel@lists.xenproject.org On 6/11/2015 10:38 AM, Ian Campbell wrote: > On Thu, 2015-06-11 at 17:24 +0100, Wei Liu wrote: >>> Since the backend is in DOM0, and is around longer than the DOMUs, this >>> happens first. It's that interaction that I'd like a little more text on. >>> If it exists. >> I'm not completely sure what you're referring to. That probably only >> exists in code. The interaction between backend and frontend is very >> driver specific. > Most front and backend pairs follow a similar pattern though, and it is > best not to reinvent the wheel completely, even if some of the details > differ. > > In general everything is driven from a pair of "state" nodes in > xenstore, one in the frontend dir and one in the backend dir. > > These contain the enum xenbus_state from xen/include/public/io/xenbus.h > (as %d formatted integers). In general both front and backend start in > state 1 (XenbusStateInitialising) and each has a watch on the other end. > Things generally start with the backend moving to state 2 > (XenbusStateInitWait) and from there they progress n lockstep through > the stages until they both reach state 4 (XenbusStateConnected), then > you are up and running. > > On teardown one end goes to 5 (XenbusStateClosing) and the other > follows. Thanks, Ian. This helped a lot. And thanks for the links, below. Linda > In Linux the place to look is the various "otherend_changed" hooks in > the front and back drivers, usually the backend half is in a xenbus.c > file (e.g. netback and blkback). > > blkif.h has a description of the states in that case. > http://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,io,blkif.h.html > > I'm not aware of any particular docs on the general case, or at least I > can't find the ones I thought we had. > > Ian > >