Re: grant tables and driver handshaking

[Linda <lindaj@jma3.com>]

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
>
>