| | 1 | # SPDX-License-Identifier: GPL-2.0-only |
| | 2 | menu "Xen driver support" |
| | 3 | depends on XEN |
| | 4 | |
| | 5 | config XEN_BALLOON |
| | 6 | bool "Xen memory balloon driver" |
| | 7 | default y |
| | 8 | help |
| | 9 | The balloon driver allows the Xen domain to request more memory from |
| | 10 | the system to expand the domain's memory allocation, or alternatively |
| | 11 | return unneeded memory to the system. |
| | 12 | |
| | 13 | config XEN_BALLOON_MEMORY_HOTPLUG |
| | 14 | bool "Memory hotplug support for Xen balloon driver" |
| | 15 | depends on XEN_BALLOON && MEMORY_HOTPLUG |
| | 16 | help |
| | 17 | Memory hotplug support for Xen balloon driver allows expanding memory |
| | 18 | available for the system above limit declared at system startup. |
| | 19 | It is very useful on critical systems which require long |
| | 20 | run without rebooting. |
| | 21 | |
| | 22 | Memory could be hotplugged in following steps: |
| | 23 | |
| | 24 | 1) target domain: ensure that memory auto online policy is in |
| | 25 | effect by checking /sys/devices/system/memory/auto_online_blocks |
| | 26 | file (should be 'online'). |
| | 27 | |
| | 28 | 2) control domain: xl mem-max <target-domain> <maxmem> |
| | 29 | where <maxmem> is >= requested memory size, |
| | 30 | |
| | 31 | 3) control domain: xl mem-set <target-domain> <memory> |
| | 32 | where <memory> is requested memory size; alternatively memory |
| | 33 | could be added by writing proper value to |
| | 34 | /sys/devices/system/xen_memory/xen_memory0/target or |
| | 35 | /sys/devices/system/xen_memory/xen_memory0/target_kb on the |
| | 36 | target domain. |
| | 37 | |
| | 38 | Alternatively, if memory auto onlining was not requested at step 1 |
| | 39 | the newly added memory can be manually onlined in the target domain |
| | 40 | by doing the following: |
| | 41 | |
| | 42 | for i in /sys/devices/system/memory/memory*/state; do \ |
| | 43 | [ "`cat "$i"`" = offline ] && echo online > "$i"; done |
| | 44 | |
| | 45 | or by adding the following line to udev rules: |
| | 46 | |
| | 47 | SUBSYSTEM=="memory", ACTION=="add", RUN+="/bin/sh -c '[ -f /sys$devpath/state ] && echo online > /sys$devpath/state'" |
| | 48 | |
| | 49 | config XEN_BALLOON_MEMORY_HOTPLUG_LIMIT |
| | 50 | int "Hotplugged memory limit (in GiB) for a PV guest" |
| | 51 | default 512 if X86_64 |
| | 52 | default 4 if X86_32 |
| | 53 | range 0 64 if X86_32 |
| | 54 | depends on XEN_HAVE_PVMMU |
| | 55 | depends on XEN_BALLOON_MEMORY_HOTPLUG |
| | 56 | help |
| | 57 | Maxmium amount of memory (in GiB) that a PV guest can be |
| | 58 | expanded to when using memory hotplug. |
| | 59 | |
| | 60 | A PV guest can have more memory than this limit if is |
| | 61 | started with a larger maximum. |
| | 62 | |
| | 63 | This value is used to allocate enough space in internal |
| | 64 | tables needed for physical memory administration. |
| | 65 | |
| | 66 | config XEN_SCRUB_PAGES_DEFAULT |
| | 67 | bool "Scrub pages before returning them to system by default" |
| | 68 | depends on XEN_BALLOON |
| | 69 | default y |
| | 70 | help |
| | 71 | Scrub pages before returning them to the system for reuse by |
| | 72 | other domains. This makes sure that any confidential data |
| | 73 | is not accidentally visible to other domains. It is more |
| | 74 | secure, but slightly less efficient. This can be controlled with |
| | 75 | xen_scrub_pages=0 parameter and |
| | 76 | /sys/devices/system/xen_memory/xen_memory0/scrub_pages. |
| | 77 | This option only sets the default value. |
| | 78 | |
| | 79 | If in doubt, say yes. |
| | 80 | |
| | 81 | config XEN_DEV_EVTCHN |
| | 82 | tristate "Xen /dev/xen/evtchn device" |
| | 83 | default y |
| | 84 | help |
| | 85 | The evtchn driver allows a userspace process to trigger event |
| | 86 | channels and to receive notification of an event channel |
| | 87 | firing. |
| | 88 | If in doubt, say yes. |
| | 89 | |
| | 90 | config XEN_BACKEND |
| | 91 | bool "Backend driver support" |
| | 92 | default XEN_DOM0 |
| | 93 | help |
| | 94 | Support for backend device drivers that provide I/O services |
| | 95 | to other virtual machines. |
| | 96 | |
| | 97 | config XENFS |
| | 98 | tristate "Xen filesystem" |
| | 99 | select XEN_PRIVCMD |
| | 100 | default y |
| | 101 | help |
| | 102 | The xen filesystem provides a way for domains to share |
| | 103 | information with each other and with the hypervisor. |
| | 104 | For example, by reading and writing the "xenbus" file, guests |
| | 105 | may pass arbitrary information to the initial domain. |
| | 106 | If in doubt, say yes. |
| | 107 | |
| | 108 | config XEN_COMPAT_XENFS |
| | 109 | bool "Create compatibility mount point /proc/xen" |
| | 110 | depends on XENFS |
| | 111 | default y |
| | 112 | help |
| | 113 | The old xenstore userspace tools expect to find "xenbus" |
| | 114 | under /proc/xen, but "xenbus" is now found at the root of the |
| | 115 | xenfs filesystem. Selecting this causes the kernel to create |
| | 116 | the compatibility mount point /proc/xen if it is running on |
| | 117 | a xen platform. |
| | 118 | If in doubt, say yes. |
| | 119 | |
| | 120 | config XEN_SYS_HYPERVISOR |
| | 121 | bool "Create xen entries under /sys/hypervisor" |
| | 122 | depends on SYSFS |
| | 123 | select SYS_HYPERVISOR |
| | 124 | default y |
| | 125 | help |
| | 126 | Create entries under /sys/hypervisor describing the Xen |
| | 127 | hypervisor environment. When running native or in another |
| | 128 | virtual environment, /sys/hypervisor will still be present, |
| | 129 | but will have no xen contents. |
| | 130 | |
| | 131 | config XEN_XENBUS_FRONTEND |
| | 132 | tristate |
| | 133 | |
| | 134 | config XEN_GNTDEV |
| | 135 | tristate "userspace grant access device driver" |
| | 136 | depends on XEN |
| | 137 | default m |
| | 138 | select MMU_NOTIFIER |
| | 139 | help |
| | 140 | Allows userspace processes to use grants. |
| | 141 | |
| | 142 | config XEN_GNTDEV_DMABUF |
| | 143 | bool "Add support for dma-buf grant access device driver extension" |
| | 144 | depends on XEN_GNTDEV && XEN_GRANT_DMA_ALLOC && DMA_SHARED_BUFFER |
| | 145 | help |
| | 146 | Allows userspace processes and kernel modules to use Xen backed |
| | 147 | dma-buf implementation. With this extension grant references to |
| | 148 | the pages of an imported dma-buf can be exported for other domain |
| | 149 | use and grant references coming from a foreign domain can be |
| | 150 | converted into a local dma-buf for local export. |
| | 151 | |
| | 152 | config XEN_GRANT_DEV_ALLOC |
| | 153 | tristate "User-space grant reference allocator driver" |
| | 154 | depends on XEN |
| | 155 | default m |
| | 156 | help |
| | 157 | Allows userspace processes to create pages with access granted |
| | 158 | to other domains. This can be used to implement frontend drivers |
| | 159 | or as part of an inter-domain shared memory channel. |
| | 160 | |
| | 161 | config XEN_GRANT_DMA_ALLOC |
| | 162 | bool "Allow allocating DMA capable buffers with grant reference module" |
| | 163 | depends on XEN && HAS_DMA |
| | 164 | help |
| | 165 | Extends grant table module API to allow allocating DMA capable |
| | 166 | buffers and mapping foreign grant references on top of it. |
| | 167 | The resulting buffer is similar to one allocated by the balloon |
| | 168 | driver in that proper memory reservation is made by |
| | 169 | ({increase|decrease}_reservation and VA mappings are updated if |
| | 170 | needed). |
| | 171 | This is useful for sharing foreign buffers with HW drivers which |
| | 172 | cannot work with scattered buffers provided by the balloon driver, |
| | 173 | but require DMAable memory instead. |
| | 174 | |
| | 175 | config SWIOTLB_XEN |
| | 176 | def_bool y |
| | 177 | select SWIOTLB |
| | 178 | |
| | 179 | config XEN_PCIDEV_BACKEND |
| | 180 | tristate "Xen PCI-device backend driver" |
| | 181 | depends on PCI && X86 && XEN |
| | 182 | depends on XEN_BACKEND |
| | 183 | default m |
| | 184 | help |
| | 185 | The PCI device backend driver allows the kernel to export arbitrary |
| | 186 | PCI devices to other guests. If you select this to be a module, you |
| | 187 | will need to make sure no other driver has bound to the device(s) |
| | 188 | you want to make visible to other guests. |
| | 189 | |
| | 190 | The parameter "passthrough" allows you specify how you want the PCI |
| | 191 | devices to appear in the guest. You can choose the default (0) where |
| | 192 | PCI topology starts at 00.00.0, or (1) for passthrough if you want |
| | 193 | the PCI devices topology appear the same as in the host. |
| | 194 | |
| | 195 | The "hide" parameter (only applicable if backend driver is compiled |
| | 196 | into the kernel) allows you to bind the PCI devices to this module |
| | 197 | from the default device drivers. The argument is the list of PCI BDFs: |
| | 198 | xen-pciback.hide=(03:00.0)(04:00.0) |
| | 199 | |
| | 200 | If in doubt, say m. |
| | 201 | |
| | 202 | config XEN_PVCALLS_FRONTEND |
| | 203 | tristate "XEN PV Calls frontend driver" |
| | 204 | depends on INET && XEN |
| | 205 | select XEN_XENBUS_FRONTEND |
| | 206 | help |
| | 207 | Experimental frontend for the Xen PV Calls protocol |
| | 208 | (https://xenbits.xen.org/docs/unstable/misc/pvcalls.html). It |
| | 209 | sends a small set of POSIX calls to the backend, which |
| | 210 | implements them. |
| | 211 | |
| | 212 | config XEN_PVCALLS_BACKEND |
| | 213 | bool "XEN PV Calls backend driver" |
| | 214 | depends on INET && XEN && XEN_BACKEND |
| | 215 | help |
| | 216 | Experimental backend for the Xen PV Calls protocol |
| | 217 | (https://xenbits.xen.org/docs/unstable/misc/pvcalls.html). It |
| | 218 | allows PV Calls frontends to send POSIX calls to the backend, |
| | 219 | which implements them. |
| | 220 | |
| | 221 | If in doubt, say n. |
| | 222 | |
| | 223 | config XEN_SCSI_BACKEND |
| | 224 | tristate "XEN SCSI backend driver" |
| | 225 | depends on XEN && XEN_BACKEND && TARGET_CORE |
| | 226 | help |
| | 227 | The SCSI backend driver allows the kernel to export its SCSI Devices |
| | 228 | to other guests via a high-performance shared-memory interface. |
| | 229 | Only needed for systems running as XEN driver domains (e.g. Dom0) and |
| | 230 | if guests need generic access to SCSI devices. |
| | 231 | |
| | 232 | config XEN_PRIVCMD |
| | 233 | tristate |
| | 234 | depends on XEN |
| | 235 | default m |
| | 236 | |
| | 237 | config XEN_STUB |
| | 238 | bool "Xen stub drivers" |
| | 239 | depends on XEN && X86_64 && BROKEN |
| | 240 | help |
| | 241 | Allow kernel to install stub drivers, to reserve space for Xen drivers, |
| | 242 | i.e. memory hotplug and cpu hotplug, and to block native drivers loaded, |
| | 243 | so that real Xen drivers can be modular. |
| | 244 | |
| | 245 | To enable Xen features like cpu and memory hotplug, select Y here. |
| | 246 | |
| | 247 | config XEN_ACPI_HOTPLUG_MEMORY |
| | 248 | tristate "Xen ACPI memory hotplug" |
| | 249 | depends on XEN_DOM0 && XEN_STUB && ACPI |
| | 250 | help |
| | 251 | This is Xen ACPI memory hotplug. |
| | 252 | |
| | 253 | Currently Xen only support ACPI memory hot-add. If you want |
| | 254 | to hot-add memory at runtime (the hot-added memory cannot be |
| | 255 | removed until machine stop), select Y/M here, otherwise select N. |
| | 256 | |
| | 257 | config XEN_ACPI_HOTPLUG_CPU |
| | 258 | tristate "Xen ACPI cpu hotplug" |
| | 259 | depends on XEN_DOM0 && XEN_STUB && ACPI |
| | 260 | select ACPI_CONTAINER |
| | 261 | help |
| | 262 | Xen ACPI cpu enumerating and hotplugging |
| | 263 | |
| | 264 | For hotplugging, currently Xen only support ACPI cpu hotadd. |
| | 265 | If you want to hotadd cpu at runtime (the hotadded cpu cannot |
| | 266 | be removed until machine stop), select Y/M here. |
| | 267 | |
| | 268 | config XEN_ACPI_PROCESSOR |
| | 269 | tristate "Xen ACPI processor" |
| | 270 | depends on XEN && XEN_DOM0 && X86 && ACPI_PROCESSOR && CPU_FREQ |
| | 271 | default m |
| | 272 | help |
| | 273 | This ACPI processor uploads Power Management information to the Xen |
| | 274 | hypervisor. |
| | 275 | |
| | 276 | To do that the driver parses the Power Management data and uploads |
| | 277 | said information to the Xen hypervisor. Then the Xen hypervisor can |
| | 278 | select the proper Cx and Pxx states. It also registers itself as the |
| | 279 | SMM so that other drivers (such as ACPI cpufreq scaling driver) will |
| | 280 | not load. |
| | 281 | |
| | 282 | To compile this driver as a module, choose M here: the module will be |
| | 283 | called xen_acpi_processor If you do not know what to choose, select |
| | 284 | M here. If the CPUFREQ drivers are built in, select Y here. |
| | 285 | |
| | 286 | config XEN_MCE_LOG |
| | 287 | bool "Xen platform mcelog" |
| | 288 | depends on XEN_DOM0 && X86_64 && X86_MCE |
| | 289 | help |
| | 290 | Allow kernel fetching MCE error from Xen platform and |
| | 291 | converting it into Linux mcelog format for mcelog tools |
| | 292 | |
| | 293 | config XEN_HAVE_PVMMU |
| | 294 | bool |
| | 295 | |
| | 296 | config XEN_EFI |
| | 297 | def_bool y |
| | 298 | depends on (ARM || ARM64 || X86_64) && EFI |
| | 299 | |
| | 300 | config XEN_AUTO_XLATE |
| | 301 | def_bool y |
| | 302 | depends on ARM || ARM64 || XEN_PVHVM |
| | 303 | help |
| | 304 | Support for auto-translated physmap guests. |
| | 305 | |
| | 306 | config XEN_ACPI |
| | 307 | def_bool y |
| | 308 | depends on X86 && ACPI |
| | 309 | |
| | 310 | config XEN_SYMS |
| | 311 | bool "Xen symbols" |
| | 312 | depends on X86 && XEN_DOM0 && XENFS |
| | 313 | default y if KALLSYMS |
| | 314 | help |
| | 315 | Exports hypervisor symbols (along with their types and addresses) via |
| | 316 | /proc/xen/xensyms file, similar to /proc/kallsyms |
| | 317 | |
| | 318 | config XEN_HAVE_VPMU |
| | 319 | bool |
| | 320 | |
| | 321 | config XEN_FRONT_PGDIR_SHBUF |
| | 322 | tristate |
| | 323 | |
| | 324 | endmenu |
projects / linux-2.6-block.git / blame_incremental