drivers/xen/Kconfig

   1 #
   2 # This Kconfig describe xen options
   3 #
   4
   5 config XEN
   6         bool
   7
   8 if XEN
   9 config XEN_INTERFACE_VERSION
  10         hex
  11         default 0x00030207
  12
  13 menu "XEN"
  14
  15 config XEN_PRIVILEGED_GUEST
  16         bool "Privileged Guest (domain 0)"
  17         help
  18           Support for privileged operation (domain 0)
  19
  20 config XEN_UNPRIVILEGED_GUEST
  21         def_bool y
  22         depends on !XEN_PRIVILEGED_GUEST
  23         select PM
  24         select SUSPEND
  25
  26 config XEN_DOMCTL
  27         tristate
  28
  29 config XEN_XENBUS_DEV
  30         def_bool y
  31         depends on PROC_FS
  32
  33 config XEN_NETDEV_ACCEL_SFC_UTIL
  34         depends on X86
  35         tristate
  36
  37 config XEN_BACKEND
  38         tristate "Backend driver support"
  39         default XEN_PRIVILEGED_GUEST
  40         help
  41           Support for backend device drivers that provide I/O services
  42           to other virtual machines.
  43
  44 config XEN_BLKDEV_BACKEND
  45         tristate "Block-device backend driver"
  46         depends on BLOCK && XEN_BACKEND
  47         default XEN_BACKEND
  48         select XEN_DOMCTL
  49         help
  50           The block-device backend driver allows the kernel to export its
  51           block devices to other guests via a high-performance shared-memory
  52           interface.
  53
  54 config XEN_BLKDEV_TAP
  55         tristate "Block-device tap backend driver"
  56         depends on BLOCK && XEN_BACKEND
  57         default XEN_BACKEND
  58         select XEN_DOMCTL
  59         help
  60           The block tap driver is an alternative to the block back driver
  61           and allows VM block requests to be redirected to userspace through
  62           a device interface.  The tap allows user-space development of
  63           high-performance block backends, where disk images may be implemented
  64           as files, in memory, or on other hosts across the network.  This
  65           driver can safely coexist with the existing blockback driver.
  66
  67 config XEN_BLKDEV_TAP2
  68         tristate "Block-device tap backend driver 2"
  69         depends on BLOCK && XEN_BACKEND
  70         default XEN_BACKEND
  71         help
  72           The block tap driver is an alternative to the block back driver
  73           and allows VM block requests to be redirected to userspace through
  74           a device interface.  The tap allows user-space development of
  75           high-performance block backends, where disk images may be implemented
  76           as files, in memory, or on other hosts across the network.  This
  77           driver can safely coexist with the existing blockback driver.
  78
  79 choice
  80         prompt "Select blktap2 driver"
  81         depends on XEN_BLKDEV_TAP2=y
  82
  83 config XEN_BLKDEV_TAP2_LEGACY
  84         bool "legacy"
  85
  86 config XEN_BLKDEV_TAP2_NEW
  87         bool "'new'"
  88
  89 endchoice
  90
  91 config XEN_NR_TAP2_DEVICES
  92         int "Number of devices the version 2 tap backend driver can handle"
  93         range 2 1048575
  94         default 1024 if 64BIT
  95         default 256
  96         depends on XEN_BLKDEV_TAP2
  97         help
  98           This sets the number of backend devices the v2 tap backend driver
  99           will be able to handle simultaneously. Note that device 0 is the
 100           control device and hence not available to service guests.
 101
 102 config XEN_BLKBACK_PAGEMAP
 103         tristate
 104         depends on XEN_BLKDEV_BACKEND != n && XEN_BLKDEV_TAP2 != n
 105         default XEN_BLKDEV_BACKEND || XEN_BLKDEV_TAP2
 106
 107 config XEN_NETDEV_BACKEND
 108         tristate "Network-device backend driver"
 109         depends on XEN_BACKEND && NET
 110         default XEN_BACKEND
 111         help
 112           The network-device backend driver allows the kernel to export its
 113           network devices to other guests via a high-performance shared-memory
 114           interface.
 115
 116 config XEN_NETDEV_TX_SHIFT
 117         int "Maximum simultaneous transmit requests (as a power of 2)"
 118         depends on XEN_NETDEV_BACKEND
 119         range 5 15
 120         default 8
 121         help
 122           The maximum number transmits the driver can hold pending, expressed
 123           as the exponent of a power of 2.
 124
 125 config XEN_NETDEV_PIPELINED_TRANSMITTER
 126         bool "Pipelined transmitter (DANGEROUS)"
 127         depends on XEN_NETDEV_BACKEND
 128         help
 129           If the net backend is a dumb domain, such as a transparent Ethernet
 130           bridge with no local IP interface, it is safe to say Y here to get
 131           slightly lower network overhead.
 132           If the backend has a local IP interface; or may be doing smart things
 133           like reassembling packets to perform firewall filtering; or if you
 134           are unsure; or if you experience network hangs when this option is
 135           enabled; then you must say N here.
 136
 137 config XEN_NETDEV_ACCEL_SFC_BACKEND
 138         tristate "Network-device backend driver acceleration for Solarflare NICs"
 139         depends on XEN_NETDEV_BACKEND && SFC && SFC_RESOURCE && X86
 140         select XEN_NETDEV_ACCEL_SFC_UTIL
 141         default m
 142
 143 config XEN_NETDEV_LOOPBACK
 144         tristate "Network-device loopback driver"
 145         depends on XEN_NETDEV_BACKEND
 146         help
 147           A two-interface loopback device to emulate a local netfront-netback
 148           connection. If unsure, it is probably safe to say N here.
 149
 150 config XEN_TPMDEV_BACKEND
 151         tristate "TPM-device backend driver"
 152         depends on XEN_BACKEND
 153         help
 154           The TPM-device backend driver
 155
 156 config XEN_SCSI_BACKEND
 157         tristate "SCSI backend driver"
 158         depends on SCSI && XEN_BACKEND
 159         default m
 160         help
 161           The SCSI backend driver allows the kernel to export its SCSI Devices
 162           to other guests via a high-performance shared-memory interface.
 163
 164 config XEN_USB_BACKEND
 165         tristate "USB backend driver"
 166         depends on USB && XEN_BACKEND
 167         default m
 168         help
 169           The USB backend driver allows the kernel to export its USB Devices
 170           to other guests.
 171
 172 config XEN_BLKDEV_FRONTEND
 173         tristate "Block-device frontend driver"
 174         default y
 175         help
 176           The block-device frontend driver allows the kernel to access block
 177           devices mounted within another guest OS. Unless you are building a
 178           dedicated device-driver domain, or your master control domain
 179           (domain 0), then you almost certainly want to say Y here.
 180
 181 config XEN_NETDEV_FRONTEND
 182         tristate "Network-device frontend driver"
 183         depends on NET
 184         default y
 185         help
 186           The network-device frontend driver allows the kernel to access
 187           network interfaces within another guest OS. Unless you are building a
 188           dedicated device-driver domain, or your master control domain
 189           (domain 0), then you almost certainly want to say Y here.
 190
 191 config XEN_NETDEV_ACCEL_SFC_FRONTEND
 192         tristate "Network-device frontend driver acceleration for Solarflare NICs"
 193         depends on XEN_NETDEV_FRONTEND && X86
 194         select XEN_NETDEV_ACCEL_SFC_UTIL
 195         default m
 196
 197 config XEN_SCSI_FRONTEND
 198         tristate "SCSI frontend driver"
 199         depends on SCSI
 200         default m
 201         help
 202           The SCSI frontend driver allows the kernel to access SCSI Devices
 203           within another guest OS.
 204
 205 config XEN_USB_FRONTEND
 206         tristate "USB frontend driver"
 207         depends on USB
 208         default m
 209         help
 210           The USB frontend driver allows the kernel to access USB Devices
 211           within another guest OS.
 212
 213 config XEN_USB_FRONTEND_HCD_STATS
 214         bool "Taking the HCD statistics (for debug)"
 215         depends on XEN_USB_FRONTEND
 216         default y
 217         help
 218           Count the transferred urb status and the RING_FULL occurrence.
 219
 220 config XEN_USB_FRONTEND_HCD_PM
 221         bool "HCD suspend/resume support (DO NOT USE)"
 222         depends on XEN_USB_FRONTEND
 223         default n
 224         help
 225           Experimental bus suspend/resume feature support.
 226
 227 config XEN_GRANT_DEV
 228         tristate "User-space granted page access driver"
 229         depends on XEN_BACKEND != n
 230         default XEN_PRIVILEGED_GUEST
 231         help
 232           Device for accessing (in user-space) pages that have been granted
 233           by other domains.
 234
 235 config XEN_FRAMEBUFFER
 236         tristate "Framebuffer-device frontend driver"
 237         depends on FB
 238         select FB_CFB_FILLRECT
 239         select FB_CFB_COPYAREA
 240         select FB_CFB_IMAGEBLIT
 241         default y
 242         help
 243           The framebuffer-device frontend drivers allows the kernel to create a
 244           virtual framebuffer.  This framebuffer can be viewed in another
 245           domain.  Unless this domain has access to a real video card, you
 246           probably want to say Y here.
 247
 248 config XEN_KEYBOARD
 249         tristate "Keyboard-device frontend driver"
 250         depends on XEN_FRAMEBUFFER && INPUT
 251         default y
 252         help
 253           The keyboard-device frontend driver allows the kernel to create a
 254           virtual keyboard.  This keyboard can then be driven by another
 255           domain.  If you've said Y to CONFIG_XEN_FRAMEBUFFER, you probably
 256           want to say Y here.
 257
 258 config XEN_DISABLE_SERIAL
 259         bool "Disable serial port drivers"
 260         default y
 261         help
 262           Disable serial port drivers, allowing the Xen console driver
 263           to provide a serial console at ttyS0.
 264
 265 config XEN_NR_GUEST_DEVICES
 266         int "Number of guest devices"
 267         range 0 4032 if 64BIT
 268         range 0 960
 269         default 256 if XEN_BACKEND
 270         default 16
 271         help
 272           Specify the total number of virtual devices (i.e. both frontend
 273           and backend) that you want the kernel to be able to service.
 274
 275 choice
 276         prompt "Xen version compatibility"
 277         default XEN_COMPAT_030002_AND_LATER
 278
 279         config XEN_COMPAT_030002_AND_LATER
 280                 bool "3.0.2 and later"
 281
 282         config XEN_COMPAT_030004_AND_LATER
 283                 bool "3.0.4 and later"
 284
 285         config XEN_COMPAT_030100_AND_LATER
 286                 bool "3.1.0 and later"
 287
 288         config XEN_COMPAT_030200_AND_LATER
 289                 bool "3.2.0 and later"
 290
 291         config XEN_COMPAT_030300_AND_LATER
 292                 bool "3.3.0 and later"
 293
 294         config XEN_COMPAT_030400_AND_LATER
 295                 bool "3.4.0 and later"
 296
 297         config XEN_COMPAT_040000_AND_LATER
 298                 bool "4.0.0 and later"
 299
 300         config XEN_COMPAT_040100_AND_LATER
 301                 bool "4.1.0 and later"
 302
 303         config XEN_COMPAT_LATEST_ONLY
 304                 bool "no compatibility code"
 305
 306 endchoice
 307
 308 config XEN_COMPAT
 309         hex
 310         default 0xffffff if XEN_COMPAT_LATEST_ONLY
 311         default 0x040100 if XEN_COMPAT_040100_AND_LATER
 312         default 0x040000 if XEN_COMPAT_040000_AND_LATER
 313         default 0x030400 if XEN_COMPAT_030400_AND_LATER
 314         default 0x030300 if XEN_COMPAT_030300_AND_LATER
 315         default 0x030200 if XEN_COMPAT_030200_AND_LATER
 316         default 0x030100 if XEN_COMPAT_030100_AND_LATER
 317         default 0x030004 if XEN_COMPAT_030004_AND_LATER
 318         default 0x030002 if XEN_COMPAT_030002_AND_LATER
 319         default 0
 320
 321 config XEN_VCPU_INFO_PLACEMENT
 322         bool "Place shared vCPU info in per-CPU storage"
 323 #       depends on X86 && (XEN_COMPAT >= 0x00030101)
 324         depends on X86
 325         depends on !XEN_COMPAT_030002_AND_LATER
 326         depends on !XEN_COMPAT_030004_AND_LATER
 327         depends on !XEN_COMPAT_030100_AND_LATER
 328         default SMP
 329         ---help---
 330           This allows faster access to the per-vCPU shared info
 331           structure.
 332
 333 endmenu
 334
 335 config HAVE_IRQ_IGNORE_UNHANDLED
 336         def_bool y
 337
 338 config ARCH_HAS_WALK_MEMORY
 339         def_bool y
 340         depends on X86
 341
 342 config XEN_SMPBOOT
 343         def_bool y
 344         depends on SMP && !PPC_XEN
 345
 346 config XEN_SPINLOCK_ACQUIRE_NESTING
 347         int "maximum nesting level for acquiring spin locks"
 348         # Xen versions prior to 3.2.x have a race condition with HYPERVISOR_poll().
 349         depends on !XEN_COMPAT_030002_AND_LATER
 350         depends on !XEN_COMPAT_030004_AND_LATER
 351         depends on !XEN_COMPAT_030100_AND_LATER
 352         range 0 3 if EXPERIMENTAL
 353         range 0 1
 354         default 0
 355         help
 356           IRQ-safe spin lock acquire operations can re-enable interrupts
 357           before entering polling mode, to reduce interrupt latencies.
 358           This option specifies how many times this can be done for each
 359           individual spin lock (0 disables this behavior).
 360
 361 config XEN_DEVMEM
 362         def_bool y
 363
 364 endif
 365
 366 menu "Xen driver support"
 367         depends on XEN || PARAVIRT_XEN
 368
 369 config XEN_BALLOON
 370         bool "Xen memory balloon driver" if PARAVIRT_XEN
 371         depends on PARAVIRT_XEN || !PPC_XEN
 372         default y
 373         help
 374           The balloon driver allows the Xen domain to request more memory from
 375           the system to expand the domain's memory allocation, or alternatively
 376           return unneeded memory to the system.
 377
 378 config XEN_SELFBALLOONING
 379         bool "Dynamically self-balloon kernel memory to target"
 380         depends on XEN_BALLOON && CLEANCACHE && SWAP && XEN_TMEM
 381         help
 382           Self-ballooning dynamically balloons available kernel memory driven
 383           by the current usage of anonymous memory ("committed AS") and
 384           controlled by various sysfs-settable parameters.  Configuring
 385           FRONTSWAP is highly recommended; if it is not configured, self-
 386           ballooning is disabled by default but can be enabled with the
 387           'selfballooning' kernel boot parameter.  If FRONTSWAP is configured,
 388           frontswap-selfshrinking is enabled by default but can be disabled
 389           with the 'noselfshrink' kernel boot parameter; and self-ballooning
 390           is enabled by default but can be disabled with the 'noselfballooning'
 391           kernel boot parameter.  Note that systems without a sufficiently
 392           large swap device should not enable self-ballooning.
 393
 394 config XEN_BALLOON_MEMORY_HOTPLUG
 395         bool "Memory hotplug support for Xen balloon driver"
 396         default n
 397         depends on PARAVIRT_XEN && XEN_BALLOON && MEMORY_HOTPLUG
 398         help
 399           Memory hotplug support for Xen balloon driver allows expanding memory
 400           available for the system above limit declared at system startup.
 401           It is very useful on critical systems which require long
 402           run without rebooting.
 403
 404           Memory could be hotplugged in following steps:
 405
 406             1) dom0: xl mem-max <domU> <maxmem>
 407                where <maxmem> is >= requested memory size,
 408
 409             2) dom0: xl mem-set <domU> <memory>
 410                where <memory> is requested memory size; alternatively memory
 411                could be added by writing proper value to
 412                /sys/devices/system/xen_memory/xen_memory0/target or
 413                /sys/devices/system/xen_memory/xen_memory0/target_kb on dumU,
 414
 415             3) domU: for i in /sys/devices/system/memory/memory*/state; do \
 416                        [ "`cat "$i"`" = offline ] && echo online > "$i"; done
 417
 418           Memory could be onlined automatically on domU by adding following line to udev rules:
 419
 420           SUBSYSTEM=="memory", ACTION=="add", RUN+="/bin/sh -c '[ -f /sys$devpath/state ] && echo online > /sys$devpath/state'"
 421
 422           In that case step 3 should be omitted.
 423
 424 config XEN_SCRUB_PAGES
 425         bool "Scrub memory before freeing it to Xen"
 426         depends on XEN || XEN_BALLOON
 427         default y
 428         help
 429           Erase memory contents before freeing it back to Xen's global
 430           pool. This ensures that any secrets contained within that
 431           memory (e.g., private keys) cannot be found by other guests that
 432           may be running on the machine. Most people will want to say Y here.
 433           If security is not a concern then you may increase performance by
 434           saying N.
 435           If in doubt, say yes.
 436
 437 config XEN_DEV_EVTCHN
 438         tristate "Xen /dev/xen/evtchn device"
 439         default PARAVIRT_XEN || XEN_PRIVILEGED_GUEST || m
 440         help
 441           The evtchn driver allows a userspace process to triger event
 442           channels and to receive notification of an event channel
 443           firing.
 444           If in doubt, say yes.
 445
 446 config PARAVIRT_XEN_BACKEND
 447         bool "Backend driver support"
 448         depends on XEN_DOM0
 449         default y
 450         help
 451           Support for backend device drivers that provide I/O services
 452           to other virtual machines.
 453
 454 config XENFS
 455         tristate "Xen filesystem"
 456         depends on PARAVIRT_XEN
 457         select XEN_PRIVCMD
 458         default y
 459         help
 460           The xen filesystem provides a way for domains to share
 461           information with each other and with the hypervisor.
 462           For example, by reading and writing the "xenbus" file, guests
 463           may pass arbitrary information to the initial domain.
 464           If in doubt, say yes.
 465
 466 config XEN_COMPAT_XENFS
 467        bool "Create compatibility mount point /proc/xen"
 468        depends on XENFS
 469        default y
 470        help
 471          The old xenstore userspace tools expect to find "xenbus"
 472          under /proc/xen, but "xenbus" is now found at the root of the
 473          xenfs filesystem.  Selecting this causes the kernel to create
 474          the compatibility mount point /proc/xen if it is running on
 475          a xen platform.
 476          If in doubt, say yes.
 477
 478 config XEN_SYS_HYPERVISOR
 479        bool "Create xen entries under /sys/hypervisor"
 480        depends on SYSFS
 481        select SYS_HYPERVISOR
 482        default y
 483        help
 484          Create entries under /sys/hypervisor describing the Xen
 485          hypervisor environment.  When running native or in another
 486          virtual environment, /sys/hypervisor will still be present,
 487          but will have no xen contents.
 488
 489 config XEN_XENBUS_FRONTEND
 490         tristate
 491
 492 config XEN_GNTDEV
 493         tristate "userspace grant access device driver"
 494         depends on PARAVIRT_XEN
 495         default m
 496         select MMU_NOTIFIER
 497         help
 498           Allows userspace processes to use grants.
 499
 500 config XEN_GRANT_DEV_ALLOC
 501         tristate "User-space grant reference allocator driver"
 502         depends on PARAVIRT_XEN
 503         default m
 504         help
 505           Allows userspace processes to create pages with access granted
 506           to other domains. This can be used to implement frontend drivers
 507           or as part of an inter-domain shared memory channel.
 508
 509 config SWIOTLB_XEN
 510         def_bool y
 511         depends on PARAVIRT_XEN && PCI
 512         select SWIOTLB
 513
 514 config XEN_XENCOMM
 515         bool
 516
 517 config XEN_TMEM
 518         bool
 519         default y if (CLEANCACHE || FRONTSWAP)
 520         help
 521           Shim to interface in-kernel Transcendent Memory hooks
 522           (e.g. cleancache and frontswap) to Xen tmem hypercalls.
 523
 524 config XEN_PCIDEV_BACKEND
 525         tristate "Xen PCI-device backend driver"
 526         depends on PCI && ((X86 && PARAVIRT_XEN_BACKEND) || (XEN_PRIVILEGED_GUEST && XEN_BACKEND))
 527         default XEN_BACKEND if XEN
 528         default m
 529         help
 530           The PCI device backend driver allows the kernel to export arbitrary
 531           PCI devices to other guests. If you select this to be a module, you
 532           will need to make sure no other driver has bound to the device(s)
 533           you want to make visible to other guests.
 534
 535           The "hide" parameter (only applicable if backend driver is compiled
 536           into the kernel) allows you to bind the PCI devices to this module
 537           from the default device drivers. The argument is the list of PCI BDFs:
 538           xen-pciback.hide=(03:00.0)(04:00.0)
 539
 540           If in doubt, say m.
 541
 542 menu "PCI Backend Mode"
 543         depends on XEN_PCIDEV_BACKEND
 544
 545 choice
 546         prompt "Default PCI backend mode"
 547         default XEN_PCIDEV_BACKEND_DEFAULT_CONTROLLER if IA64
 548         default XEN_PCIDEV_BACKEND_DEFAULT_VPCI
 549
 550 config XEN_PCIDEV_BACKEND_DEFAULT_VPCI
 551         bool "Virtual PCI"
 552         select XEN_PCIDEV_BACKEND_VPCI
 553
 554 config XEN_PCIDEV_BACKEND_DEFAULT_PASSTHROUGH
 555         bool "Passthrough"
 556         select XEN_PCIDEV_BACKEND_PASSTHROUGH
 557
 558 config XEN_PCIDEV_BACKEND_DEFAULT_SLOT
 559         bool "Slot"
 560         select XEN_PCIDEV_BACKEND_SLOT
 561
 562 config XEN_PCIDEV_BACKEND_DEFAULT_CONTROLLER
 563         bool "Controller"
 564         depends on IA64
 565         select XEN_PCIDEV_BACKEND_CONTROLLER
 566
 567 endchoice
 568
 569 config XEN_PCIDEV_BACKEND_DEFAULT
 570         string
 571         default "vpci" if XEN_PCIDEV_BACKEND_DEFAULT_VPCI
 572         default "passthrough" if XEN_PCIDEV_BACKEND_DEFAULT_PASSTHROUGH
 573         default "slot" if XEN_PCIDEV_BACKEND_DEFAULT_SLOT
 574         default "controller" if XEN_PCIDEV_BACKEND_DEFAULT_CONTROLLER
 575
 576 config XEN_PCIDEV_BACKEND_VPCI
 577         bool "Virtual PCI"
 578         default X86
 579         ---help---
 580           This PCI Backend hides the true PCI topology and makes the frontend
 581           think there is a single PCI bus with only the exported devices on it.
 582           For example, a device at 03:05.0 will be re-assigned to 00:00.0. A
 583           second device at 02:1a.1 will be re-assigned to 00:01.1.
 584
 585           If not the default, the parameter "mode=vpci" allows you to use this
 586           mode.
 587
 588 config XEN_PCIDEV_BACKEND_PASSTHROUGH
 589         bool "Passthrough"
 590         ---help---
 591           This PCI Backend provides a real view of the PCI topology to the
 592           frontend (for example, a device at 06:01.b will still appear at
 593           06:01.b to the frontend). This is similar to how Xen 2.0.x exposed
 594           PCI devices to its driver domains. This may be required for drivers
 595           which depend on finding their hardward in certain bus/slot
 596           locations.
 597
 598           If not the default, the parameter "mode=passthrough" allows you to
 599           use this mode.
 600
 601 config XEN_PCIDEV_BACKEND_SLOT
 602         bool "Slot"
 603         ---help---
 604           This PCI Backend hides the true PCI topology and makes the frontend
 605           think there is a single PCI bus with only the exported devices on it.
 606           Contrary to the virtual PCI backend, a function becomes a new slot.
 607           For example, a device at 03:05.2 will be re-assigned to 00:00.0. A
 608           second device at 02:1a.1 will be re-assigned to 00:01.0.
 609
 610           If not the default, the parameter "mode=slot" allows you to use this
 611           mode.
 612
 613 config XEN_PCIDEV_BACKEND_CONTROLLER
 614         bool "Controller"
 615         depends on IA64
 616         ---help---
 617           This PCI backend virtualizes the PCI bus topology by providing a
 618           virtual bus per PCI root device.  Devices which are physically under
 619           the same root bus will appear on the same virtual bus.  For systems
 620           with complex I/O addressing, this is the only backend which supports
 621           extended I/O port spaces and MMIO translation offsets.  This backend
 622           also supports slot virtualization.  For example, a device at
 623           0000:01:02.1 will be re-assigned to 0000:00:00.0.  A second device
 624           at 0000:02:05.0 (behind a P2P bridge on bus 0000:01) will be
 625           re-assigned to 0000:00:01.0.  A third device at 0000:16:05.0 (under
 626           a different PCI root bus) will be re-assigned to 0000:01:00.0.
 627
 628           If not the default, the parameter "mode=controller" allows you to
 629           use this mode.
 630
 631 endmenu
 632
 633 config XEN_PRIVCMD
 634         tristate
 635         depends on PARAVIRT_XEN || (XEN && PROC_FS)
 636         default y if XEN
 637         default m
 638
 639 endmenu