The Xen Store

The Xen Store
The Xen Store Daemon provides a simple tree-like database to which we can read and write values. The Xen Store code is mainly under tools\xenstore.
It replaces the XCS, which was a daemon handling control messages.
The physical xenstore resides in one file: /var/lib/xenstored/tdb.
Both user space ("tools"in Xen terminology) and kernel code can write to the  XenStore .The kernel code writes to the  XenStore  by using  XenBus .
The python scripts (under tools/python) uses lowlevel/xs.c to read/write to the  XenStore .
The Xen Store Daemon is started in xenstored_core.c. It creates a device file ("/dev/xen/evtchn") in case such a device file does not exists and it opens it. (see : domain_init() ,file tools/xenstore/xenstored_domain.c).
It opens 2 TCP sockets (UNIX sockets). One of these sockets is a Read-Only socket, and it resides under/var/run/xenstored/socket_ro. The second is/var/run/xenstored/socket.
Connections on these sockets are represented by the connection struct.
A connection can be in one of three states:

BLOCKED (blocked by a transaction)        
BUSY    (doing some action)        
OK      (completed it's transaction)

struct connection is declared in xenstore/xenstored_core.h; When a socket is  ReadOnly ,the "can_write"member of it is false.
Then we start an endless loop in which we can get input/output from three sources: the two sockets and the event channel, mentioned above.
Events, which are received in the event channel,are handled by handle_event() method (file xenstored_domain.c).
There are six executables under tools/xenstore, five of which are in fact made from the same module, which is xenstore_client.c, each time built with a different DEFINE passed. (See the Makefile). The sixth tool is built from xsls.c
These executables are : xenstore-exists, xenstore-list, xenstore-read, xenstore-rm, xenstore-write and xsls.
You can use these executable for accessing xenstore. For example: to view the list of fields of domain 0 which has a path "local/domain/0", you run:

xenstore-list /local/domain/0

and a typical result can be the following list:

cpu
memory
name
console
vm
domid
backend

The xsls command is very useful and recursively shows the contents of a specified  XenStore  path. Essentially it does a xenstore-list and then a xenstore-read for each returned field, displaying the fields and their values and then repeating this recursively on each sub-path. For example: to view information about all VIFs backends hosted in domain 0 you may use the following command.

xenstore-ls /local/domain/0/backend/vif

and a typical result may be:

14 = "" 0 = ""  bridge = "xenbr0"  domain = "vm1"  handle = "0"  script = "/etc/xen/scripts/vif-bridge"  state = "4"  frontend = "/local/domain/14/device/vif/0"  mac = "aa:00:00:22:fe:9f"  frontend-id = "14"  hotplug-status = "connected"15 = "" 0 = ""  mac = "aa:00:00:6e:d8:46"  state = "4"  handle = "0"  script = "/etc/xen/scripts/vif-bridge"  frontend-id = "15"  domain = "vm2"  frontend = "/local/domain/15/device/vif/0"  hotplug-status = "connected"

(The xenstored must be running for these six executables to run; If xenstored is not running, then running theses executables will usually hang. The Xend daemon can be stopped).
An instance of struct node is the elementary unit of the  XenStore . (struct node is defined in xenstored_core.h). The actual writing to the  XenStore  is done by write_node() method of xenstored_core.c.
xen_start_info structure has a member named :store_evtchn. (declared in public/xen.h as u16). This is the event channel for store communication.