WSL2-Linux-Kernel/drivers/xen/Kconfig

menu "Xen driver support"
	depends on XEN

config XEN_BALLOON
	bool "Xen memory balloon driver"
	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_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 triger 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"
	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 XEN_PLATFORM_PCI
	tristate "xen platform pci device driver"
	depends on XEN_PVHVM && PCI
	default m
	help
	  Driver for the Xen PCI Platform device: it is responsible for
	  initializing xenbus and grant_table when running in a Xen HVM
	  domain. As a consequence this driver is required to run any Xen PV
	  frontend on Xen HVM.

config SWIOTLB_XEN
	def_bool y
	depends on PCI
	select SWIOTLB

config XEN_PCIDEV_BACKEND
	tristate "Xen PCI-device backend driver"
	depends on PCI && X86 && XEN
	depends on XEN_BACKEND
	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

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.

endchoice

endmenu