xbdback(4) [netbsd man page]

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

XNB(4)							   BSD Kernel Interfaces Manual 						    XNB(4)

NAME

     xnb -- Xen Paravirtualized Backend Ethernet Driver

SYNOPSIS

     To compile this driver into the kernel, place the following lines in your kernel configuration file:

	   options XENHVM
	   device xenpci

DESCRIPTION

     The xnb driver provides the back half of a paravirtualized xen(4) network connection.  The netback and netfront drivers appear to their
     respective operating systems as Ethernet devices linked by a crossover cable.  Typically, xnb will run on Domain 0 and the netfront driver
     will run on a guest domain.  However, it is also possible to run xnb on a guest domain.  It may be bridged or routed to provide the net-
     front's domain access to other guest domains or to a physical network.

     In most respects, the xnb device appears to the OS as an other Ethernet device.  It can be configured at runtime entirely with ifconfig(8).
     In particular, it supports MAC changing, arbitrary MTU sizes, checksum offload for IP, UDP, and TCP for both receive and transmit, and TSO.
     However, see CAVEATS before enabling txcsum, rxcsum, or tso.

SYSCTL VARIABLES

     The following read-only variables are available via sysctl(8):

     dev.xnb.%d.dump_rings
	     Displays information about the ring buffers used to pass requests between the netfront and netback.  Mostly useful for debugging, but
	     can also be used to get traffic statistics.

     dev.xnb.%d.unit_test_results
	     Runs a builtin suite of unit tests and displays the results.  Does not affect the operation of the driver in any way.  Note that the
	     test suite simulates error conditions; this will result in error messages being printed to the system log.

SEE ALSO

     arp(4), netintro(4), ng_ether(4), xen(4), ifconfig(8)

HISTORY

     The xnb device driver first appeared in FreeBSD 10.0.

AUTHORS

     The xnb driver was written by Alan Somers <alans@spectralogic.com> and John Suykerbuyk <johns@spectralogic.com>.

CAVEATS

     Packets sent through Xennet pass over shared memory, so the protocol includes no form of link-layer checksum or CRC.  Furthermore, Xennet
     drivers always report to their hosts that they support receive and transmit checksum offloading.  They "offload" the checksum calculation by
     simply skipping it.  That works fine for packets that are exchanged between two domains on the same machine.  However, when a Xennet inter-
     face is bridged to a physical interface, a correct checksum must be attached to any packets bound for that physical interface.  Currently,
     FreeBSD lacks any mechanism for an Ethernet device to inform the OS that newly received packets are valid even though their checksums are
     not.  So if the netfront driver is configured to offload checksum calculations, it will pass non-checksumed packets to xnb, which must then
     calculate the checksum in software before passing the packet to the OS.

     For this reason, it is recommended that if xnb is bridged to a physical interface, then transmit checksum offloading should be disabled on
     the netfront.  The Xennet protocol does not have any mechanism for the netback to request the netfront to do this; the operator must do it
     manually.

BUGS

     The xnb driver does not properly checksum UDP datagrams that span more than one Ethernet frame.  Nor does it correctly checksum IPv6 packets.
     To workaround that bug, disable transmit checksum offloading on the netfront driver.

BSD
								   June 6, 2014 							       BSD