tmem is not supported on arm or arm64 yet. Will revert this once the Xen hypervisor supports it. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
		
			
				
	
	
		
			245 lines
		
	
	
	
		
			8.1 KiB
			
		
	
	
	
		
			Text
		
	
	
	
	
	
			
		
		
	
	
			245 lines
		
	
	
	
		
			8.1 KiB
			
		
	
	
	
		
			Text
		
	
	
	
	
	
menu "Xen driver support"
 | 
						|
	depends on XEN
 | 
						|
 | 
						|
config XEN_BALLOON
 | 
						|
	bool "Xen memory balloon driver"
 | 
						|
	depends on !ARM
 | 
						|
	default y
 | 
						|
	help
 | 
						|
	  The balloon driver allows the Xen domain to request more memory from
 | 
						|
	  the system to expand the domain's memory allocation, or alternatively
 | 
						|
	  return unneeded memory to the system.
 | 
						|
 | 
						|
config XEN_SELFBALLOONING
 | 
						|
	bool "Dynamically self-balloon kernel memory to target"
 | 
						|
	depends on XEN && XEN_BALLOON && CLEANCACHE && SWAP && XEN_TMEM
 | 
						|
	default n
 | 
						|
	help
 | 
						|
	  Self-ballooning dynamically balloons available kernel memory driven
 | 
						|
	  by the current usage of anonymous memory ("committed AS") and
 | 
						|
	  controlled by various sysfs-settable parameters.  Configuring
 | 
						|
	  FRONTSWAP is highly recommended; if it is not configured, self-
 | 
						|
	  ballooning is disabled by default. If FRONTSWAP is configured,
 | 
						|
	  frontswap-selfshrinking is enabled by default but can be disabled
 | 
						|
	  with the 'tmem.selfshrink=0' kernel boot parameter; and self-ballooning
 | 
						|
	  is enabled by default but can be disabled with the 'tmem.selfballooning=0'
 | 
						|
	  kernel boot parameter.  Note that systems without a sufficiently
 | 
						|
	  large swap device should not enable self-ballooning.
 | 
						|
 | 
						|
config XEN_BALLOON_MEMORY_HOTPLUG
 | 
						|
	bool "Memory hotplug support for Xen balloon driver"
 | 
						|
	default n
 | 
						|
	depends on XEN_BALLOON && MEMORY_HOTPLUG
 | 
						|
	help
 | 
						|
	  Memory hotplug support for Xen balloon driver allows expanding memory
 | 
						|
	  available for the system above limit declared at system startup.
 | 
						|
	  It is very useful on critical systems which require long
 | 
						|
	  run without rebooting.
 | 
						|
 | 
						|
	  Memory could be hotplugged in following steps:
 | 
						|
 | 
						|
	    1) dom0: xl mem-max <domU> <maxmem>
 | 
						|
	       where <maxmem> is >= requested memory size,
 | 
						|
 | 
						|
	    2) dom0: xl mem-set <domU> <memory>
 | 
						|
	       where <memory> is requested memory size; alternatively memory
 | 
						|
	       could be added by writing proper value to
 | 
						|
	       /sys/devices/system/xen_memory/xen_memory0/target or
 | 
						|
	       /sys/devices/system/xen_memory/xen_memory0/target_kb on dumU,
 | 
						|
 | 
						|
	    3) domU: for i in /sys/devices/system/memory/memory*/state; do \
 | 
						|
	               [ "`cat "$i"`" = offline ] && echo online > "$i"; done
 | 
						|
 | 
						|
	  Memory could be onlined automatically on domU by adding following line to udev rules:
 | 
						|
 | 
						|
	  SUBSYSTEM=="memory", ACTION=="add", RUN+="/bin/sh -c '[ -f /sys$devpath/state ] && echo online > /sys$devpath/state'"
 | 
						|
 | 
						|
	  In that case step 3 should be omitted.
 | 
						|
 | 
						|
config XEN_SCRUB_PAGES
 | 
						|
	bool "Scrub pages before returning them to system"
 | 
						|
	depends on XEN_BALLOON
 | 
						|
	default y
 | 
						|
	help
 | 
						|
	  Scrub pages before returning them to the system for reuse by
 | 
						|
	  other domains.  This makes sure that any confidential data
 | 
						|
	  is not accidentally visible to other domains.  Is it more
 | 
						|
	  secure, but slightly less efficient.
 | 
						|
	  If in doubt, say yes.
 | 
						|
 | 
						|
config XEN_DEV_EVTCHN
 | 
						|
	tristate "Xen /dev/xen/evtchn device"
 | 
						|
	default y
 | 
						|
	help
 | 
						|
	  The evtchn driver allows a userspace process to trigger event
 | 
						|
	  channels and to receive notification of an event channel
 | 
						|
	  firing.
 | 
						|
	  If in doubt, say yes.
 | 
						|
 | 
						|
config XEN_BACKEND
 | 
						|
	bool "Backend driver support"
 | 
						|
	depends on XEN_DOM0
 | 
						|
	default y
 | 
						|
	help
 | 
						|
	  Support for backend device drivers that provide I/O services
 | 
						|
	  to other virtual machines.
 | 
						|
 | 
						|
config XENFS
 | 
						|
	tristate "Xen filesystem"
 | 
						|
	select XEN_PRIVCMD
 | 
						|
	default y
 | 
						|
	help
 | 
						|
	  The xen filesystem provides a way for domains to share
 | 
						|
	  information with each other and with the hypervisor.
 | 
						|
	  For example, by reading and writing the "xenbus" file, guests
 | 
						|
	  may pass arbitrary information to the initial domain.
 | 
						|
	  If in doubt, say yes.
 | 
						|
 | 
						|
config XEN_COMPAT_XENFS
 | 
						|
       bool "Create compatibility mount point /proc/xen"
 | 
						|
       depends on XENFS
 | 
						|
       default y
 | 
						|
       help
 | 
						|
         The old xenstore userspace tools expect to find "xenbus"
 | 
						|
         under /proc/xen, but "xenbus" is now found at the root of the
 | 
						|
         xenfs filesystem.  Selecting this causes the kernel to create
 | 
						|
         the compatibility mount point /proc/xen if it is running on
 | 
						|
         a xen platform.
 | 
						|
         If in doubt, say yes.
 | 
						|
 | 
						|
config XEN_SYS_HYPERVISOR
 | 
						|
       bool "Create xen entries under /sys/hypervisor"
 | 
						|
       depends on SYSFS
 | 
						|
       select SYS_HYPERVISOR
 | 
						|
       default y
 | 
						|
       help
 | 
						|
         Create entries under /sys/hypervisor describing the Xen
 | 
						|
	 hypervisor environment.  When running native or in another
 | 
						|
	 virtual environment, /sys/hypervisor will still be present,
 | 
						|
	 but will have no xen contents.
 | 
						|
 | 
						|
config XEN_XENBUS_FRONTEND
 | 
						|
	tristate
 | 
						|
 | 
						|
config XEN_GNTDEV
 | 
						|
	tristate "userspace grant access device driver"
 | 
						|
	depends on XEN
 | 
						|
	default m
 | 
						|
	select MMU_NOTIFIER
 | 
						|
	help
 | 
						|
	  Allows userspace processes to use grants.
 | 
						|
 | 
						|
config XEN_GRANT_DEV_ALLOC
 | 
						|
	tristate "User-space grant reference allocator driver"
 | 
						|
	depends on XEN
 | 
						|
	default m
 | 
						|
	help
 | 
						|
	  Allows userspace processes to create pages with access granted
 | 
						|
	  to other domains. This can be used to implement frontend drivers
 | 
						|
	  or as part of an inter-domain shared memory channel.
 | 
						|
 | 
						|
config SWIOTLB_XEN
 | 
						|
	def_bool y
 | 
						|
	depends on PCI && X86
 | 
						|
	select SWIOTLB
 | 
						|
 | 
						|
config XEN_TMEM
 | 
						|
	tristate
 | 
						|
	depends on !ARM && !ARM64
 | 
						|
	default m if (CLEANCACHE || FRONTSWAP)
 | 
						|
	help
 | 
						|
	  Shim to interface in-kernel Transcendent Memory hooks
 | 
						|
	  (e.g. cleancache and frontswap) to Xen tmem hypercalls.
 | 
						|
 | 
						|
config XEN_PCIDEV_BACKEND
 | 
						|
	tristate "Xen PCI-device backend driver"
 | 
						|
	depends on PCI && X86 && XEN
 | 
						|
	depends on XEN_BACKEND
 | 
						|
	default m
 | 
						|
	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.
 | 
						|
 | 
						|
	  The parameter "passthrough" allows you specify how you want the PCI
 | 
						|
	  devices to appear in the guest. You can choose the default (0) where
 | 
						|
	  PCI topology starts at 00.00.0, or (1) for passthrough if you want
 | 
						|
	  the PCI devices topology appear the same as in the host.
 | 
						|
 | 
						|
	  The "hide" parameter (only applicable if backend driver is compiled
 | 
						|
	  into the kernel) allows you to bind the PCI devices to this module
 | 
						|
	  from the default device drivers. The argument is the list of PCI BDFs:
 | 
						|
	  xen-pciback.hide=(03:00.0)(04:00.0)
 | 
						|
 | 
						|
	  If in doubt, say m.
 | 
						|
 | 
						|
config XEN_PRIVCMD
 | 
						|
	tristate
 | 
						|
	depends on XEN
 | 
						|
	default m
 | 
						|
 | 
						|
config XEN_STUB
 | 
						|
	bool "Xen stub drivers"
 | 
						|
	depends on XEN && X86_64 && BROKEN
 | 
						|
	default n
 | 
						|
	help
 | 
						|
	  Allow kernel to install stub drivers, to reserve space for Xen drivers,
 | 
						|
	  i.e. memory hotplug and cpu hotplug, and to block native drivers loaded,
 | 
						|
	  so that real Xen drivers can be modular.
 | 
						|
 | 
						|
	  To enable Xen features like cpu and memory hotplug, select Y here.
 | 
						|
 | 
						|
config XEN_ACPI_HOTPLUG_MEMORY
 | 
						|
	tristate "Xen ACPI memory hotplug"
 | 
						|
	depends on XEN_DOM0 && XEN_STUB && ACPI
 | 
						|
	default n
 | 
						|
	help
 | 
						|
	  This is Xen ACPI memory hotplug.
 | 
						|
 | 
						|
	  Currently Xen only support ACPI memory hot-add. If you want
 | 
						|
	  to hot-add memory at runtime (the hot-added memory cannot be
 | 
						|
	  removed until machine stop), select Y/M here, otherwise select N.
 | 
						|
 | 
						|
config XEN_ACPI_HOTPLUG_CPU
 | 
						|
	tristate "Xen ACPI cpu hotplug"
 | 
						|
	depends on XEN_DOM0 && XEN_STUB && ACPI
 | 
						|
	select ACPI_CONTAINER
 | 
						|
	default n
 | 
						|
	help
 | 
						|
	  Xen ACPI cpu enumerating and hotplugging
 | 
						|
 | 
						|
	  For hotplugging, currently Xen only support ACPI cpu hotadd.
 | 
						|
	  If you want to hotadd cpu at runtime (the hotadded cpu cannot
 | 
						|
	  be removed until machine stop), select Y/M here.
 | 
						|
 | 
						|
config XEN_ACPI_PROCESSOR
 | 
						|
	tristate "Xen ACPI processor"
 | 
						|
	depends on XEN && X86 && ACPI_PROCESSOR && CPU_FREQ
 | 
						|
	default m
 | 
						|
	help
 | 
						|
          This ACPI processor uploads Power Management information to the Xen
 | 
						|
	  hypervisor.
 | 
						|
 | 
						|
	  To do that the driver parses the Power Management data and uploads
 | 
						|
	  said information to the Xen hypervisor. Then the Xen hypervisor can
 | 
						|
	  select the proper Cx and Pxx states. It also registers itslef as the
 | 
						|
	  SMM so that other drivers (such as ACPI cpufreq scaling driver) will
 | 
						|
	  not load.
 | 
						|
 | 
						|
          To compile this driver as a module, choose M here: the module will be
 | 
						|
	  called xen_acpi_processor  If you do not know what to choose, select
 | 
						|
	  M here. If the CPUFREQ drivers are built in, select Y here.
 | 
						|
 | 
						|
config XEN_MCE_LOG
 | 
						|
	bool "Xen platform mcelog"
 | 
						|
	depends on XEN_DOM0 && X86_64 && X86_MCE
 | 
						|
	default n
 | 
						|
	help
 | 
						|
	  Allow kernel fetching MCE error from Xen platform and
 | 
						|
	  converting it into Linux mcelog format for mcelog tools
 | 
						|
 | 
						|
config XEN_HAVE_PVMMU
 | 
						|
       bool
 | 
						|
 | 
						|
endmenu
 |