[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] grant tables and driver handshaking
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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |