Xenbus and xenstore

Xenbus and xenstore

Xenstore is a database-like file system that contains information shared between domains. domain configuration and status information. xenstore provides a simple method for discovering device information. as a database in/var/lib/xenstore/TDB, the daemon in the user space is called "xenstored ". the logical file tree has three main paths:

/Vm-/Vm/UUID stores configuration information, such as the number of virtual CPUs and the number of memory allocations.

/Local/domain-contains information about the running domain, which is identified by domid.

/Tool-stores various tool information.

The application writes information to the key of the database and configures the driver. The driver sets watch on the key and responds to the change.

For more information, see: http://wiki.xensource.com/xenwiki/XenStoreReference

Access xenstore

When guest kernel is started, xenstore is accessed through the start_info page and used as the machine page frame number and event channel of the shared page. the dom0 tool uses UNIX domain socket/var/run/xenstored/socket or/var/run/xenstoed/socket_ro. The dom0 tool uses the proce interface/proc/xen/xenbus, the kernel code uses the xenbus API.

Command

Xenstore-read, xenstore-exists, xenstore-list, xenstor-, and ipvs are used to communicate with the xenstored daemon database.

E.g.-# xenstore-list/local/domain/0

Domain ID

1) the universal unique identifier (UUID) is the number that identifies the domain, even if the guest migration remains the same.

2) The domain identifier (domid) identifies a running instance. After the guest is migrated to another machine, the domid changes.

What is xenbus?

Xenbus is an interface of xenstore. It is also a device-driven connection protocol written on xenstore. xenbus is the MGMT bus of a virtual device. the xen PV "backend" device appears on xenbus and can be accessed by the domu PV "fronted" device driver. the status of these virtual backend devices is managed by xenbus. these statuses are stored in xenstore and monitored by dom0 and domu xenbus drivers. xenstore refers to how a domain associates a front-end device with the services provided by the backend (this part is actually carried by xenbus, a Protocol built on the top layer of xenstore ). the backend communicates with the frontend using the shared event channel and ring buffer. all standard xen virtual device drivers register themselves with xenbus during initialization. this is to pass the xenbus_driver struct to the xenbus_register_devide () function.

Xenbus provides a bus when action 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.

All devices must be registered first to use xenbus. Xenbus_register_driver_common replaces the previous xenbus_register_driver function. _ Xenbus_register_frontend ,__ xenbus_register_backend calls xenbus_register_driver_common to register frontend and backend devices respectively. (I think xenbus is more and more like sysfs implementation in xen)

Xenbus limits the unified Drive Structure xenbus_driver for these devices. Pay attention to the xenbus_device, xenbus_driver, and xen_bus_type structures in xenbus. h. The Linux driver structure is encapsulated internally: device, device_driver, and bus_type. Another xenbus_watch related to xenstore is used to watch the node value changes in xenstore and call the callback function in xenbus_watch.

Xenbus_register_driver_common calls the driver_register function, and then calls the bus_add_driver of the Linux kernel to register the driver of the device to the bus. In dom0 pvops, you can see the bus information of/sys/bus/xen-backend. All the backend Vif and vbd devices are registered on the backend bus. Correspondingly, the bus information of/sys/bus/xen can be seen in the guest Vm, which is registered by the Front-End bus. Pvdriver calls _ xenbus_register_frontend to register the front-end driver.

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 login action 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 shocould 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 shoshould be entered by the back end while it is waiting for information before completing initialization. the source of the information can be hot-plug configurations 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.

· Xenbusstateinitialised shoshould 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 stored ed from the front. when this state is entered, the front end shoshould 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 mechanic. 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.