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

XEN(4)							   BSD Kernel Interfaces Manual 						    XEN(4)

NAME

     xen -- Xen Hypervisor Guest (DomU) Support

SYNOPSIS

     To compile para-virtualized (PV) Xen guest support into an i386 kernel, place the following lines in your kernel configuration file:

	   options PAE
	   options XEN
	   nooptions NATIVE

     To compile hardware-assisted virtualization (HVM) Xen guest support with para-virtualized drivers into an amd64 kernel, place the following
     lines in your kernel configuration file:

	   options XENHVM
	   device xenpci

DESCRIPTION

     The Xen Hypervisor allows multiple virtual machines to be run on a single computer system.  When first released, Xen required that i386 ker-
     nels be compiled "para-virtualized" as the x86 instruction set was not fully virtualizable.  Primarily, para-virtualization modifies the vir-
     tual memory system to use hypervisor calls (hypercalls) rather than direct hardware instructions to modify the TLB, although para-virtualized
     device drivers were also required to access resources such as virtual network interfaces and disk devices.

     With later instruction set extensions from AMD and Intel to support fully virtualizable instructions, unmodified virtual memory systems can
     also be supported; this is referred to as hardware-assisted virtualization (HVM).	HVM configurations may either rely on transparently emu-
     lated hardware peripherals, or para-virtualized drivers, which are aware of virtualization, and hence able to optimize certain behaviors to
     improve performance or semantics.

     FreeBSD supports a fully para-virtualized (PV) kernel on the i386 architecture using options XEN and nooptions NATIVE; currently, this
     requires use of a PAE kernel, enabled via options PAE.

     FreeBSD supports hardware-assisted virtualization (HVM) on both the i386 and amd64 kernels; however, PV device drivers with an HVM kernel are
     only supported on the amd64 architecture, and require options XENHVM and device xenpci.

     Para-virtualized device drivers are required in order to support certain functionality, such as processing management requests, returning
     idle physical memory pages to the hypervisor, etc.

   Xen DomU device drivers
     Xen para-virtualized drivers are automatically added to the kernel if a PV kernel is compiled using options XEN; for HVM environments,
     options XENHVM and device xenpci are required.  The follow drivers are supported:

	   balloon   Allow physical memory pages to be returned to the hypervisor as a result of manual tuning or automatic policy.

	   blkback   Exports local block devices or files to other Xen domains where they can then be imported via blkfront.

	   blkfront  Import block devices from other Xen domains as local block devices, to be used for file systems, swap, etc.

	   console   Export the low-level system console via the Xen console service.

	   control   Process management operations from Domain 0, including power off, reboot, suspend, crash, and halt requests.

	   evtchn    Expose Xen events via the /dev/xen/evtchn special device.

	   netback   Export local network interfaces to other Xen domains where they can be imported via netfront.

	   netfront  Import network interfaces from other Xen domains as local network interfaces, which may be used for IPv4, IPv6, etc.

	   pcifront  Allow physical PCI devices to be passed through into a PV domain.

	   xenpci    Represents the Xen PCI device, an emulated PCI device that is exposed to HVM domains.  This device allows detection of the
		     Xen hypervisor, and provides interrupt and shared memory services required to interact with the hypervisor.

   Performance considerations
     In general, PV drivers will perform better than emulated hardware, and are the recommended configuration for HVM installations.

     Using a hypervisor introduces a second layer of scheduling that may limit the effectiveness of certain FreeBSD scheduling optimisations.
     Among these is adaptive locking, which is no longer able to determine whether a thread holding a lock is in execution.  It is recommended
     that adaptive locking be disabled when using Xen:

	   options NO_ADAPTIVE_MUTEXES
	   options NO_ADAPTIVE_RWLOCKS
	   options NO_ADAPTIVE_SX

SEE ALSO

     pae(4)

HISTORY

     Support for xen first appeared in FreeBSD 8.1.

AUTHORS

     FreeBSD support for Xen was first added by Kip Macy <kmacy@FreeBSD.org> and Doug Rabson <dfr@FreeBSD.org>.  Further refinements were made by
     Justin Gibbs <gibbs@FreeBSD.org>, Adrian Chadd <adrian@FreeBSD.org>, and Colin Percival <cperciva@FreeBSD.org>.  This manual page was written
     by Robert Watson <rwatson@FreeBSD.org>.

BUGS

     FreeBSD is only able to run as a Xen guest (DomU) and not as a Xen host (Dom0).

     A fully para-virtualized (PV) kernel is only supported on i386, and not amd64.

     Para-virtualized drivers under hardware-assisted virtualization (HVM) kernel are only supported on amd64, not i386.

     As of this release, Xen PV DomU support is not heavily tested; instability has been reported during VM migration of PV kernels.

     Certain PV driver features, such as the balloon driver, are under-exercised.

BSD
								 December 17, 2010							       BSD