XenBus and XenStore
XenStore是一个类似于数据库的文件系统, 包含了domain间的共享信息. 有domain配置和状态信息.XenStore 提供了一种发现设备信息的简便方法. 它作为数据库在/var/lib/xenstore/tdb, 在用户空间的 daemon 称为 "xenstored".这个逻辑文件树有三个主要的路径:
/vm – /vm/uuid 存储配置信息,例如虚拟CPU数和内存分配数.
/local/domain – 包含了正在运行的domain信息, 由domid标识.
/tool – 存储多种工具信息.
应用程序向这个数据库的 key 写信息, 配置驱动; 驱动在key上设置watch并对改变做出回应.
详细介绍请参考: http://wiki.xensource.com/xenwiki/XenStoreReference
访问xenstore
在guest kernel启动时xenstore经过start_info页而被访问到, 作为共享页的机器页帧号和event channel使用.Dom0工具使用UNIX domain socket /var/run/xenstored/socket 或 /var/run/xenstoed/socket_ro; Dom0工具使用proce接口/proc/xen/xenbus, 内核代码使用xenbus API.
命令
xenstore-read, xenstore-exists, xenstore-list, xenstor-, xsls, 用于和xenstored daemon数据库通信.
e.g. – #xenstore-list /local/domain/0
Domain 标识
1) 通用唯一标识符(UUID)是标识domain的数字, 即使guest迁移也保持相同.
2) domain 标识(DOMID) 标识一个正在运行的实例, 当guest 迁移到另一台机器后DOMID改变.
什么是Xenbus
Xenbus是Xenstore的一个接口, 它也是在Xenstore之上写的设备驱动的连接协议. Xenbus是一个虚拟设备的mgmt bus. Xen PV "backend" 设备出现在xenbus上, 而且能被DomU使用PV "fronted"设备驱动访问到. 这些虚拟后端设备的状态由xenbus管理. 这些状态被存储到xenstore, 并且一直被Dom0和DomU的xenbus驱动程序监测.XenStore 指供了一个domain如何将前端设备与后端提供的服务联系起来的方法, (实际这部分是由XenBus承载的, 一种建立在XenStore顶层的协议). 后端与前端通信使用共享event channel 和 ring buffer通信. 所有规范的xen虚拟设备驱动在初始化时向XenBus注册自己. 这是通过传递xenbus_driver 结构体给xenbus_register_devide()函数.
XenBus provides a bus abstraction for paravirtualized drivers to communicate between domains. In practice, the bus is used for configuration negotiation, leaving most data transfer to be done via an interdomain channel composed of a shared page and an event channel.
/proc/xen/xenbus
Xenstore is a centralized configuration database that is accessible by all domains. Management tools configure and control virtual devices by writing values into the database that trigger events in drivers.
所有的设备，如果要使用xenbus，必须首先注册。xenbus_register_driver_common替代了之前的xenbus_register_driver函数。__xenbus_register_frontend，__xenbus_register_backend都调用xenbus_register_driver_common来分别注册前端和后端设备。（我越来越觉得xenbus就像个xen里的sysfs实现）
xenbus对这些设备限制了统一的驱动结构 xenbus_driver，注意xenbus.h里的几个结构体 xenbus_device, xenbus_driver, xen_bus_type。都是内部封装了linux驱动的结构：device, device_driver, bus_type。还有一个与xenstore有关系的xenbus_watch用来watch xenstore里面node值的变化后调用xenbus_watch内的callback函数。
xenbus_register_driver_common会调用driver_register函数，接着调用linux内核的bus_add_driver把设备的驱动注册到总线上。在dom0 pvops里，可以看到/sys/bus/xen-backend的总线信息，该后端总线上注册了所有的后端vif, vbd的设备。相应的，guest vm里，可以看到/sys/bus/xen的总线信息，这个是前端总线注册上去的。pvdriver会调用__xenbus_register_frontend来注册前端驱动。
The XenBus, in the context of device drivers, is an informal protocol built on top of the XenStore, which provides a way of enumerating the (virtual) devicesavailable to a given domain, andconnecting to them. Implementing theXenBus interface is not required when porting a kernel to Xen. It is predominantly used in Linux to isolate the Xen-specific code behind a relatively abstract interface.
The XenBus interface is intended to roughly mirror that of a device bus such as PCI. It is defined inlinux-2.6-xen-sparse/include/xen/xenbus.h2. Each virtual device has three major components:
· A shared memory page containing the ring buffers
· An event channel signaling activity in the ring
· A XenStore entry containing configuration information
These components are tied together in the bus interface by the structure shown in Listing 6.1. This device structure is passed as an argument to a number of other functions, which (between them) implement the driver for the device.
Listing 6.1. The structure defining a XenBus device
[from: linux-2.6-xensparse/include/xen/xenbus.h]
71 struct xenbus_device {
72 const char *devicetype;
73 const char *nodename;
74 const char *otherend;
75 int otherend_id;
76 struct xenbus_watch otherend_watch;
77 struct device dev;
78 enum xenbus_state state;
79 struct completion down;
80 };
The exact definition of this structure is tied quite closely to Linux; the device struct, for example, represents a Linux device. It can, however, be used as a good starting point for building a similar abstraction layer for other systems.
The core component of the XenBus interface, indeed the only part that needs to be implemented by all systems wanting to use the paravirtualized devices available to Xen guests, is the xenbus_stateenumerated type. Each device has such a type associated with it.
The XenBus state, unlike the rest of the XenBus interface, is defined by Xen, in the io/xenbus.hpublic header. This is used while negotiating a connection between the two halves of the device driver. There are seven states defined. In normal operation, the state should be gradually incremented as the device is initialized, connected, and then disconnected. The possible states are:
· XenbusStateUnknown represents the initial state of the device on the bus, before either end has been connected.
· XenbusStateInitialising is the state while the back end is in process of initializing itself.
· XenbusStateInitWait should be entered by the back end while it is waiting for information before completing initialization. The source of the information can be hot-plug notifications within the Domain 0 kernel, or further information from the connecting guest. The meaning of this state is that the driver itself is initialized, but needs more information before it can be connected to.
· XenbusStateInitialised should be set to indicate that the back end is now ready for connection. After the bus is in this state, the front end may proceed to connect.
· XenbusStateConnected is the normal state of the bus. For most of the duration of a guest’s run, the bus will be in this state indicating that the front and back ends are communicating normally.
· XenbusStateClosing is set to indicate that the device has become unavailable. The front and back halves of the driver are still connected at this point, but the back end is no longer doing anything sensible with the commands received from the front. When this state is entered, the front end should begin a graceful shutdown.
· XenbusStateClosed is the final state, once the two halves of the driver have disconnected from each other.
Not all drivers make use of the XenBus mechanism. The two notable exceptions are the console and XenStore. Both of these are mapped directly from the start info page, and have no information in the XenStore. In the case of the console, this is so that a guest kernel can start outputting debugging information to the console as soon as possible. In the case of the XenStore, it is obvious that the device can’t use XenBus, because XenBus is built on top of the XenStore, and the XenStore cannot be used to get information required to map itself.