0001 # SPDX-License-Identifier: GPL-2.0-only
0002 menu "Xen driver support"
0003 depends on XEN
0004
0005 config XEN_BALLOON
0006 bool "Xen memory balloon driver"
0007 default y
0008 help
0009 The balloon driver allows the Xen domain to request more memory from
0010 the system to expand the domain's memory allocation, or alternatively
0011 return unneeded memory to the system.
0012
0013 config XEN_BALLOON_MEMORY_HOTPLUG
0014 bool "Memory hotplug support for Xen balloon driver"
0015 depends on XEN_BALLOON && MEMORY_HOTPLUG
0016 default y
0017 help
0018 Memory hotplug support for Xen balloon driver allows expanding memory
0019 available for the system above limit declared at system startup.
0020 It is very useful on critical systems which require long
0021 run without rebooting.
0022
0023 It's also very useful for non PV domains to obtain unpopulated physical
0024 memory ranges to use in order to map foreign memory or grants.
0025
0026 Memory could be hotplugged in following steps:
0027
0028 1) target domain: ensure that memory auto online policy is in
0029 effect by checking /sys/devices/system/memory/auto_online_blocks
0030 file (should be 'online').
0031
0032 2) control domain: xl mem-max <target-domain> <maxmem>
0033 where <maxmem> is >= requested memory size,
0034
0035 3) control domain: xl mem-set <target-domain> <memory>
0036 where <memory> is requested memory size; alternatively memory
0037 could be added by writing proper value to
0038 /sys/devices/system/xen_memory/xen_memory0/target or
0039 /sys/devices/system/xen_memory/xen_memory0/target_kb on the
0040 target domain.
0041
0042 Alternatively, if memory auto onlining was not requested at step 1
0043 the newly added memory can be manually onlined in the target domain
0044 by doing the following:
0045
0046 for i in /sys/devices/system/memory/memory*/state; do \
0047 [ "`cat "$i"`" = offline ] && echo online > "$i"; done
0048
0049 or by adding the following line to udev rules:
0050
0051 SUBSYSTEM=="memory", ACTION=="add", RUN+="/bin/sh -c '[ -f /sys$devpath/state ] && echo online > /sys$devpath/state'"
0052
0053 config XEN_MEMORY_HOTPLUG_LIMIT
0054 int "Hotplugged memory limit (in GiB) for a PV guest"
0055 default 512
0056 depends on XEN_HAVE_PVMMU
0057 depends on MEMORY_HOTPLUG
0058 help
0059 Maxmium amount of memory (in GiB) that a PV guest can be
0060 expanded to when using memory hotplug.
0061
0062 A PV guest can have more memory than this limit if is
0063 started with a larger maximum.
0064
0065 This value is used to allocate enough space in internal
0066 tables needed for physical memory administration.
0067
0068 config XEN_SCRUB_PAGES_DEFAULT
0069 bool "Scrub pages before returning them to system by default"
0070 depends on XEN_BALLOON
0071 default y
0072 help
0073 Scrub pages before returning them to the system for reuse by
0074 other domains. This makes sure that any confidential data
0075 is not accidentally visible to other domains. It is more
0076 secure, but slightly less efficient. This can be controlled with
0077 xen_scrub_pages=0 parameter and
0078 /sys/devices/system/xen_memory/xen_memory0/scrub_pages.
0079 This option only sets the default value.
0080
0081 If in doubt, say yes.
0082
0083 config XEN_DEV_EVTCHN
0084 tristate "Xen /dev/xen/evtchn device"
0085 default y
0086 help
0087 The evtchn driver allows a userspace process to trigger event
0088 channels and to receive notification of an event channel
0089 firing.
0090 If in doubt, say yes.
0091
0092 config XEN_BACKEND
0093 bool "Backend driver support"
0094 default XEN_DOM0
0095 help
0096 Support for backend device drivers that provide I/O services
0097 to other virtual machines.
0098
0099 config XENFS
0100 tristate "Xen filesystem"
0101 select XEN_PRIVCMD
0102 default y
0103 help
0104 The xen filesystem provides a way for domains to share
0105 information with each other and with the hypervisor.
0106 For example, by reading and writing the "xenbus" file, guests
0107 may pass arbitrary information to the initial domain.
0108 If in doubt, say yes.
0109
0110 config XEN_COMPAT_XENFS
0111 bool "Create compatibility mount point /proc/xen"
0112 depends on XENFS
0113 default y
0114 help
0115 The old xenstore userspace tools expect to find "xenbus"
0116 under /proc/xen, but "xenbus" is now found at the root of the
0117 xenfs filesystem. Selecting this causes the kernel to create
0118 the compatibility mount point /proc/xen if it is running on
0119 a xen platform.
0120 If in doubt, say yes.
0121
0122 config XEN_SYS_HYPERVISOR
0123 bool "Create xen entries under /sys/hypervisor"
0124 depends on SYSFS
0125 select SYS_HYPERVISOR
0126 default y
0127 help
0128 Create entries under /sys/hypervisor describing the Xen
0129 hypervisor environment. When running native or in another
0130 virtual environment, /sys/hypervisor will still be present,
0131 but will have no xen contents.
0132
0133 config XEN_XENBUS_FRONTEND
0134 tristate
0135
0136 config XEN_GNTDEV
0137 tristate "userspace grant access device driver"
0138 depends on XEN
0139 default m
0140 select MMU_NOTIFIER
0141 help
0142 Allows userspace processes to use grants.
0143
0144 config XEN_GNTDEV_DMABUF
0145 bool "Add support for dma-buf grant access device driver extension"
0146 depends on XEN_GNTDEV && XEN_GRANT_DMA_ALLOC
0147 select DMA_SHARED_BUFFER
0148 help
0149 Allows userspace processes and kernel modules to use Xen backed
0150 dma-buf implementation. With this extension grant references to
0151 the pages of an imported dma-buf can be exported for other domain
0152 use and grant references coming from a foreign domain can be
0153 converted into a local dma-buf for local export.
0154
0155 config XEN_GRANT_DEV_ALLOC
0156 tristate "User-space grant reference allocator driver"
0157 depends on XEN
0158 default m
0159 help
0160 Allows userspace processes to create pages with access granted
0161 to other domains. This can be used to implement frontend drivers
0162 or as part of an inter-domain shared memory channel.
0163
0164 config XEN_GRANT_DMA_ALLOC
0165 bool "Allow allocating DMA capable buffers with grant reference module"
0166 depends on XEN && HAS_DMA
0167 help
0168 Extends grant table module API to allow allocating DMA capable
0169 buffers and mapping foreign grant references on top of it.
0170 The resulting buffer is similar to one allocated by the balloon
0171 driver in that proper memory reservation is made by
0172 ({increase|decrease}_reservation and VA mappings are updated if
0173 needed).
0174 This is useful for sharing foreign buffers with HW drivers which
0175 cannot work with scattered buffers provided by the balloon driver,
0176 but require DMAable memory instead.
0177
0178 config SWIOTLB_XEN
0179 def_bool y
0180 depends on XEN_PV || ARM || ARM64
0181 select DMA_OPS
0182 select SWIOTLB
0183
0184 config XEN_PCI_STUB
0185 bool
0186
0187 config XEN_PCIDEV_STUB
0188 tristate "Xen PCI-device stub driver"
0189 depends on PCI && !X86 && XEN
0190 depends on XEN_BACKEND
0191 select XEN_PCI_STUB
0192 default m
0193 help
0194 The PCI device stub driver provides limited version of the PCI
0195 device backend driver without para-virtualized support for guests.
0196 If you select this to be a module, you will need to make sure no
0197 other driver has bound to the device(s) you want to make visible to
0198 other guests.
0199
0200 The "hide" parameter (only applicable if backend driver is compiled
0201 into the kernel) allows you to bind the PCI devices to this module
0202 from the default device drivers. The argument is the list of PCI BDFs:
0203 xen-pciback.hide=(03:00.0)(04:00.0)
0204
0205 If in doubt, say m.
0206
0207 config XEN_PCIDEV_BACKEND
0208 tristate "Xen PCI-device backend driver"
0209 depends on PCI && X86 && XEN
0210 depends on XEN_BACKEND
0211 select XEN_PCI_STUB
0212 default m
0213 help
0214 The PCI device backend driver allows the kernel to export arbitrary
0215 PCI devices to other guests. If you select this to be a module, you
0216 will need to make sure no other driver has bound to the device(s)
0217 you want to make visible to other guests.
0218
0219 The parameter "passthrough" allows you specify how you want the PCI
0220 devices to appear in the guest. You can choose the default (0) where
0221 PCI topology starts at 00.00.0, or (1) for passthrough if you want
0222 the PCI devices topology appear the same as in the host.
0223
0224 The "hide" parameter (only applicable if backend driver is compiled
0225 into the kernel) allows you to bind the PCI devices to this module
0226 from the default device drivers. The argument is the list of PCI BDFs:
0227 xen-pciback.hide=(03:00.0)(04:00.0)
0228
0229 If in doubt, say m.
0230
0231 config XEN_PVCALLS_FRONTEND
0232 tristate "XEN PV Calls frontend driver"
0233 depends on INET && XEN
0234 select XEN_XENBUS_FRONTEND
0235 help
0236 Experimental frontend for the Xen PV Calls protocol
0237 (https://xenbits.xen.org/docs/unstable/misc/pvcalls.html). It
0238 sends a small set of POSIX calls to the backend, which
0239 implements them.
0240
0241 config XEN_PVCALLS_BACKEND
0242 tristate "XEN PV Calls backend driver"
0243 depends on INET && XEN && XEN_BACKEND
0244 help
0245 Experimental backend for the Xen PV Calls protocol
0246 (https://xenbits.xen.org/docs/unstable/misc/pvcalls.html). It
0247 allows PV Calls frontends to send POSIX calls to the backend,
0248 which implements them.
0249
0250 If in doubt, say n.
0251
0252 config XEN_SCSI_BACKEND
0253 tristate "XEN SCSI backend driver"
0254 depends on XEN && XEN_BACKEND && TARGET_CORE
0255 help
0256 The SCSI backend driver allows the kernel to export its SCSI Devices
0257 to other guests via a high-performance shared-memory interface.
0258 Only needed for systems running as XEN driver domains (e.g. Dom0) and
0259 if guests need generic access to SCSI devices.
0260
0261 config XEN_PRIVCMD
0262 tristate "Xen hypercall passthrough driver"
0263 depends on XEN
0264 default m
0265 help
0266 The hypercall passthrough driver allows privileged user programs to
0267 perform Xen hypercalls. This driver is normally required for systems
0268 running as Dom0 to perform privileged operations, but in some
0269 disaggregated Xen setups this driver might be needed for other
0270 domains, too.
0271
0272 config XEN_ACPI_PROCESSOR
0273 tristate "Xen ACPI processor"
0274 depends on XEN && XEN_PV_DOM0 && X86 && ACPI_PROCESSOR && CPU_FREQ
0275 default m
0276 help
0277 This ACPI processor uploads Power Management information to the Xen
0278 hypervisor.
0279
0280 To do that the driver parses the Power Management data and uploads
0281 said information to the Xen hypervisor. Then the Xen hypervisor can
0282 select the proper Cx and Pxx states. It also registers itself as the
0283 SMM so that other drivers (such as ACPI cpufreq scaling driver) will
0284 not load.
0285
0286 To compile this driver as a module, choose M here: the module will be
0287 called xen_acpi_processor If you do not know what to choose, select
0288 M here. If the CPUFREQ drivers are built in, select Y here.
0289
0290 config XEN_MCE_LOG
0291 bool "Xen platform mcelog"
0292 depends on XEN_PV_DOM0 && X86_MCE
0293 help
0294 Allow kernel fetching MCE error from Xen platform and
0295 converting it into Linux mcelog format for mcelog tools
0296
0297 config XEN_HAVE_PVMMU
0298 bool
0299
0300 config XEN_EFI
0301 def_bool y
0302 depends on (ARM || ARM64 || X86_64) && EFI
0303
0304 config XEN_AUTO_XLATE
0305 def_bool y
0306 depends on ARM || ARM64 || XEN_PVHVM
0307 help
0308 Support for auto-translated physmap guests.
0309
0310 config XEN_ACPI
0311 def_bool y
0312 depends on X86 && ACPI
0313
0314 config XEN_SYMS
0315 bool "Xen symbols"
0316 depends on X86 && XEN_DOM0 && XENFS
0317 default y if KALLSYMS
0318 help
0319 Exports hypervisor symbols (along with their types and addresses) via
0320 /proc/xen/xensyms file, similar to /proc/kallsyms
0321
0322 config XEN_HAVE_VPMU
0323 bool
0324
0325 config XEN_FRONT_PGDIR_SHBUF
0326 tristate
0327
0328 config XEN_UNPOPULATED_ALLOC
0329 bool "Use unpopulated memory ranges for guest mappings"
0330 depends on ZONE_DEVICE
0331 default XEN_BACKEND || XEN_GNTDEV || XEN_DOM0
0332 help
0333 Use unpopulated memory ranges in order to create mappings for guest
0334 memory regions, including grant maps and foreign pages. This avoids
0335 having to balloon out RAM regions in order to obtain physical memory
0336 space to create such mappings.
0337
0338 config XEN_GRANT_DMA_IOMMU
0339 bool
0340 select IOMMU_API
0341
0342 config XEN_GRANT_DMA_OPS
0343 bool
0344 select DMA_OPS
0345
0346 config XEN_VIRTIO
0347 bool "Xen virtio support"
0348 depends on VIRTIO
0349 select XEN_GRANT_DMA_OPS
0350 select XEN_GRANT_DMA_IOMMU if OF
0351 help
0352 Enable virtio support for running as Xen guest. Depending on the
0353 guest type this will require special support on the backend side
0354 (qemu or kernel, depending on the virtio device types used).
0355
0356 If in doubt, say n.
0357
0358 config XEN_VIRTIO_FORCE_GRANT
0359 bool "Require Xen virtio support to use grants"
0360 depends on XEN_VIRTIO
0361 help
0362 Require virtio for Xen guests to use grant mappings.
0363 This will avoid the need to give the backend the right to map all
0364 of the guest memory. This will need support on the backend side
0365 (e.g. qemu or kernel, depending on the virtio device types used).
0366
0367 endmenu
