xenbus(4) [netbsd man page]

XENBUS(4)						 BSD/xen Kernel Interfaces Manual						 XENBUS(4)

NAME

     xenbus -- Xen bus abstraction for paravirtualized drivers

SYNOPSIS

     xenbus* at hypervisor?

DESCRIPTION

     The xenbus interface offers an abstraction layer used for communications between domains.	xenbus is mainly used by split paravirtualized
     drivers, so backend and frontend devices can exchange configuration information, properties, and statistics.

     xenbus is not used for data transfer (network frames, blocks, PCI commands, ...). This functionality is implemented by each paravirtualized
     driver independently, typically via shared memory pages and an event channel that serves as a virtual interrupt, for signaling.

     The xenbus abstraction offers guests the possibility to read and write information directly from and to XenStore, a centralized database
     accessible to all domains.  For this reason, it also has an event channel associated to it, so that domains can post messages to the XenStore
     facility.

DIAGNOSTICS

     xenbus0: using event channel %d  The event channel associated to the xenbus interface, for communication with the XenStore database.

SEE ALSO

     pciback(4), xbd(4), xbdback(4), xennet(4), xpci(4), xvif(4)

HISTORY

     The xenbus driver first appeared in NetBSD 3.0.

AUTHORS

     The xenbus driver was written by Manuel Bouyer <bouyer@NetBSD.org>.

BSD
								  January 8, 2011							       BSD

XBDBACK(4)						 BSD/xen Kernel Interfaces Manual						XBDBACK(4)

NAME

     xbdback -- Xen backend paravirtualized block device interface

SYNOPSIS

     pseudo-device xbdback

DESCRIPTION

     The xbdback interface forms the backend part of the paravirtualized drivers used by Xen domains to offer a block device interface, similar to
     a hard disk.  xbdback interfaces are backed either by a physical device directly, or an image file mounted through vnd(4).

     All xbdback interfaces follow the ``xbdbackXiY'' naming convention, where 'X' represents the guest domain identifier, and 'Y' an arbitrary
     identifier.  This identifier is usually associated to the device node as seen by the guest using major(3) and minor(3) numbers.  For example,
     identifier ``769'' (0x301) means major 3 and minor 1, identified as ``hda1'' under Linux convention.  For NetBSD, the guest device name spec-
     ified in the guest configuration file does not matter, and can be chosen arbitrarily.

     A xbdback interface will appear as a xbd(4) block device inside a NetBSD guest domain.  In the XenStore, xbd and xbdback are identified by
     ``vbd'' (virtual block device) entries.

DIAGNOSTICS

     xbd backend: attach device %s (size %d) for domain %d  Gives the device used as xbdback interface for the given guest domain, and its size,
     in bytes.

     xbd backend 0x%x for domain %d using event channel %d, protocol %s  Gives the backend identifier, guest domain ID, event channel ID, and pro-
     tocol used for block level communication.

     xbdback %s: can't VOP_OPEN device 0x%x: %d  When this message appears in the system message buffer with error 16 (EBUSY), the device is
     likely to be already mounted.  It must be unmounted first, as the system will refuse to open it a second time.

SEE ALSO

     vnd(4), xbd(4), xenbus(4)

HISTORY

     The xbdback driver first appeared in NetBSD 4.0.

AUTHORS

     The xbdback driver was written by Manuel Bouyer <bouyer@NetBSD.org>.

BSD
								   June 7, 2011 							       BSD