[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] grant tables and driver handshaking



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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.