[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |