This commit was manufactured by cvs2svn to create branch 'vserver'.
[linux-2.6.git] / drivers / xen / Kconfig
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
new file mode 100644 (file)
index 0000000..da25eee
--- /dev/null
@@ -0,0 +1,260 @@
+#
+# This Kconfig describe xen options
+#
+
+mainmenu "Xen Configuration"
+
+config XEN
+       bool
+       default y if X86_XEN || X86_64_XEN
+       help
+         This is the Linux Xen port.
+
+if XEN
+config XEN_INTERFACE_VERSION
+       hex
+       default 0x00030202
+
+menu "XEN"
+
+config XEN_PRIVILEGED_GUEST
+       bool "Privileged Guest (domain 0)"
+       depends XEN
+       default n
+       help
+         Support for privileged operation (domain 0)
+
+config XEN_UNPRIVILEGED_GUEST
+       bool
+       default !XEN_PRIVILEGED_GUEST
+
+config XEN_PRIVCMD
+       bool
+       depends on PROC_FS
+       default y
+
+config XEN_XENBUS_DEV
+       bool
+       depends on PROC_FS
+       default y
+
+config XEN_BACKEND
+        tristate "Backend driver support"
+        default y
+        help
+          Support for backend device drivers that provide I/O services
+          to other virtual machines.
+
+config XEN_BLKDEV_BACKEND
+       tristate "Block-device backend driver"
+        depends on XEN_BACKEND
+       default y
+       help
+         The block-device backend driver allows the kernel to export its
+         block devices to other guests via a high-performance shared-memory
+         interface.
+
+config XEN_BLKDEV_TAP
+       tristate "Block-device tap backend driver"
+       depends on XEN_BACKEND
+       default XEN_PRIVILEGED_GUEST
+       help
+         The block tap driver is an alternative to the block back driver 
+          and allows VM block requests to be redirected to userspace through
+          a device interface.  The tap allows user-space development of 
+          high-performance block backends, where disk images may be implemented
+          as files, in memory, or on other hosts across the network.  This 
+         driver can safely coexist with the existing blockback driver.
+
+config XEN_NETDEV_BACKEND
+       tristate "Network-device backend driver"
+        depends on XEN_BACKEND && NET
+       default y
+       help
+         The network-device backend driver allows the kernel to export its
+         network devices to other guests via a high-performance shared-memory
+         interface.
+
+config XEN_NETDEV_PIPELINED_TRANSMITTER
+       bool "Pipelined transmitter (DANGEROUS)"
+       depends on XEN_NETDEV_BACKEND
+       default n
+       help
+         If the net backend is a dumb domain, such as a transparent Ethernet
+         bridge with no local IP interface, it is safe to say Y here to get
+         slightly lower network overhead.
+         If the backend has a local IP interface; or may be doing smart things
+         like reassembling packets to perform firewall filtering; or if you
+         are unsure; or if you experience network hangs when this option is
+         enabled; then you must say N here.
+
+config XEN_NETDEV_LOOPBACK
+       tristate "Network-device loopback driver"
+       depends on XEN_NETDEV_BACKEND
+       default y
+       help
+         A two-interface loopback device to emulate a local netfront-netback
+         connection.
+
+config XEN_PCIDEV_BACKEND
+       tristate "PCI-device backend driver"
+       depends on PCI && XEN_BACKEND
+       default XEN_PRIVILEGED_GUEST
+       help
+         The PCI device backend driver allows the kernel to export arbitrary
+         PCI devices to other guests. If you select this to be a module, you
+         will need to make sure no other driver has bound to the device(s)
+         you want to make visible to other guests.
+
+choice
+       prompt "PCI Backend Mode"
+       depends on XEN_PCIDEV_BACKEND
+       default XEN_PCIDEV_BACKEND_VPCI
+
+config XEN_PCIDEV_BACKEND_VPCI
+       bool "Virtual PCI"
+       ---help---
+         This PCI Backend hides the true PCI topology and makes the frontend
+         think there is a single PCI bus with only the exported devices on it.
+         For example, a device at 03:05.0 will be re-assigned to 00:00.0. A
+         second device at 02:1a.1 will be re-assigned to 00:01.1.
+
+config XEN_PCIDEV_BACKEND_PASS
+       bool "Passthrough"
+       ---help---
+         This PCI Backend provides a real view of the PCI topology to the
+         frontend (for example, a device at 06:01.b will still appear at
+         06:01.b to the frontend). This is similar to how Xen 2.0.x exposed
+         PCI devices to its driver domains. This may be required for drivers
+         which depend on finding their hardward in certain bus/slot
+         locations.
+
+config XEN_PCIDEV_BACKEND_SLOT
+       bool "Slot"
+       ---help---
+         This PCI Backend hides the true PCI topology and makes the frontend
+         think there is a single PCI bus with only the exported devices on it.
+         Contrary to the virtual PCI backend, a function becomes a new slot.
+         For example, a device at 03:05.2 will be re-assigned to 00:00.0. A
+         second device at 02:1a.1 will be re-assigned to 00:01.0.
+
+endchoice
+
+config XEN_PCIDEV_BE_DEBUG
+       bool "PCI Backend Debugging"
+       depends on XEN_PCIDEV_BACKEND
+       default n
+
+config XEN_TPMDEV_BACKEND
+       tristate "TPM-device backend driver"
+        depends on XEN_BACKEND
+       default n
+       help
+         The TPM-device backend driver
+
+config XEN_BLKDEV_FRONTEND
+       tristate "Block-device frontend driver"
+       depends on XEN
+       default y
+       help
+         The block-device frontend driver allows the kernel to access block
+         devices mounted within another guest OS. Unless you are building a
+         dedicated device-driver domain, or your master control domain
+         (domain 0), then you almost certainly want to say Y here.
+
+config XEN_NETDEV_FRONTEND
+       tristate "Network-device frontend driver"
+       depends on XEN && NET
+       default y
+       help
+         The network-device frontend driver allows the kernel to access
+         network interfaces within another guest OS. Unless you are building a
+         dedicated device-driver domain, or your master control domain
+         (domain 0), then you almost certainly want to say Y here.
+
+config XEN_SCRUB_PAGES
+       bool "Scrub memory before freeing it to Xen"
+       default y
+       help
+         Erase memory contents before freeing it back to Xen's global
+         pool. This ensures that any secrets contained within that
+         memory (e.g., private keys) cannot be found by other guests that
+         may be running on the machine. Most people will want to say Y here.
+         If security is not a concern then you may increase performance by
+         saying N.
+
+config XEN_DISABLE_SERIAL
+       bool "Disable serial port drivers"
+       default y
+       help
+         Disable serial port drivers, allowing the Xen console driver
+         to provide a serial console at ttyS0.
+
+config XEN_SYSFS
+       tristate "Export Xen attributes in sysfs"
+       depends on SYSFS
+       default y
+       help
+         Xen hypervisor attributes will show up under /sys/hypervisor/.
+
+choice
+       prompt "Xen version compatibility"
+       default XEN_COMPAT_030002_AND_LATER
+
+       config XEN_COMPAT_030002_AND_LATER
+               bool "3.0.2 and later"
+
+       config XEN_COMPAT_LATEST_ONLY
+               bool "no compatibility code"
+
+endchoice
+
+config XEN_COMPAT_030002
+       bool
+       default XEN_COMPAT_030002_AND_LATER
+
+endmenu
+
+config HAVE_ARCH_ALLOC_SKB
+       bool
+       default y
+
+config HAVE_ARCH_DEV_ALLOC_SKB
+       bool
+       default y
+
+config HAVE_IRQ_IGNORE_UNHANDLED
+       bool
+       default y
+
+config NO_IDLE_HZ
+       bool
+       default y
+
+config XEN_UTIL
+       bool
+       default y
+
+config XEN_BALLOON
+       bool
+       default y
+
+config XEN_DEVMEM
+       bool
+       default y
+
+config XEN_SKBUFF
+       bool
+       default y
+       depends on NET
+
+config XEN_REBOOT
+       bool
+       default y
+
+config XEN_SMPBOOT
+       bool
+       default y
+       depends on SMP
+
+endif