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