From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: grant tables and driver handshaking Date: Thu, 11 Jun 2015 17:38:04 +0100 Message-ID: <1434040684.30003.179.camel@citrix.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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Z35Um-0000j7-4q for xen-devel@lists.xenproject.org; Thu, 11 Jun 2015 16:38:24 +0000 In-Reply-To: <20150611162451.GK14606@zion.uk.xensource.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: Wei Liu Cc: julien.grall@citrix.com, xen-devel@lists.xenproject.org, lars.kurth.xen@gmail.com, Linda List-Id: xen-devel@lists.xenproject.org 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. 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