#
# For a description of the syntax of this configuration file,
# see Documentation/kbuild/kconfig-language.txt.
#

mainmenu "Linux Kernel Configuration"

config XEN
	bool
	default y
	help
	  This is the Linux Xen port.

config ARCH_XEN
	bool
	default y


config NO_IDLE_HZ
	bool
	default y


menu "XEN"

config XEN_PRIVILEGED_GUEST
	bool "Privileged Guest (domain 0)"
	default n
	select XEN_PHYSDEV_ACCESS
	help
	  Support for privileged operation (domain 0)

config XEN_PHYSDEV_ACCESS
	bool "Physical device access"
	default XEN_PRIVILEGED_GUEST
	help
	  Assume access is available to physical hardware devices
	  (e.g., hard drives, network cards). This allows you to configure
	  such devices and also includes some low-level support that is
	  otherwise not compiled into the kernel.

config XEN_BLKDEV_BACKEND
	bool "Block-device backend driver"
	depends on XEN_PHYSDEV_ACCESS
	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_BE
        bool "Block Tap support for backend driver (DANGEROUS)"
        depends on XEN_BLKDEV_BACKEND
        default n
        help
          If you intend to use the block tap driver, the backend domain will
          not know the domain id of the real frontend, and so will not be able
          to map its data pages.  This modifies the backend to attempt to map
          from both the tap domain and the real frontend.  This presents a
          security risk, and so should ONLY be used for development
          with the blktap.  This option will be removed as the block drivers are
          modified to use grant tables.

config XEN_BLKDEV_GRANT
        bool "Grant table substrate for block drivers"
        depends on !XEN_BLKDEV_TAP_BE
        default y
        help
          This introduces the use of grant tables as a data exhange mechanism
          between the frontend and backend block drivers. This currently
          conflicts with the block tap.

config XEN_NETDEV_BACKEND
	bool "Network-device backend driver"
	depends on XEN_PHYSDEV_ACCESS
	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_BLKDEV_FRONTEND
	bool "Block-device frontend driver"
	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
	bool "Network-device frontend driver"
	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_NETDEV_FRONTEND_PIPELINED_TRANSMITTER
	bool "Pipelined transmitter (DANGEROUS)"
	depends on XEN_NETDEV_FRONTEND
	default n
	help
	  The driver will assume that the backend is pipelining packets for
	  transmission: whenever packets are pending in the remote backend,
	  the driver will not send asynchronous notifications when it queues
	  additional packets for transmission.
	  If the 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_BLKDEV_TAP
	bool "Block device tap driver"
	default n
	help
	  This driver allows a VM to interact on block device channels
	  to other VMs.  Block messages may be passed through or redirected
	  to a character device, allowing device prototyping in application
	  space.  Odds are that you want to say N here.

config XEN_SHADOW_MODE
	bool "Fake shadow mode"
	default n
    help
      fakes out a shadow mode kernel


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.

choice
	prompt "Processor Type"
	default XEN_X86

config XEN_X86
	bool "X86"
	help
	  Choose this option if your computer is a X86 architecture.

config XEN_X86_64
	bool "X86_64"
	help
	  Choose this option if your computer is a X86_64 architecture.

endchoice

endmenu

config HAVE_ARCH_DEV_ALLOC_SKB
	bool
	default y

source "init/Kconfig"

if XEN_X86
source "arch/xen/i386/Kconfig"
endif

if XEN_X86_64
source "arch/xen/x86_64/Kconfig"
endif

menu "Executable file formats"

source "fs/Kconfig.binfmt"

endmenu

source "arch/xen/Kconfig.drivers"

source "fs/Kconfig"

source "arch/i386/Kconfig.debug"

source "security/Kconfig"

source "crypto/Kconfig"

source "lib/Kconfig"