About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / virtual / kvm / api.txt




Custom Search

Based on kernel version 4.13.3. Page generated on 2017-09-23 13:56 EST.

1	The Definitive KVM (Kernel-based Virtual Machine) API Documentation
2	===================================================================
3	
4	1. General description
5	----------------------
6	
7	The kvm API is a set of ioctls that are issued to control various aspects
8	of a virtual machine.  The ioctls belong to three classes
9	
10	 - System ioctls: These query and set global attributes which affect the
11	   whole kvm subsystem.  In addition a system ioctl is used to create
12	   virtual machines
13	
14	 - VM ioctls: These query and set attributes that affect an entire virtual
15	   machine, for example memory layout.  In addition a VM ioctl is used to
16	   create virtual cpus (vcpus).
17	
18	   Only run VM ioctls from the same process (address space) that was used
19	   to create the VM.
20	
21	 - vcpu ioctls: These query and set attributes that control the operation
22	   of a single virtual cpu.
23	
24	   Only run vcpu ioctls from the same thread that was used to create the
25	   vcpu.
26	
27	
28	2. File descriptors
29	-------------------
30	
31	The kvm API is centered around file descriptors.  An initial
32	open("/dev/kvm") obtains a handle to the kvm subsystem; this handle
33	can be used to issue system ioctls.  A KVM_CREATE_VM ioctl on this
34	handle will create a VM file descriptor which can be used to issue VM
35	ioctls.  A KVM_CREATE_VCPU ioctl on a VM fd will create a virtual cpu
36	and return a file descriptor pointing to it.  Finally, ioctls on a vcpu
37	fd can be used to control the vcpu, including the important task of
38	actually running guest code.
39	
40	In general file descriptors can be migrated among processes by means
41	of fork() and the SCM_RIGHTS facility of unix domain socket.  These
42	kinds of tricks are explicitly not supported by kvm.  While they will
43	not cause harm to the host, their actual behavior is not guaranteed by
44	the API.  The only supported use is one virtual machine per process,
45	and one vcpu per thread.
46	
47	
48	3. Extensions
49	-------------
50	
51	As of Linux 2.6.22, the KVM ABI has been stabilized: no backward
52	incompatible change are allowed.  However, there is an extension
53	facility that allows backward-compatible extensions to the API to be
54	queried and used.
55	
56	The extension mechanism is not based on the Linux version number.
57	Instead, kvm defines extension identifiers and a facility to query
58	whether a particular extension identifier is available.  If it is, a
59	set of ioctls is available for application use.
60	
61	
62	4. API description
63	------------------
64	
65	This section describes ioctls that can be used to control kvm guests.
66	For each ioctl, the following information is provided along with a
67	description:
68	
69	  Capability: which KVM extension provides this ioctl.  Can be 'basic',
70	      which means that is will be provided by any kernel that supports
71	      API version 12 (see section 4.1), a KVM_CAP_xyz constant, which
72	      means availability needs to be checked with KVM_CHECK_EXTENSION
73	      (see section 4.4), or 'none' which means that while not all kernels
74	      support this ioctl, there's no capability bit to check its
75	      availability: for kernels that don't support the ioctl,
76	      the ioctl returns -ENOTTY.
77	
78	  Architectures: which instruction set architectures provide this ioctl.
79	      x86 includes both i386 and x86_64.
80	
81	  Type: system, vm, or vcpu.
82	
83	  Parameters: what parameters are accepted by the ioctl.
84	
85	  Returns: the return value.  General error numbers (EBADF, ENOMEM, EINVAL)
86	      are not detailed, but errors with specific meanings are.
87	
88	
89	4.1 KVM_GET_API_VERSION
90	
91	Capability: basic
92	Architectures: all
93	Type: system ioctl
94	Parameters: none
95	Returns: the constant KVM_API_VERSION (=12)
96	
97	This identifies the API version as the stable kvm API. It is not
98	expected that this number will change.  However, Linux 2.6.20 and
99	2.6.21 report earlier versions; these are not documented and not
100	supported.  Applications should refuse to run if KVM_GET_API_VERSION
101	returns a value other than 12.  If this check passes, all ioctls
102	described as 'basic' will be available.
103	
104	
105	4.2 KVM_CREATE_VM
106	
107	Capability: basic
108	Architectures: all
109	Type: system ioctl
110	Parameters: machine type identifier (KVM_VM_*)
111	Returns: a VM fd that can be used to control the new virtual machine.
112	
113	The new VM has no virtual cpus and no memory.
114	You probably want to use 0 as machine type.
115	
116	In order to create user controlled virtual machines on S390, check
117	KVM_CAP_S390_UCONTROL and use the flag KVM_VM_S390_UCONTROL as
118	privileged user (CAP_SYS_ADMIN).
119	
120	To use hardware assisted virtualization on MIPS (VZ ASE) rather than
121	the default trap & emulate implementation (which changes the virtual
122	memory layout to fit in user mode), check KVM_CAP_MIPS_VZ and use the
123	flag KVM_VM_MIPS_VZ.
124	
125	
126	4.3 KVM_GET_MSR_INDEX_LIST
127	
128	Capability: basic
129	Architectures: x86
130	Type: system
131	Parameters: struct kvm_msr_list (in/out)
132	Returns: 0 on success; -1 on error
133	Errors:
134	  E2BIG:     the msr index list is to be to fit in the array specified by
135	             the user.
136	
137	struct kvm_msr_list {
138		__u32 nmsrs; /* number of msrs in entries */
139		__u32 indices[0];
140	};
141	
142	This ioctl returns the guest msrs that are supported.  The list varies
143	by kvm version and host processor, but does not change otherwise.  The
144	user fills in the size of the indices array in nmsrs, and in return
145	kvm adjusts nmsrs to reflect the actual number of msrs and fills in
146	the indices array with their numbers.
147	
148	Note: if kvm indicates supports MCE (KVM_CAP_MCE), then the MCE bank MSRs are
149	not returned in the MSR list, as different vcpus can have a different number
150	of banks, as set via the KVM_X86_SETUP_MCE ioctl.
151	
152	
153	4.4 KVM_CHECK_EXTENSION
154	
155	Capability: basic, KVM_CAP_CHECK_EXTENSION_VM for vm ioctl
156	Architectures: all
157	Type: system ioctl, vm ioctl
158	Parameters: extension identifier (KVM_CAP_*)
159	Returns: 0 if unsupported; 1 (or some other positive integer) if supported
160	
161	The API allows the application to query about extensions to the core
162	kvm API.  Userspace passes an extension identifier (an integer) and
163	receives an integer that describes the extension availability.
164	Generally 0 means no and 1 means yes, but some extensions may report
165	additional information in the integer return value.
166	
167	Based on their initialization different VMs may have different capabilities.
168	It is thus encouraged to use the vm ioctl to query for capabilities (available
169	with KVM_CAP_CHECK_EXTENSION_VM on the vm fd)
170	
171	4.5 KVM_GET_VCPU_MMAP_SIZE
172	
173	Capability: basic
174	Architectures: all
175	Type: system ioctl
176	Parameters: none
177	Returns: size of vcpu mmap area, in bytes
178	
179	The KVM_RUN ioctl (cf.) communicates with userspace via a shared
180	memory region.  This ioctl returns the size of that region.  See the
181	KVM_RUN documentation for details.
182	
183	
184	4.6 KVM_SET_MEMORY_REGION
185	
186	Capability: basic
187	Architectures: all
188	Type: vm ioctl
189	Parameters: struct kvm_memory_region (in)
190	Returns: 0 on success, -1 on error
191	
192	This ioctl is obsolete and has been removed.
193	
194	
195	4.7 KVM_CREATE_VCPU
196	
197	Capability: basic
198	Architectures: all
199	Type: vm ioctl
200	Parameters: vcpu id (apic id on x86)
201	Returns: vcpu fd on success, -1 on error
202	
203	This API adds a vcpu to a virtual machine. No more than max_vcpus may be added.
204	The vcpu id is an integer in the range [0, max_vcpu_id).
205	
206	The recommended max_vcpus value can be retrieved using the KVM_CAP_NR_VCPUS of
207	the KVM_CHECK_EXTENSION ioctl() at run-time.
208	The maximum possible value for max_vcpus can be retrieved using the
209	KVM_CAP_MAX_VCPUS of the KVM_CHECK_EXTENSION ioctl() at run-time.
210	
211	If the KVM_CAP_NR_VCPUS does not exist, you should assume that max_vcpus is 4
212	cpus max.
213	If the KVM_CAP_MAX_VCPUS does not exist, you should assume that max_vcpus is
214	same as the value returned from KVM_CAP_NR_VCPUS.
215	
216	The maximum possible value for max_vcpu_id can be retrieved using the
217	KVM_CAP_MAX_VCPU_ID of the KVM_CHECK_EXTENSION ioctl() at run-time.
218	
219	If the KVM_CAP_MAX_VCPU_ID does not exist, you should assume that max_vcpu_id
220	is the same as the value returned from KVM_CAP_MAX_VCPUS.
221	
222	On powerpc using book3s_hv mode, the vcpus are mapped onto virtual
223	threads in one or more virtual CPU cores.  (This is because the
224	hardware requires all the hardware threads in a CPU core to be in the
225	same partition.)  The KVM_CAP_PPC_SMT capability indicates the number
226	of vcpus per virtual core (vcore).  The vcore id is obtained by
227	dividing the vcpu id by the number of vcpus per vcore.  The vcpus in a
228	given vcore will always be in the same physical core as each other
229	(though that might be a different physical core from time to time).
230	Userspace can control the threading (SMT) mode of the guest by its
231	allocation of vcpu ids.  For example, if userspace wants
232	single-threaded guest vcpus, it should make all vcpu ids be a multiple
233	of the number of vcpus per vcore.
234	
235	For virtual cpus that have been created with S390 user controlled virtual
236	machines, the resulting vcpu fd can be memory mapped at page offset
237	KVM_S390_SIE_PAGE_OFFSET in order to obtain a memory map of the virtual
238	cpu's hardware control block.
239	
240	
241	4.8 KVM_GET_DIRTY_LOG (vm ioctl)
242	
243	Capability: basic
244	Architectures: x86
245	Type: vm ioctl
246	Parameters: struct kvm_dirty_log (in/out)
247	Returns: 0 on success, -1 on error
248	
249	/* for KVM_GET_DIRTY_LOG */
250	struct kvm_dirty_log {
251		__u32 slot;
252		__u32 padding;
253		union {
254			void __user *dirty_bitmap; /* one bit per page */
255			__u64 padding;
256		};
257	};
258	
259	Given a memory slot, return a bitmap containing any pages dirtied
260	since the last call to this ioctl.  Bit 0 is the first page in the
261	memory slot.  Ensure the entire structure is cleared to avoid padding
262	issues.
263	
264	If KVM_CAP_MULTI_ADDRESS_SPACE is available, bits 16-31 specifies
265	the address space for which you want to return the dirty bitmap.
266	They must be less than the value that KVM_CHECK_EXTENSION returns for
267	the KVM_CAP_MULTI_ADDRESS_SPACE capability.
268	
269	
270	4.9 KVM_SET_MEMORY_ALIAS
271	
272	Capability: basic
273	Architectures: x86
274	Type: vm ioctl
275	Parameters: struct kvm_memory_alias (in)
276	Returns: 0 (success), -1 (error)
277	
278	This ioctl is obsolete and has been removed.
279	
280	
281	4.10 KVM_RUN
282	
283	Capability: basic
284	Architectures: all
285	Type: vcpu ioctl
286	Parameters: none
287	Returns: 0 on success, -1 on error
288	Errors:
289	  EINTR:     an unmasked signal is pending
290	
291	This ioctl is used to run a guest virtual cpu.  While there are no
292	explicit parameters, there is an implicit parameter block that can be
293	obtained by mmap()ing the vcpu fd at offset 0, with the size given by
294	KVM_GET_VCPU_MMAP_SIZE.  The parameter block is formatted as a 'struct
295	kvm_run' (see below).
296	
297	
298	4.11 KVM_GET_REGS
299	
300	Capability: basic
301	Architectures: all except ARM, arm64
302	Type: vcpu ioctl
303	Parameters: struct kvm_regs (out)
304	Returns: 0 on success, -1 on error
305	
306	Reads the general purpose registers from the vcpu.
307	
308	/* x86 */
309	struct kvm_regs {
310		/* out (KVM_GET_REGS) / in (KVM_SET_REGS) */
311		__u64 rax, rbx, rcx, rdx;
312		__u64 rsi, rdi, rsp, rbp;
313		__u64 r8,  r9,  r10, r11;
314		__u64 r12, r13, r14, r15;
315		__u64 rip, rflags;
316	};
317	
318	/* mips */
319	struct kvm_regs {
320		/* out (KVM_GET_REGS) / in (KVM_SET_REGS) */
321		__u64 gpr[32];
322		__u64 hi;
323		__u64 lo;
324		__u64 pc;
325	};
326	
327	
328	4.12 KVM_SET_REGS
329	
330	Capability: basic
331	Architectures: all except ARM, arm64
332	Type: vcpu ioctl
333	Parameters: struct kvm_regs (in)
334	Returns: 0 on success, -1 on error
335	
336	Writes the general purpose registers into the vcpu.
337	
338	See KVM_GET_REGS for the data structure.
339	
340	
341	4.13 KVM_GET_SREGS
342	
343	Capability: basic
344	Architectures: x86, ppc
345	Type: vcpu ioctl
346	Parameters: struct kvm_sregs (out)
347	Returns: 0 on success, -1 on error
348	
349	Reads special registers from the vcpu.
350	
351	/* x86 */
352	struct kvm_sregs {
353		struct kvm_segment cs, ds, es, fs, gs, ss;
354		struct kvm_segment tr, ldt;
355		struct kvm_dtable gdt, idt;
356		__u64 cr0, cr2, cr3, cr4, cr8;
357		__u64 efer;
358		__u64 apic_base;
359		__u64 interrupt_bitmap[(KVM_NR_INTERRUPTS + 63) / 64];
360	};
361	
362	/* ppc -- see arch/powerpc/include/uapi/asm/kvm.h */
363	
364	interrupt_bitmap is a bitmap of pending external interrupts.  At most
365	one bit may be set.  This interrupt has been acknowledged by the APIC
366	but not yet injected into the cpu core.
367	
368	
369	4.14 KVM_SET_SREGS
370	
371	Capability: basic
372	Architectures: x86, ppc
373	Type: vcpu ioctl
374	Parameters: struct kvm_sregs (in)
375	Returns: 0 on success, -1 on error
376	
377	Writes special registers into the vcpu.  See KVM_GET_SREGS for the
378	data structures.
379	
380	
381	4.15 KVM_TRANSLATE
382	
383	Capability: basic
384	Architectures: x86
385	Type: vcpu ioctl
386	Parameters: struct kvm_translation (in/out)
387	Returns: 0 on success, -1 on error
388	
389	Translates a virtual address according to the vcpu's current address
390	translation mode.
391	
392	struct kvm_translation {
393		/* in */
394		__u64 linear_address;
395	
396		/* out */
397		__u64 physical_address;
398		__u8  valid;
399		__u8  writeable;
400		__u8  usermode;
401		__u8  pad[5];
402	};
403	
404	
405	4.16 KVM_INTERRUPT
406	
407	Capability: basic
408	Architectures: x86, ppc, mips
409	Type: vcpu ioctl
410	Parameters: struct kvm_interrupt (in)
411	Returns: 0 on success, negative on failure.
412	
413	Queues a hardware interrupt vector to be injected.
414	
415	/* for KVM_INTERRUPT */
416	struct kvm_interrupt {
417		/* in */
418		__u32 irq;
419	};
420	
421	X86:
422	
423	Returns: 0 on success,
424		 -EEXIST if an interrupt is already enqueued
425		 -EINVAL the the irq number is invalid
426		 -ENXIO if the PIC is in the kernel
427		 -EFAULT if the pointer is invalid
428	
429	Note 'irq' is an interrupt vector, not an interrupt pin or line. This
430	ioctl is useful if the in-kernel PIC is not used.
431	
432	PPC:
433	
434	Queues an external interrupt to be injected. This ioctl is overleaded
435	with 3 different irq values:
436	
437	a) KVM_INTERRUPT_SET
438	
439	  This injects an edge type external interrupt into the guest once it's ready
440	  to receive interrupts. When injected, the interrupt is done.
441	
442	b) KVM_INTERRUPT_UNSET
443	
444	  This unsets any pending interrupt.
445	
446	  Only available with KVM_CAP_PPC_UNSET_IRQ.
447	
448	c) KVM_INTERRUPT_SET_LEVEL
449	
450	  This injects a level type external interrupt into the guest context. The
451	  interrupt stays pending until a specific ioctl with KVM_INTERRUPT_UNSET
452	  is triggered.
453	
454	  Only available with KVM_CAP_PPC_IRQ_LEVEL.
455	
456	Note that any value for 'irq' other than the ones stated above is invalid
457	and incurs unexpected behavior.
458	
459	MIPS:
460	
461	Queues an external interrupt to be injected into the virtual CPU. A negative
462	interrupt number dequeues the interrupt.
463	
464	
465	4.17 KVM_DEBUG_GUEST
466	
467	Capability: basic
468	Architectures: none
469	Type: vcpu ioctl
470	Parameters: none)
471	Returns: -1 on error
472	
473	Support for this has been removed.  Use KVM_SET_GUEST_DEBUG instead.
474	
475	
476	4.18 KVM_GET_MSRS
477	
478	Capability: basic
479	Architectures: x86
480	Type: vcpu ioctl
481	Parameters: struct kvm_msrs (in/out)
482	Returns: 0 on success, -1 on error
483	
484	Reads model-specific registers from the vcpu.  Supported msr indices can
485	be obtained using KVM_GET_MSR_INDEX_LIST.
486	
487	struct kvm_msrs {
488		__u32 nmsrs; /* number of msrs in entries */
489		__u32 pad;
490	
491		struct kvm_msr_entry entries[0];
492	};
493	
494	struct kvm_msr_entry {
495		__u32 index;
496		__u32 reserved;
497		__u64 data;
498	};
499	
500	Application code should set the 'nmsrs' member (which indicates the
501	size of the entries array) and the 'index' member of each array entry.
502	kvm will fill in the 'data' member.
503	
504	
505	4.19 KVM_SET_MSRS
506	
507	Capability: basic
508	Architectures: x86
509	Type: vcpu ioctl
510	Parameters: struct kvm_msrs (in)
511	Returns: 0 on success, -1 on error
512	
513	Writes model-specific registers to the vcpu.  See KVM_GET_MSRS for the
514	data structures.
515	
516	Application code should set the 'nmsrs' member (which indicates the
517	size of the entries array), and the 'index' and 'data' members of each
518	array entry.
519	
520	
521	4.20 KVM_SET_CPUID
522	
523	Capability: basic
524	Architectures: x86
525	Type: vcpu ioctl
526	Parameters: struct kvm_cpuid (in)
527	Returns: 0 on success, -1 on error
528	
529	Defines the vcpu responses to the cpuid instruction.  Applications
530	should use the KVM_SET_CPUID2 ioctl if available.
531	
532	
533	struct kvm_cpuid_entry {
534		__u32 function;
535		__u32 eax;
536		__u32 ebx;
537		__u32 ecx;
538		__u32 edx;
539		__u32 padding;
540	};
541	
542	/* for KVM_SET_CPUID */
543	struct kvm_cpuid {
544		__u32 nent;
545		__u32 padding;
546		struct kvm_cpuid_entry entries[0];
547	};
548	
549	
550	4.21 KVM_SET_SIGNAL_MASK
551	
552	Capability: basic
553	Architectures: all
554	Type: vcpu ioctl
555	Parameters: struct kvm_signal_mask (in)
556	Returns: 0 on success, -1 on error
557	
558	Defines which signals are blocked during execution of KVM_RUN.  This
559	signal mask temporarily overrides the threads signal mask.  Any
560	unblocked signal received (except SIGKILL and SIGSTOP, which retain
561	their traditional behaviour) will cause KVM_RUN to return with -EINTR.
562	
563	Note the signal will only be delivered if not blocked by the original
564	signal mask.
565	
566	/* for KVM_SET_SIGNAL_MASK */
567	struct kvm_signal_mask {
568		__u32 len;
569		__u8  sigset[0];
570	};
571	
572	
573	4.22 KVM_GET_FPU
574	
575	Capability: basic
576	Architectures: x86
577	Type: vcpu ioctl
578	Parameters: struct kvm_fpu (out)
579	Returns: 0 on success, -1 on error
580	
581	Reads the floating point state from the vcpu.
582	
583	/* for KVM_GET_FPU and KVM_SET_FPU */
584	struct kvm_fpu {
585		__u8  fpr[8][16];
586		__u16 fcw;
587		__u16 fsw;
588		__u8  ftwx;  /* in fxsave format */
589		__u8  pad1;
590		__u16 last_opcode;
591		__u64 last_ip;
592		__u64 last_dp;
593		__u8  xmm[16][16];
594		__u32 mxcsr;
595		__u32 pad2;
596	};
597	
598	
599	4.23 KVM_SET_FPU
600	
601	Capability: basic
602	Architectures: x86
603	Type: vcpu ioctl
604	Parameters: struct kvm_fpu (in)
605	Returns: 0 on success, -1 on error
606	
607	Writes the floating point state to the vcpu.
608	
609	/* for KVM_GET_FPU and KVM_SET_FPU */
610	struct kvm_fpu {
611		__u8  fpr[8][16];
612		__u16 fcw;
613		__u16 fsw;
614		__u8  ftwx;  /* in fxsave format */
615		__u8  pad1;
616		__u16 last_opcode;
617		__u64 last_ip;
618		__u64 last_dp;
619		__u8  xmm[16][16];
620		__u32 mxcsr;
621		__u32 pad2;
622	};
623	
624	
625	4.24 KVM_CREATE_IRQCHIP
626	
627	Capability: KVM_CAP_IRQCHIP, KVM_CAP_S390_IRQCHIP (s390)
628	Architectures: x86, ARM, arm64, s390
629	Type: vm ioctl
630	Parameters: none
631	Returns: 0 on success, -1 on error
632	
633	Creates an interrupt controller model in the kernel.
634	On x86, creates a virtual ioapic, a virtual PIC (two PICs, nested), and sets up
635	future vcpus to have a local APIC.  IRQ routing for GSIs 0-15 is set to both
636	PIC and IOAPIC; GSI 16-23 only go to the IOAPIC.
637	On ARM/arm64, a GICv2 is created. Any other GIC versions require the usage of
638	KVM_CREATE_DEVICE, which also supports creating a GICv2.  Using
639	KVM_CREATE_DEVICE is preferred over KVM_CREATE_IRQCHIP for GICv2.
640	On s390, a dummy irq routing table is created.
641	
642	Note that on s390 the KVM_CAP_S390_IRQCHIP vm capability needs to be enabled
643	before KVM_CREATE_IRQCHIP can be used.
644	
645	
646	4.25 KVM_IRQ_LINE
647	
648	Capability: KVM_CAP_IRQCHIP
649	Architectures: x86, arm, arm64
650	Type: vm ioctl
651	Parameters: struct kvm_irq_level
652	Returns: 0 on success, -1 on error
653	
654	Sets the level of a GSI input to the interrupt controller model in the kernel.
655	On some architectures it is required that an interrupt controller model has
656	been previously created with KVM_CREATE_IRQCHIP.  Note that edge-triggered
657	interrupts require the level to be set to 1 and then back to 0.
658	
659	On real hardware, interrupt pins can be active-low or active-high.  This
660	does not matter for the level field of struct kvm_irq_level: 1 always
661	means active (asserted), 0 means inactive (deasserted).
662	
663	x86 allows the operating system to program the interrupt polarity
664	(active-low/active-high) for level-triggered interrupts, and KVM used
665	to consider the polarity.  However, due to bitrot in the handling of
666	active-low interrupts, the above convention is now valid on x86 too.
667	This is signaled by KVM_CAP_X86_IOAPIC_POLARITY_IGNORED.  Userspace
668	should not present interrupts to the guest as active-low unless this
669	capability is present (or unless it is not using the in-kernel irqchip,
670	of course).
671	
672	
673	ARM/arm64 can signal an interrupt either at the CPU level, or at the
674	in-kernel irqchip (GIC), and for in-kernel irqchip can tell the GIC to
675	use PPIs designated for specific cpus.  The irq field is interpreted
676	like this:
677	
678	  bits:  | 31 ... 24 | 23  ... 16 | 15    ...    0 |
679	  field: | irq_type  | vcpu_index |     irq_id     |
680	
681	The irq_type field has the following values:
682	- irq_type[0]: out-of-kernel GIC: irq_id 0 is IRQ, irq_id 1 is FIQ
683	- irq_type[1]: in-kernel GIC: SPI, irq_id between 32 and 1019 (incl.)
684	               (the vcpu_index field is ignored)
685	- irq_type[2]: in-kernel GIC: PPI, irq_id between 16 and 31 (incl.)
686	
687	(The irq_id field thus corresponds nicely to the IRQ ID in the ARM GIC specs)
688	
689	In both cases, level is used to assert/deassert the line.
690	
691	struct kvm_irq_level {
692		union {
693			__u32 irq;     /* GSI */
694			__s32 status;  /* not used for KVM_IRQ_LEVEL */
695		};
696		__u32 level;           /* 0 or 1 */
697	};
698	
699	
700	4.26 KVM_GET_IRQCHIP
701	
702	Capability: KVM_CAP_IRQCHIP
703	Architectures: x86
704	Type: vm ioctl
705	Parameters: struct kvm_irqchip (in/out)
706	Returns: 0 on success, -1 on error
707	
708	Reads the state of a kernel interrupt controller created with
709	KVM_CREATE_IRQCHIP into a buffer provided by the caller.
710	
711	struct kvm_irqchip {
712		__u32 chip_id;  /* 0 = PIC1, 1 = PIC2, 2 = IOAPIC */
713		__u32 pad;
714	        union {
715			char dummy[512];  /* reserving space */
716			struct kvm_pic_state pic;
717			struct kvm_ioapic_state ioapic;
718		} chip;
719	};
720	
721	
722	4.27 KVM_SET_IRQCHIP
723	
724	Capability: KVM_CAP_IRQCHIP
725	Architectures: x86
726	Type: vm ioctl
727	Parameters: struct kvm_irqchip (in)
728	Returns: 0 on success, -1 on error
729	
730	Sets the state of a kernel interrupt controller created with
731	KVM_CREATE_IRQCHIP from a buffer provided by the caller.
732	
733	struct kvm_irqchip {
734		__u32 chip_id;  /* 0 = PIC1, 1 = PIC2, 2 = IOAPIC */
735		__u32 pad;
736	        union {
737			char dummy[512];  /* reserving space */
738			struct kvm_pic_state pic;
739			struct kvm_ioapic_state ioapic;
740		} chip;
741	};
742	
743	
744	4.28 KVM_XEN_HVM_CONFIG
745	
746	Capability: KVM_CAP_XEN_HVM
747	Architectures: x86
748	Type: vm ioctl
749	Parameters: struct kvm_xen_hvm_config (in)
750	Returns: 0 on success, -1 on error
751	
752	Sets the MSR that the Xen HVM guest uses to initialize its hypercall
753	page, and provides the starting address and size of the hypercall
754	blobs in userspace.  When the guest writes the MSR, kvm copies one
755	page of a blob (32- or 64-bit, depending on the vcpu mode) to guest
756	memory.
757	
758	struct kvm_xen_hvm_config {
759		__u32 flags;
760		__u32 msr;
761		__u64 blob_addr_32;
762		__u64 blob_addr_64;
763		__u8 blob_size_32;
764		__u8 blob_size_64;
765		__u8 pad2[30];
766	};
767	
768	
769	4.29 KVM_GET_CLOCK
770	
771	Capability: KVM_CAP_ADJUST_CLOCK
772	Architectures: x86
773	Type: vm ioctl
774	Parameters: struct kvm_clock_data (out)
775	Returns: 0 on success, -1 on error
776	
777	Gets the current timestamp of kvmclock as seen by the current guest. In
778	conjunction with KVM_SET_CLOCK, it is used to ensure monotonicity on scenarios
779	such as migration.
780	
781	When KVM_CAP_ADJUST_CLOCK is passed to KVM_CHECK_EXTENSION, it returns the
782	set of bits that KVM can return in struct kvm_clock_data's flag member.
783	
784	The only flag defined now is KVM_CLOCK_TSC_STABLE.  If set, the returned
785	value is the exact kvmclock value seen by all VCPUs at the instant
786	when KVM_GET_CLOCK was called.  If clear, the returned value is simply
787	CLOCK_MONOTONIC plus a constant offset; the offset can be modified
788	with KVM_SET_CLOCK.  KVM will try to make all VCPUs follow this clock,
789	but the exact value read by each VCPU could differ, because the host
790	TSC is not stable.
791	
792	struct kvm_clock_data {
793		__u64 clock;  /* kvmclock current value */
794		__u32 flags;
795		__u32 pad[9];
796	};
797	
798	
799	4.30 KVM_SET_CLOCK
800	
801	Capability: KVM_CAP_ADJUST_CLOCK
802	Architectures: x86
803	Type: vm ioctl
804	Parameters: struct kvm_clock_data (in)
805	Returns: 0 on success, -1 on error
806	
807	Sets the current timestamp of kvmclock to the value specified in its parameter.
808	In conjunction with KVM_GET_CLOCK, it is used to ensure monotonicity on scenarios
809	such as migration.
810	
811	struct kvm_clock_data {
812		__u64 clock;  /* kvmclock current value */
813		__u32 flags;
814		__u32 pad[9];
815	};
816	
817	
818	4.31 KVM_GET_VCPU_EVENTS
819	
820	Capability: KVM_CAP_VCPU_EVENTS
821	Extended by: KVM_CAP_INTR_SHADOW
822	Architectures: x86
823	Type: vm ioctl
824	Parameters: struct kvm_vcpu_event (out)
825	Returns: 0 on success, -1 on error
826	
827	Gets currently pending exceptions, interrupts, and NMIs as well as related
828	states of the vcpu.
829	
830	struct kvm_vcpu_events {
831		struct {
832			__u8 injected;
833			__u8 nr;
834			__u8 has_error_code;
835			__u8 pad;
836			__u32 error_code;
837		} exception;
838		struct {
839			__u8 injected;
840			__u8 nr;
841			__u8 soft;
842			__u8 shadow;
843		} interrupt;
844		struct {
845			__u8 injected;
846			__u8 pending;
847			__u8 masked;
848			__u8 pad;
849		} nmi;
850		__u32 sipi_vector;
851		__u32 flags;
852		struct {
853			__u8 smm;
854			__u8 pending;
855			__u8 smm_inside_nmi;
856			__u8 latched_init;
857		} smi;
858	};
859	
860	Only two fields are defined in the flags field:
861	
862	- KVM_VCPUEVENT_VALID_SHADOW may be set in the flags field to signal that
863	  interrupt.shadow contains a valid state.
864	
865	- KVM_VCPUEVENT_VALID_SMM may be set in the flags field to signal that
866	  smi contains a valid state.
867	
868	4.32 KVM_SET_VCPU_EVENTS
869	
870	Capability: KVM_CAP_VCPU_EVENTS
871	Extended by: KVM_CAP_INTR_SHADOW
872	Architectures: x86
873	Type: vm ioctl
874	Parameters: struct kvm_vcpu_event (in)
875	Returns: 0 on success, -1 on error
876	
877	Set pending exceptions, interrupts, and NMIs as well as related states of the
878	vcpu.
879	
880	See KVM_GET_VCPU_EVENTS for the data structure.
881	
882	Fields that may be modified asynchronously by running VCPUs can be excluded
883	from the update. These fields are nmi.pending, sipi_vector, smi.smm,
884	smi.pending. Keep the corresponding bits in the flags field cleared to
885	suppress overwriting the current in-kernel state. The bits are:
886	
887	KVM_VCPUEVENT_VALID_NMI_PENDING - transfer nmi.pending to the kernel
888	KVM_VCPUEVENT_VALID_SIPI_VECTOR - transfer sipi_vector
889	KVM_VCPUEVENT_VALID_SMM         - transfer the smi sub-struct.
890	
891	If KVM_CAP_INTR_SHADOW is available, KVM_VCPUEVENT_VALID_SHADOW can be set in
892	the flags field to signal that interrupt.shadow contains a valid state and
893	shall be written into the VCPU.
894	
895	KVM_VCPUEVENT_VALID_SMM can only be set if KVM_CAP_X86_SMM is available.
896	
897	
898	4.33 KVM_GET_DEBUGREGS
899	
900	Capability: KVM_CAP_DEBUGREGS
901	Architectures: x86
902	Type: vm ioctl
903	Parameters: struct kvm_debugregs (out)
904	Returns: 0 on success, -1 on error
905	
906	Reads debug registers from the vcpu.
907	
908	struct kvm_debugregs {
909		__u64 db[4];
910		__u64 dr6;
911		__u64 dr7;
912		__u64 flags;
913		__u64 reserved[9];
914	};
915	
916	
917	4.34 KVM_SET_DEBUGREGS
918	
919	Capability: KVM_CAP_DEBUGREGS
920	Architectures: x86
921	Type: vm ioctl
922	Parameters: struct kvm_debugregs (in)
923	Returns: 0 on success, -1 on error
924	
925	Writes debug registers into the vcpu.
926	
927	See KVM_GET_DEBUGREGS for the data structure. The flags field is unused
928	yet and must be cleared on entry.
929	
930	
931	4.35 KVM_SET_USER_MEMORY_REGION
932	
933	Capability: KVM_CAP_USER_MEM
934	Architectures: all
935	Type: vm ioctl
936	Parameters: struct kvm_userspace_memory_region (in)
937	Returns: 0 on success, -1 on error
938	
939	struct kvm_userspace_memory_region {
940		__u32 slot;
941		__u32 flags;
942		__u64 guest_phys_addr;
943		__u64 memory_size; /* bytes */
944		__u64 userspace_addr; /* start of the userspace allocated memory */
945	};
946	
947	/* for kvm_memory_region::flags */
948	#define KVM_MEM_LOG_DIRTY_PAGES	(1UL << 0)
949	#define KVM_MEM_READONLY	(1UL << 1)
950	
951	This ioctl allows the user to create or modify a guest physical memory
952	slot.  When changing an existing slot, it may be moved in the guest
953	physical memory space, or its flags may be modified.  It may not be
954	resized.  Slots may not overlap in guest physical address space.
955	Bits 0-15 of "slot" specifies the slot id and this value should be
956	less than the maximum number of user memory slots supported per VM.
957	The maximum allowed slots can be queried using KVM_CAP_NR_MEMSLOTS,
958	if this capability is supported by the architecture.
959	
960	If KVM_CAP_MULTI_ADDRESS_SPACE is available, bits 16-31 of "slot"
961	specifies the address space which is being modified.  They must be
962	less than the value that KVM_CHECK_EXTENSION returns for the
963	KVM_CAP_MULTI_ADDRESS_SPACE capability.  Slots in separate address spaces
964	are unrelated; the restriction on overlapping slots only applies within
965	each address space.
966	
967	Memory for the region is taken starting at the address denoted by the
968	field userspace_addr, which must point at user addressable memory for
969	the entire memory slot size.  Any object may back this memory, including
970	anonymous memory, ordinary files, and hugetlbfs.
971	
972	It is recommended that the lower 21 bits of guest_phys_addr and userspace_addr
973	be identical.  This allows large pages in the guest to be backed by large
974	pages in the host.
975	
976	The flags field supports two flags: KVM_MEM_LOG_DIRTY_PAGES and
977	KVM_MEM_READONLY.  The former can be set to instruct KVM to keep track of
978	writes to memory within the slot.  See KVM_GET_DIRTY_LOG ioctl to know how to
979	use it.  The latter can be set, if KVM_CAP_READONLY_MEM capability allows it,
980	to make a new slot read-only.  In this case, writes to this memory will be
981	posted to userspace as KVM_EXIT_MMIO exits.
982	
983	When the KVM_CAP_SYNC_MMU capability is available, changes in the backing of
984	the memory region are automatically reflected into the guest.  For example, an
985	mmap() that affects the region will be made visible immediately.  Another
986	example is madvise(MADV_DROP).
987	
988	It is recommended to use this API instead of the KVM_SET_MEMORY_REGION ioctl.
989	The KVM_SET_MEMORY_REGION does not allow fine grained control over memory
990	allocation and is deprecated.
991	
992	
993	4.36 KVM_SET_TSS_ADDR
994	
995	Capability: KVM_CAP_SET_TSS_ADDR
996	Architectures: x86
997	Type: vm ioctl
998	Parameters: unsigned long tss_address (in)
999	Returns: 0 on success, -1 on error
1000	
1001	This ioctl defines the physical address of a three-page region in the guest
1002	physical address space.  The region must be within the first 4GB of the
1003	guest physical address space and must not conflict with any memory slot
1004	or any mmio address.  The guest may malfunction if it accesses this memory
1005	region.
1006	
1007	This ioctl is required on Intel-based hosts.  This is needed on Intel hardware
1008	because of a quirk in the virtualization implementation (see the internals
1009	documentation when it pops into existence).
1010	
1011	
1012	4.37 KVM_ENABLE_CAP
1013	
1014	Capability: KVM_CAP_ENABLE_CAP, KVM_CAP_ENABLE_CAP_VM
1015	Architectures: x86 (only KVM_CAP_ENABLE_CAP_VM),
1016		       mips (only KVM_CAP_ENABLE_CAP), ppc, s390
1017	Type: vcpu ioctl, vm ioctl (with KVM_CAP_ENABLE_CAP_VM)
1018	Parameters: struct kvm_enable_cap (in)
1019	Returns: 0 on success; -1 on error
1020	
1021	+Not all extensions are enabled by default. Using this ioctl the application
1022	can enable an extension, making it available to the guest.
1023	
1024	On systems that do not support this ioctl, it always fails. On systems that
1025	do support it, it only works for extensions that are supported for enablement.
1026	
1027	To check if a capability can be enabled, the KVM_CHECK_EXTENSION ioctl should
1028	be used.
1029	
1030	struct kvm_enable_cap {
1031	       /* in */
1032	       __u32 cap;
1033	
1034	The capability that is supposed to get enabled.
1035	
1036	       __u32 flags;
1037	
1038	A bitfield indicating future enhancements. Has to be 0 for now.
1039	
1040	       __u64 args[4];
1041	
1042	Arguments for enabling a feature. If a feature needs initial values to
1043	function properly, this is the place to put them.
1044	
1045	       __u8  pad[64];
1046	};
1047	
1048	The vcpu ioctl should be used for vcpu-specific capabilities, the vm ioctl
1049	for vm-wide capabilities.
1050	
1051	4.38 KVM_GET_MP_STATE
1052	
1053	Capability: KVM_CAP_MP_STATE
1054	Architectures: x86, s390, arm, arm64
1055	Type: vcpu ioctl
1056	Parameters: struct kvm_mp_state (out)
1057	Returns: 0 on success; -1 on error
1058	
1059	struct kvm_mp_state {
1060		__u32 mp_state;
1061	};
1062	
1063	Returns the vcpu's current "multiprocessing state" (though also valid on
1064	uniprocessor guests).
1065	
1066	Possible values are:
1067	
1068	 - KVM_MP_STATE_RUNNABLE:        the vcpu is currently running [x86,arm/arm64]
1069	 - KVM_MP_STATE_UNINITIALIZED:   the vcpu is an application processor (AP)
1070	                                 which has not yet received an INIT signal [x86]
1071	 - KVM_MP_STATE_INIT_RECEIVED:   the vcpu has received an INIT signal, and is
1072	                                 now ready for a SIPI [x86]
1073	 - KVM_MP_STATE_HALTED:          the vcpu has executed a HLT instruction and
1074	                                 is waiting for an interrupt [x86]
1075	 - KVM_MP_STATE_SIPI_RECEIVED:   the vcpu has just received a SIPI (vector
1076	                                 accessible via KVM_GET_VCPU_EVENTS) [x86]
1077	 - KVM_MP_STATE_STOPPED:         the vcpu is stopped [s390,arm/arm64]
1078	 - KVM_MP_STATE_CHECK_STOP:      the vcpu is in a special error state [s390]
1079	 - KVM_MP_STATE_OPERATING:       the vcpu is operating (running or halted)
1080	                                 [s390]
1081	 - KVM_MP_STATE_LOAD:            the vcpu is in a special load/startup state
1082	                                 [s390]
1083	
1084	On x86, this ioctl is only useful after KVM_CREATE_IRQCHIP. Without an
1085	in-kernel irqchip, the multiprocessing state must be maintained by userspace on
1086	these architectures.
1087	
1088	For arm/arm64:
1089	
1090	The only states that are valid are KVM_MP_STATE_STOPPED and
1091	KVM_MP_STATE_RUNNABLE which reflect if the vcpu is paused or not.
1092	
1093	4.39 KVM_SET_MP_STATE
1094	
1095	Capability: KVM_CAP_MP_STATE
1096	Architectures: x86, s390, arm, arm64
1097	Type: vcpu ioctl
1098	Parameters: struct kvm_mp_state (in)
1099	Returns: 0 on success; -1 on error
1100	
1101	Sets the vcpu's current "multiprocessing state"; see KVM_GET_MP_STATE for
1102	arguments.
1103	
1104	On x86, this ioctl is only useful after KVM_CREATE_IRQCHIP. Without an
1105	in-kernel irqchip, the multiprocessing state must be maintained by userspace on
1106	these architectures.
1107	
1108	For arm/arm64:
1109	
1110	The only states that are valid are KVM_MP_STATE_STOPPED and
1111	KVM_MP_STATE_RUNNABLE which reflect if the vcpu should be paused or not.
1112	
1113	4.40 KVM_SET_IDENTITY_MAP_ADDR
1114	
1115	Capability: KVM_CAP_SET_IDENTITY_MAP_ADDR
1116	Architectures: x86
1117	Type: vm ioctl
1118	Parameters: unsigned long identity (in)
1119	Returns: 0 on success, -1 on error
1120	
1121	This ioctl defines the physical address of a one-page region in the guest
1122	physical address space.  The region must be within the first 4GB of the
1123	guest physical address space and must not conflict with any memory slot
1124	or any mmio address.  The guest may malfunction if it accesses this memory
1125	region.
1126	
1127	This ioctl is required on Intel-based hosts.  This is needed on Intel hardware
1128	because of a quirk in the virtualization implementation (see the internals
1129	documentation when it pops into existence).
1130	
1131	
1132	4.41 KVM_SET_BOOT_CPU_ID
1133	
1134	Capability: KVM_CAP_SET_BOOT_CPU_ID
1135	Architectures: x86
1136	Type: vm ioctl
1137	Parameters: unsigned long vcpu_id
1138	Returns: 0 on success, -1 on error
1139	
1140	Define which vcpu is the Bootstrap Processor (BSP).  Values are the same
1141	as the vcpu id in KVM_CREATE_VCPU.  If this ioctl is not called, the default
1142	is vcpu 0.
1143	
1144	
1145	4.42 KVM_GET_XSAVE
1146	
1147	Capability: KVM_CAP_XSAVE
1148	Architectures: x86
1149	Type: vcpu ioctl
1150	Parameters: struct kvm_xsave (out)
1151	Returns: 0 on success, -1 on error
1152	
1153	struct kvm_xsave {
1154		__u32 region[1024];
1155	};
1156	
1157	This ioctl would copy current vcpu's xsave struct to the userspace.
1158	
1159	
1160	4.43 KVM_SET_XSAVE
1161	
1162	Capability: KVM_CAP_XSAVE
1163	Architectures: x86
1164	Type: vcpu ioctl
1165	Parameters: struct kvm_xsave (in)
1166	Returns: 0 on success, -1 on error
1167	
1168	struct kvm_xsave {
1169		__u32 region[1024];
1170	};
1171	
1172	This ioctl would copy userspace's xsave struct to the kernel.
1173	
1174	
1175	4.44 KVM_GET_XCRS
1176	
1177	Capability: KVM_CAP_XCRS
1178	Architectures: x86
1179	Type: vcpu ioctl
1180	Parameters: struct kvm_xcrs (out)
1181	Returns: 0 on success, -1 on error
1182	
1183	struct kvm_xcr {
1184		__u32 xcr;
1185		__u32 reserved;
1186		__u64 value;
1187	};
1188	
1189	struct kvm_xcrs {
1190		__u32 nr_xcrs;
1191		__u32 flags;
1192		struct kvm_xcr xcrs[KVM_MAX_XCRS];
1193		__u64 padding[16];
1194	};
1195	
1196	This ioctl would copy current vcpu's xcrs to the userspace.
1197	
1198	
1199	4.45 KVM_SET_XCRS
1200	
1201	Capability: KVM_CAP_XCRS
1202	Architectures: x86
1203	Type: vcpu ioctl
1204	Parameters: struct kvm_xcrs (in)
1205	Returns: 0 on success, -1 on error
1206	
1207	struct kvm_xcr {
1208		__u32 xcr;
1209		__u32 reserved;
1210		__u64 value;
1211	};
1212	
1213	struct kvm_xcrs {
1214		__u32 nr_xcrs;
1215		__u32 flags;
1216		struct kvm_xcr xcrs[KVM_MAX_XCRS];
1217		__u64 padding[16];
1218	};
1219	
1220	This ioctl would set vcpu's xcr to the value userspace specified.
1221	
1222	
1223	4.46 KVM_GET_SUPPORTED_CPUID
1224	
1225	Capability: KVM_CAP_EXT_CPUID
1226	Architectures: x86
1227	Type: system ioctl
1228	Parameters: struct kvm_cpuid2 (in/out)
1229	Returns: 0 on success, -1 on error
1230	
1231	struct kvm_cpuid2 {
1232		__u32 nent;
1233		__u32 padding;
1234		struct kvm_cpuid_entry2 entries[0];
1235	};
1236	
1237	#define KVM_CPUID_FLAG_SIGNIFCANT_INDEX		BIT(0)
1238	#define KVM_CPUID_FLAG_STATEFUL_FUNC		BIT(1)
1239	#define KVM_CPUID_FLAG_STATE_READ_NEXT		BIT(2)
1240	
1241	struct kvm_cpuid_entry2 {
1242		__u32 function;
1243		__u32 index;
1244		__u32 flags;
1245		__u32 eax;
1246		__u32 ebx;
1247		__u32 ecx;
1248		__u32 edx;
1249		__u32 padding[3];
1250	};
1251	
1252	This ioctl returns x86 cpuid features which are supported by both the hardware
1253	and kvm.  Userspace can use the information returned by this ioctl to
1254	construct cpuid information (for KVM_SET_CPUID2) that is consistent with
1255	hardware, kernel, and userspace capabilities, and with user requirements (for
1256	example, the user may wish to constrain cpuid to emulate older hardware,
1257	or for feature consistency across a cluster).
1258	
1259	Userspace invokes KVM_GET_SUPPORTED_CPUID by passing a kvm_cpuid2 structure
1260	with the 'nent' field indicating the number of entries in the variable-size
1261	array 'entries'.  If the number of entries is too low to describe the cpu
1262	capabilities, an error (E2BIG) is returned.  If the number is too high,
1263	the 'nent' field is adjusted and an error (ENOMEM) is returned.  If the
1264	number is just right, the 'nent' field is adjusted to the number of valid
1265	entries in the 'entries' array, which is then filled.
1266	
1267	The entries returned are the host cpuid as returned by the cpuid instruction,
1268	with unknown or unsupported features masked out.  Some features (for example,
1269	x2apic), may not be present in the host cpu, but are exposed by kvm if it can
1270	emulate them efficiently. The fields in each entry are defined as follows:
1271	
1272	  function: the eax value used to obtain the entry
1273	  index: the ecx value used to obtain the entry (for entries that are
1274	         affected by ecx)
1275	  flags: an OR of zero or more of the following:
1276	        KVM_CPUID_FLAG_SIGNIFCANT_INDEX:
1277	           if the index field is valid
1278	        KVM_CPUID_FLAG_STATEFUL_FUNC:
1279	           if cpuid for this function returns different values for successive
1280	           invocations; there will be several entries with the same function,
1281	           all with this flag set
1282	        KVM_CPUID_FLAG_STATE_READ_NEXT:
1283	           for KVM_CPUID_FLAG_STATEFUL_FUNC entries, set if this entry is
1284	           the first entry to be read by a cpu
1285	   eax, ebx, ecx, edx: the values returned by the cpuid instruction for
1286	         this function/index combination
1287	
1288	The TSC deadline timer feature (CPUID leaf 1, ecx[24]) is always returned
1289	as false, since the feature depends on KVM_CREATE_IRQCHIP for local APIC
1290	support.  Instead it is reported via
1291	
1292	  ioctl(KVM_CHECK_EXTENSION, KVM_CAP_TSC_DEADLINE_TIMER)
1293	
1294	if that returns true and you use KVM_CREATE_IRQCHIP, or if you emulate the
1295	feature in userspace, then you can enable the feature for KVM_SET_CPUID2.
1296	
1297	
1298	4.47 KVM_PPC_GET_PVINFO
1299	
1300	Capability: KVM_CAP_PPC_GET_PVINFO
1301	Architectures: ppc
1302	Type: vm ioctl
1303	Parameters: struct kvm_ppc_pvinfo (out)
1304	Returns: 0 on success, !0 on error
1305	
1306	struct kvm_ppc_pvinfo {
1307		__u32 flags;
1308		__u32 hcall[4];
1309		__u8  pad[108];
1310	};
1311	
1312	This ioctl fetches PV specific information that need to be passed to the guest
1313	using the device tree or other means from vm context.
1314	
1315	The hcall array defines 4 instructions that make up a hypercall.
1316	
1317	If any additional field gets added to this structure later on, a bit for that
1318	additional piece of information will be set in the flags bitmap.
1319	
1320	The flags bitmap is defined as:
1321	
1322	   /* the host supports the ePAPR idle hcall
1323	   #define KVM_PPC_PVINFO_FLAGS_EV_IDLE   (1<<0)
1324	
1325	4.52 KVM_SET_GSI_ROUTING
1326	
1327	Capability: KVM_CAP_IRQ_ROUTING
1328	Architectures: x86 s390 arm arm64
1329	Type: vm ioctl
1330	Parameters: struct kvm_irq_routing (in)
1331	Returns: 0 on success, -1 on error
1332	
1333	Sets the GSI routing table entries, overwriting any previously set entries.
1334	
1335	On arm/arm64, GSI routing has the following limitation:
1336	- GSI routing does not apply to KVM_IRQ_LINE but only to KVM_IRQFD.
1337	
1338	struct kvm_irq_routing {
1339		__u32 nr;
1340		__u32 flags;
1341		struct kvm_irq_routing_entry entries[0];
1342	};
1343	
1344	No flags are specified so far, the corresponding field must be set to zero.
1345	
1346	struct kvm_irq_routing_entry {
1347		__u32 gsi;
1348		__u32 type;
1349		__u32 flags;
1350		__u32 pad;
1351		union {
1352			struct kvm_irq_routing_irqchip irqchip;
1353			struct kvm_irq_routing_msi msi;
1354			struct kvm_irq_routing_s390_adapter adapter;
1355			struct kvm_irq_routing_hv_sint hv_sint;
1356			__u32 pad[8];
1357		} u;
1358	};
1359	
1360	/* gsi routing entry types */
1361	#define KVM_IRQ_ROUTING_IRQCHIP 1
1362	#define KVM_IRQ_ROUTING_MSI 2
1363	#define KVM_IRQ_ROUTING_S390_ADAPTER 3
1364	#define KVM_IRQ_ROUTING_HV_SINT 4
1365	
1366	flags:
1367	- KVM_MSI_VALID_DEVID: used along with KVM_IRQ_ROUTING_MSI routing entry
1368	  type, specifies that the devid field contains a valid value.  The per-VM
1369	  KVM_CAP_MSI_DEVID capability advertises the requirement to provide
1370	  the device ID.  If this capability is not available, userspace should
1371	  never set the KVM_MSI_VALID_DEVID flag as the ioctl might fail.
1372	- zero otherwise
1373	
1374	struct kvm_irq_routing_irqchip {
1375		__u32 irqchip;
1376		__u32 pin;
1377	};
1378	
1379	struct kvm_irq_routing_msi {
1380		__u32 address_lo;
1381		__u32 address_hi;
1382		__u32 data;
1383		union {
1384			__u32 pad;
1385			__u32 devid;
1386		};
1387	};
1388	
1389	If KVM_MSI_VALID_DEVID is set, devid contains a unique device identifier
1390	for the device that wrote the MSI message.  For PCI, this is usually a
1391	BFD identifier in the lower 16 bits.
1392	
1393	On x86, address_hi is ignored unless the KVM_X2APIC_API_USE_32BIT_IDS
1394	feature of KVM_CAP_X2APIC_API capability is enabled.  If it is enabled,
1395	address_hi bits 31-8 provide bits 31-8 of the destination id.  Bits 7-0 of
1396	address_hi must be zero.
1397	
1398	struct kvm_irq_routing_s390_adapter {
1399		__u64 ind_addr;
1400		__u64 summary_addr;
1401		__u64 ind_offset;
1402		__u32 summary_offset;
1403		__u32 adapter_id;
1404	};
1405	
1406	struct kvm_irq_routing_hv_sint {
1407		__u32 vcpu;
1408		__u32 sint;
1409	};
1410	
1411	
1412	4.55 KVM_SET_TSC_KHZ
1413	
1414	Capability: KVM_CAP_TSC_CONTROL
1415	Architectures: x86
1416	Type: vcpu ioctl
1417	Parameters: virtual tsc_khz
1418	Returns: 0 on success, -1 on error
1419	
1420	Specifies the tsc frequency for the virtual machine. The unit of the
1421	frequency is KHz.
1422	
1423	
1424	4.56 KVM_GET_TSC_KHZ
1425	
1426	Capability: KVM_CAP_GET_TSC_KHZ
1427	Architectures: x86
1428	Type: vcpu ioctl
1429	Parameters: none
1430	Returns: virtual tsc-khz on success, negative value on error
1431	
1432	Returns the tsc frequency of the guest. The unit of the return value is
1433	KHz. If the host has unstable tsc this ioctl returns -EIO instead as an
1434	error.
1435	
1436	
1437	4.57 KVM_GET_LAPIC
1438	
1439	Capability: KVM_CAP_IRQCHIP
1440	Architectures: x86
1441	Type: vcpu ioctl
1442	Parameters: struct kvm_lapic_state (out)
1443	Returns: 0 on success, -1 on error
1444	
1445	#define KVM_APIC_REG_SIZE 0x400
1446	struct kvm_lapic_state {
1447		char regs[KVM_APIC_REG_SIZE];
1448	};
1449	
1450	Reads the Local APIC registers and copies them into the input argument.  The
1451	data format and layout are the same as documented in the architecture manual.
1452	
1453	If KVM_X2APIC_API_USE_32BIT_IDS feature of KVM_CAP_X2APIC_API is
1454	enabled, then the format of APIC_ID register depends on the APIC mode
1455	(reported by MSR_IA32_APICBASE) of its VCPU.  x2APIC stores APIC ID in
1456	the APIC_ID register (bytes 32-35).  xAPIC only allows an 8-bit APIC ID
1457	which is stored in bits 31-24 of the APIC register, or equivalently in
1458	byte 35 of struct kvm_lapic_state's regs field.  KVM_GET_LAPIC must then
1459	be called after MSR_IA32_APICBASE has been set with KVM_SET_MSR.
1460	
1461	If KVM_X2APIC_API_USE_32BIT_IDS feature is disabled, struct kvm_lapic_state
1462	always uses xAPIC format.
1463	
1464	
1465	4.58 KVM_SET_LAPIC
1466	
1467	Capability: KVM_CAP_IRQCHIP
1468	Architectures: x86
1469	Type: vcpu ioctl
1470	Parameters: struct kvm_lapic_state (in)
1471	Returns: 0 on success, -1 on error
1472	
1473	#define KVM_APIC_REG_SIZE 0x400
1474	struct kvm_lapic_state {
1475		char regs[KVM_APIC_REG_SIZE];
1476	};
1477	
1478	Copies the input argument into the Local APIC registers.  The data format
1479	and layout are the same as documented in the architecture manual.
1480	
1481	The format of the APIC ID register (bytes 32-35 of struct kvm_lapic_state's
1482	regs field) depends on the state of the KVM_CAP_X2APIC_API capability.
1483	See the note in KVM_GET_LAPIC.
1484	
1485	
1486	4.59 KVM_IOEVENTFD
1487	
1488	Capability: KVM_CAP_IOEVENTFD
1489	Architectures: all
1490	Type: vm ioctl
1491	Parameters: struct kvm_ioeventfd (in)
1492	Returns: 0 on success, !0 on error
1493	
1494	This ioctl attaches or detaches an ioeventfd to a legal pio/mmio address
1495	within the guest.  A guest write in the registered address will signal the
1496	provided event instead of triggering an exit.
1497	
1498	struct kvm_ioeventfd {
1499		__u64 datamatch;
1500		__u64 addr;        /* legal pio/mmio address */
1501		__u32 len;         /* 0, 1, 2, 4, or 8 bytes    */
1502		__s32 fd;
1503		__u32 flags;
1504		__u8  pad[36];
1505	};
1506	
1507	For the special case of virtio-ccw devices on s390, the ioevent is matched
1508	to a subchannel/virtqueue tuple instead.
1509	
1510	The following flags are defined:
1511	
1512	#define KVM_IOEVENTFD_FLAG_DATAMATCH (1 << kvm_ioeventfd_flag_nr_datamatch)
1513	#define KVM_IOEVENTFD_FLAG_PIO       (1 << kvm_ioeventfd_flag_nr_pio)
1514	#define KVM_IOEVENTFD_FLAG_DEASSIGN  (1 << kvm_ioeventfd_flag_nr_deassign)
1515	#define KVM_IOEVENTFD_FLAG_VIRTIO_CCW_NOTIFY \
1516		(1 << kvm_ioeventfd_flag_nr_virtio_ccw_notify)
1517	
1518	If datamatch flag is set, the event will be signaled only if the written value
1519	to the registered address is equal to datamatch in struct kvm_ioeventfd.
1520	
1521	For virtio-ccw devices, addr contains the subchannel id and datamatch the
1522	virtqueue index.
1523	
1524	With KVM_CAP_IOEVENTFD_ANY_LENGTH, a zero length ioeventfd is allowed, and
1525	the kernel will ignore the length of guest write and may get a faster vmexit.
1526	The speedup may only apply to specific architectures, but the ioeventfd will
1527	work anyway.
1528	
1529	4.60 KVM_DIRTY_TLB
1530	
1531	Capability: KVM_CAP_SW_TLB
1532	Architectures: ppc
1533	Type: vcpu ioctl
1534	Parameters: struct kvm_dirty_tlb (in)
1535	Returns: 0 on success, -1 on error
1536	
1537	struct kvm_dirty_tlb {
1538		__u64 bitmap;
1539		__u32 num_dirty;
1540	};
1541	
1542	This must be called whenever userspace has changed an entry in the shared
1543	TLB, prior to calling KVM_RUN on the associated vcpu.
1544	
1545	The "bitmap" field is the userspace address of an array.  This array
1546	consists of a number of bits, equal to the total number of TLB entries as
1547	determined by the last successful call to KVM_CONFIG_TLB, rounded up to the
1548	nearest multiple of 64.
1549	
1550	Each bit corresponds to one TLB entry, ordered the same as in the shared TLB
1551	array.
1552	
1553	The array is little-endian: the bit 0 is the least significant bit of the
1554	first byte, bit 8 is the least significant bit of the second byte, etc.
1555	This avoids any complications with differing word sizes.
1556	
1557	The "num_dirty" field is a performance hint for KVM to determine whether it
1558	should skip processing the bitmap and just invalidate everything.  It must
1559	be set to the number of set bits in the bitmap.
1560	
1561	
1562	4.62 KVM_CREATE_SPAPR_TCE
1563	
1564	Capability: KVM_CAP_SPAPR_TCE
1565	Architectures: powerpc
1566	Type: vm ioctl
1567	Parameters: struct kvm_create_spapr_tce (in)
1568	Returns: file descriptor for manipulating the created TCE table
1569	
1570	This creates a virtual TCE (translation control entry) table, which
1571	is an IOMMU for PAPR-style virtual I/O.  It is used to translate
1572	logical addresses used in virtual I/O into guest physical addresses,
1573	and provides a scatter/gather capability for PAPR virtual I/O.
1574	
1575	/* for KVM_CAP_SPAPR_TCE */
1576	struct kvm_create_spapr_tce {
1577		__u64 liobn;
1578		__u32 window_size;
1579	};
1580	
1581	The liobn field gives the logical IO bus number for which to create a
1582	TCE table.  The window_size field specifies the size of the DMA window
1583	which this TCE table will translate - the table will contain one 64
1584	bit TCE entry for every 4kiB of the DMA window.
1585	
1586	When the guest issues an H_PUT_TCE hcall on a liobn for which a TCE
1587	table has been created using this ioctl(), the kernel will handle it
1588	in real mode, updating the TCE table.  H_PUT_TCE calls for other
1589	liobns will cause a vm exit and must be handled by userspace.
1590	
1591	The return value is a file descriptor which can be passed to mmap(2)
1592	to map the created TCE table into userspace.  This lets userspace read
1593	the entries written by kernel-handled H_PUT_TCE calls, and also lets
1594	userspace update the TCE table directly which is useful in some
1595	circumstances.
1596	
1597	
1598	4.63 KVM_ALLOCATE_RMA
1599	
1600	Capability: KVM_CAP_PPC_RMA
1601	Architectures: powerpc
1602	Type: vm ioctl
1603	Parameters: struct kvm_allocate_rma (out)
1604	Returns: file descriptor for mapping the allocated RMA
1605	
1606	This allocates a Real Mode Area (RMA) from the pool allocated at boot
1607	time by the kernel.  An RMA is a physically-contiguous, aligned region
1608	of memory used on older POWER processors to provide the memory which
1609	will be accessed by real-mode (MMU off) accesses in a KVM guest.
1610	POWER processors support a set of sizes for the RMA that usually
1611	includes 64MB, 128MB, 256MB and some larger powers of two.
1612	
1613	/* for KVM_ALLOCATE_RMA */
1614	struct kvm_allocate_rma {
1615		__u64 rma_size;
1616	};
1617	
1618	The return value is a file descriptor which can be passed to mmap(2)
1619	to map the allocated RMA into userspace.  The mapped area can then be
1620	passed to the KVM_SET_USER_MEMORY_REGION ioctl to establish it as the
1621	RMA for a virtual machine.  The size of the RMA in bytes (which is
1622	fixed at host kernel boot time) is returned in the rma_size field of
1623	the argument structure.
1624	
1625	The KVM_CAP_PPC_RMA capability is 1 or 2 if the KVM_ALLOCATE_RMA ioctl
1626	is supported; 2 if the processor requires all virtual machines to have
1627	an RMA, or 1 if the processor can use an RMA but doesn't require it,
1628	because it supports the Virtual RMA (VRMA) facility.
1629	
1630	
1631	4.64 KVM_NMI
1632	
1633	Capability: KVM_CAP_USER_NMI
1634	Architectures: x86
1635	Type: vcpu ioctl
1636	Parameters: none
1637	Returns: 0 on success, -1 on error
1638	
1639	Queues an NMI on the thread's vcpu.  Note this is well defined only
1640	when KVM_CREATE_IRQCHIP has not been called, since this is an interface
1641	between the virtual cpu core and virtual local APIC.  After KVM_CREATE_IRQCHIP
1642	has been called, this interface is completely emulated within the kernel.
1643	
1644	To use this to emulate the LINT1 input with KVM_CREATE_IRQCHIP, use the
1645	following algorithm:
1646	
1647	  - pause the vcpu
1648	  - read the local APIC's state (KVM_GET_LAPIC)
1649	  - check whether changing LINT1 will queue an NMI (see the LVT entry for LINT1)
1650	  - if so, issue KVM_NMI
1651	  - resume the vcpu
1652	
1653	Some guests configure the LINT1 NMI input to cause a panic, aiding in
1654	debugging.
1655	
1656	
1657	4.65 KVM_S390_UCAS_MAP
1658	
1659	Capability: KVM_CAP_S390_UCONTROL
1660	Architectures: s390
1661	Type: vcpu ioctl
1662	Parameters: struct kvm_s390_ucas_mapping (in)
1663	Returns: 0 in case of success
1664	
1665	The parameter is defined like this:
1666		struct kvm_s390_ucas_mapping {
1667			__u64 user_addr;
1668			__u64 vcpu_addr;
1669			__u64 length;
1670		};
1671	
1672	This ioctl maps the memory at "user_addr" with the length "length" to
1673	the vcpu's address space starting at "vcpu_addr". All parameters need to
1674	be aligned by 1 megabyte.
1675	
1676	
1677	4.66 KVM_S390_UCAS_UNMAP
1678	
1679	Capability: KVM_CAP_S390_UCONTROL
1680	Architectures: s390
1681	Type: vcpu ioctl
1682	Parameters: struct kvm_s390_ucas_mapping (in)
1683	Returns: 0 in case of success
1684	
1685	The parameter is defined like this:
1686		struct kvm_s390_ucas_mapping {
1687			__u64 user_addr;
1688			__u64 vcpu_addr;
1689			__u64 length;
1690		};
1691	
1692	This ioctl unmaps the memory in the vcpu's address space starting at
1693	"vcpu_addr" with the length "length". The field "user_addr" is ignored.
1694	All parameters need to be aligned by 1 megabyte.
1695	
1696	
1697	4.67 KVM_S390_VCPU_FAULT
1698	
1699	Capability: KVM_CAP_S390_UCONTROL
1700	Architectures: s390
1701	Type: vcpu ioctl
1702	Parameters: vcpu absolute address (in)
1703	Returns: 0 in case of success
1704	
1705	This call creates a page table entry on the virtual cpu's address space
1706	(for user controlled virtual machines) or the virtual machine's address
1707	space (for regular virtual machines). This only works for minor faults,
1708	thus it's recommended to access subject memory page via the user page
1709	table upfront. This is useful to handle validity intercepts for user
1710	controlled virtual machines to fault in the virtual cpu's lowcore pages
1711	prior to calling the KVM_RUN ioctl.
1712	
1713	
1714	4.68 KVM_SET_ONE_REG
1715	
1716	Capability: KVM_CAP_ONE_REG
1717	Architectures: all
1718	Type: vcpu ioctl
1719	Parameters: struct kvm_one_reg (in)
1720	Returns: 0 on success, negative value on failure
1721	
1722	struct kvm_one_reg {
1723	       __u64 id;
1724	       __u64 addr;
1725	};
1726	
1727	Using this ioctl, a single vcpu register can be set to a specific value
1728	defined by user space with the passed in struct kvm_one_reg, where id
1729	refers to the register identifier as described below and addr is a pointer
1730	to a variable with the respective size. There can be architecture agnostic
1731	and architecture specific registers. Each have their own range of operation
1732	and their own constants and width. To keep track of the implemented
1733	registers, find a list below:
1734	
1735	  Arch  |           Register            | Width (bits)
1736	        |                               |
1737	  PPC   | KVM_REG_PPC_HIOR              | 64
1738	  PPC   | KVM_REG_PPC_IAC1              | 64
1739	  PPC   | KVM_REG_PPC_IAC2              | 64
1740	  PPC   | KVM_REG_PPC_IAC3              | 64
1741	  PPC   | KVM_REG_PPC_IAC4              | 64
1742	  PPC   | KVM_REG_PPC_DAC1              | 64
1743	  PPC   | KVM_REG_PPC_DAC2              | 64
1744	  PPC   | KVM_REG_PPC_DABR              | 64
1745	  PPC   | KVM_REG_PPC_DSCR              | 64
1746	  PPC   | KVM_REG_PPC_PURR              | 64
1747	  PPC   | KVM_REG_PPC_SPURR             | 64
1748	  PPC   | KVM_REG_PPC_DAR               | 64
1749	  PPC   | KVM_REG_PPC_DSISR             | 32
1750	  PPC   | KVM_REG_PPC_AMR               | 64
1751	  PPC   | KVM_REG_PPC_UAMOR             | 64
1752	  PPC   | KVM_REG_PPC_MMCR0             | 64
1753	  PPC   | KVM_REG_PPC_MMCR1             | 64
1754	  PPC   | KVM_REG_PPC_MMCRA             | 64
1755	  PPC   | KVM_REG_PPC_MMCR2             | 64
1756	  PPC   | KVM_REG_PPC_MMCRS             | 64
1757	  PPC   | KVM_REG_PPC_SIAR              | 64
1758	  PPC   | KVM_REG_PPC_SDAR              | 64
1759	  PPC   | KVM_REG_PPC_SIER              | 64
1760	  PPC   | KVM_REG_PPC_PMC1              | 32
1761	  PPC   | KVM_REG_PPC_PMC2              | 32
1762	  PPC   | KVM_REG_PPC_PMC3              | 32
1763	  PPC   | KVM_REG_PPC_PMC4              | 32
1764	  PPC   | KVM_REG_PPC_PMC5              | 32
1765	  PPC   | KVM_REG_PPC_PMC6              | 32
1766	  PPC   | KVM_REG_PPC_PMC7              | 32
1767	  PPC   | KVM_REG_PPC_PMC8              | 32
1768	  PPC   | KVM_REG_PPC_FPR0              | 64
1769	          ...
1770	  PPC   | KVM_REG_PPC_FPR31             | 64
1771	  PPC   | KVM_REG_PPC_VR0               | 128
1772	          ...
1773	  PPC   | KVM_REG_PPC_VR31              | 128
1774	  PPC   | KVM_REG_PPC_VSR0              | 128
1775	          ...
1776	  PPC   | KVM_REG_PPC_VSR31             | 128
1777	  PPC   | KVM_REG_PPC_FPSCR             | 64
1778	  PPC   | KVM_REG_PPC_VSCR              | 32
1779	  PPC   | KVM_REG_PPC_VPA_ADDR          | 64
1780	  PPC   | KVM_REG_PPC_VPA_SLB           | 128
1781	  PPC   | KVM_REG_PPC_VPA_DTL           | 128
1782	  PPC   | KVM_REG_PPC_EPCR              | 32
1783	  PPC   | KVM_REG_PPC_EPR               | 32
1784	  PPC   | KVM_REG_PPC_TCR               | 32
1785	  PPC   | KVM_REG_PPC_TSR               | 32
1786	  PPC   | KVM_REG_PPC_OR_TSR            | 32
1787	  PPC   | KVM_REG_PPC_CLEAR_TSR         | 32
1788	  PPC   | KVM_REG_PPC_MAS0              | 32
1789	  PPC   | KVM_REG_PPC_MAS1              | 32
1790	  PPC   | KVM_REG_PPC_MAS2              | 64
1791	  PPC   | KVM_REG_PPC_MAS7_3            | 64
1792	  PPC   | KVM_REG_PPC_MAS4              | 32
1793	  PPC   | KVM_REG_PPC_MAS6              | 32
1794	  PPC   | KVM_REG_PPC_MMUCFG            | 32
1795	  PPC   | KVM_REG_PPC_TLB0CFG           | 32
1796	  PPC   | KVM_REG_PPC_TLB1CFG           | 32
1797	  PPC   | KVM_REG_PPC_TLB2CFG           | 32
1798	  PPC   | KVM_REG_PPC_TLB3CFG           | 32
1799	  PPC   | KVM_REG_PPC_TLB0PS            | 32
1800	  PPC   | KVM_REG_PPC_TLB1PS            | 32
1801	  PPC   | KVM_REG_PPC_TLB2PS            | 32
1802	  PPC   | KVM_REG_PPC_TLB3PS            | 32
1803	  PPC   | KVM_REG_PPC_EPTCFG            | 32
1804	  PPC   | KVM_REG_PPC_ICP_STATE         | 64
1805	  PPC   | KVM_REG_PPC_TB_OFFSET         | 64
1806	  PPC   | KVM_REG_PPC_SPMC1             | 32
1807	  PPC   | KVM_REG_PPC_SPMC2             | 32
1808	  PPC   | KVM_REG_PPC_IAMR              | 64
1809	  PPC   | KVM_REG_PPC_TFHAR             | 64
1810	  PPC   | KVM_REG_PPC_TFIAR             | 64
1811	  PPC   | KVM_REG_PPC_TEXASR            | 64
1812	  PPC   | KVM_REG_PPC_FSCR              | 64
1813	  PPC   | KVM_REG_PPC_PSPB              | 32
1814	  PPC   | KVM_REG_PPC_EBBHR             | 64
1815	  PPC   | KVM_REG_PPC_EBBRR             | 64
1816	  PPC   | KVM_REG_PPC_BESCR             | 64
1817	  PPC   | KVM_REG_PPC_TAR               | 64
1818	  PPC   | KVM_REG_PPC_DPDES             | 64
1819	  PPC   | KVM_REG_PPC_DAWR              | 64
1820	  PPC   | KVM_REG_PPC_DAWRX             | 64
1821	  PPC   | KVM_REG_PPC_CIABR             | 64
1822	  PPC   | KVM_REG_PPC_IC                | 64
1823	  PPC   | KVM_REG_PPC_VTB               | 64
1824	  PPC   | KVM_REG_PPC_CSIGR             | 64
1825	  PPC   | KVM_REG_PPC_TACR              | 64
1826	  PPC   | KVM_REG_PPC_TCSCR             | 64
1827	  PPC   | KVM_REG_PPC_PID               | 64
1828	  PPC   | KVM_REG_PPC_ACOP              | 64
1829	  PPC   | KVM_REG_PPC_VRSAVE            | 32
1830	  PPC   | KVM_REG_PPC_LPCR              | 32
1831	  PPC   | KVM_REG_PPC_LPCR_64           | 64
1832	  PPC   | KVM_REG_PPC_PPR               | 64
1833	  PPC   | KVM_REG_PPC_ARCH_COMPAT       | 32
1834	  PPC   | KVM_REG_PPC_DABRX             | 32
1835	  PPC   | KVM_REG_PPC_WORT              | 64
1836	  PPC	| KVM_REG_PPC_SPRG9             | 64
1837	  PPC	| KVM_REG_PPC_DBSR              | 32
1838	  PPC   | KVM_REG_PPC_TIDR              | 64
1839	  PPC   | KVM_REG_PPC_PSSCR             | 64
1840	  PPC   | KVM_REG_PPC_TM_GPR0           | 64
1841	          ...
1842	  PPC   | KVM_REG_PPC_TM_GPR31          | 64
1843	  PPC   | KVM_REG_PPC_TM_VSR0           | 128
1844	          ...
1845	  PPC   | KVM_REG_PPC_TM_VSR63          | 128
1846	  PPC   | KVM_REG_PPC_TM_CR             | 64
1847	  PPC   | KVM_REG_PPC_TM_LR             | 64
1848	  PPC   | KVM_REG_PPC_TM_CTR            | 64
1849	  PPC   | KVM_REG_PPC_TM_FPSCR          | 64
1850	  PPC   | KVM_REG_PPC_TM_AMR            | 64
1851	  PPC   | KVM_REG_PPC_TM_PPR            | 64
1852	  PPC   | KVM_REG_PPC_TM_VRSAVE         | 64
1853	  PPC   | KVM_REG_PPC_TM_VSCR           | 32
1854	  PPC   | KVM_REG_PPC_TM_DSCR           | 64
1855	  PPC   | KVM_REG_PPC_TM_TAR            | 64
1856	  PPC   | KVM_REG_PPC_TM_XER            | 64
1857	        |                               |
1858	  MIPS  | KVM_REG_MIPS_R0               | 64
1859	          ...
1860	  MIPS  | KVM_REG_MIPS_R31              | 64
1861	  MIPS  | KVM_REG_MIPS_HI               | 64
1862	  MIPS  | KVM_REG_MIPS_LO               | 64
1863	  MIPS  | KVM_REG_MIPS_PC               | 64
1864	  MIPS  | KVM_REG_MIPS_CP0_INDEX        | 32
1865	  MIPS  | KVM_REG_MIPS_CP0_ENTRYLO0     | 64
1866	  MIPS  | KVM_REG_MIPS_CP0_ENTRYLO1     | 64
1867	  MIPS  | KVM_REG_MIPS_CP0_CONTEXT      | 64
1868	  MIPS  | KVM_REG_MIPS_CP0_CONTEXTCONFIG| 32
1869	  MIPS  | KVM_REG_MIPS_CP0_USERLOCAL    | 64
1870	  MIPS  | KVM_REG_MIPS_CP0_XCONTEXTCONFIG| 64
1871	  MIPS  | KVM_REG_MIPS_CP0_PAGEMASK     | 32
1872	  MIPS  | KVM_REG_MIPS_CP0_PAGEGRAIN    | 32
1873	  MIPS  | KVM_REG_MIPS_CP0_SEGCTL0      | 64
1874	  MIPS  | KVM_REG_MIPS_CP0_SEGCTL1      | 64
1875	  MIPS  | KVM_REG_MIPS_CP0_SEGCTL2      | 64
1876	  MIPS  | KVM_REG_MIPS_CP0_PWBASE       | 64
1877	  MIPS  | KVM_REG_MIPS_CP0_PWFIELD      | 64
1878	  MIPS  | KVM_REG_MIPS_CP0_PWSIZE       | 64
1879	  MIPS  | KVM_REG_MIPS_CP0_WIRED        | 32
1880	  MIPS  | KVM_REG_MIPS_CP0_PWCTL        | 32
1881	  MIPS  | KVM_REG_MIPS_CP0_HWRENA       | 32
1882	  MIPS  | KVM_REG_MIPS_CP0_BADVADDR     | 64
1883	  MIPS  | KVM_REG_MIPS_CP0_BADINSTR     | 32
1884	  MIPS  | KVM_REG_MIPS_CP0_BADINSTRP    | 32
1885	  MIPS  | KVM_REG_MIPS_CP0_COUNT        | 32
1886	  MIPS  | KVM_REG_MIPS_CP0_ENTRYHI      | 64
1887	  MIPS  | KVM_REG_MIPS_CP0_COMPARE      | 32
1888	  MIPS  | KVM_REG_MIPS_CP0_STATUS       | 32
1889	  MIPS  | KVM_REG_MIPS_CP0_INTCTL       | 32
1890	  MIPS  | KVM_REG_MIPS_CP0_CAUSE        | 32
1891	  MIPS  | KVM_REG_MIPS_CP0_EPC          | 64
1892	  MIPS  | KVM_REG_MIPS_CP0_PRID         | 32
1893	  MIPS  | KVM_REG_MIPS_CP0_EBASE        | 64
1894	  MIPS  | KVM_REG_MIPS_CP0_CONFIG       | 32
1895	  MIPS  | KVM_REG_MIPS_CP0_CONFIG1      | 32
1896	  MIPS  | KVM_REG_MIPS_CP0_CONFIG2      | 32
1897	  MIPS  | KVM_REG_MIPS_CP0_CONFIG3      | 32
1898	  MIPS  | KVM_REG_MIPS_CP0_CONFIG4      | 32
1899	  MIPS  | KVM_REG_MIPS_CP0_CONFIG5      | 32
1900	  MIPS  | KVM_REG_MIPS_CP0_CONFIG7      | 32
1901	  MIPS  | KVM_REG_MIPS_CP0_XCONTEXT     | 64
1902	  MIPS  | KVM_REG_MIPS_CP0_ERROREPC     | 64
1903	  MIPS  | KVM_REG_MIPS_CP0_KSCRATCH1    | 64
1904	  MIPS  | KVM_REG_MIPS_CP0_KSCRATCH2    | 64
1905	  MIPS  | KVM_REG_MIPS_CP0_KSCRATCH3    | 64
1906	  MIPS  | KVM_REG_MIPS_CP0_KSCRATCH4    | 64
1907	  MIPS  | KVM_REG_MIPS_CP0_KSCRATCH5    | 64
1908	  MIPS  | KVM_REG_MIPS_CP0_KSCRATCH6    | 64
1909	  MIPS  | KVM_REG_MIPS_CP0_MAAR(0..63)  | 64
1910	  MIPS  | KVM_REG_MIPS_COUNT_CTL        | 64
1911	  MIPS  | KVM_REG_MIPS_COUNT_RESUME     | 64
1912	  MIPS  | KVM_REG_MIPS_COUNT_HZ         | 64
1913	  MIPS  | KVM_REG_MIPS_FPR_32(0..31)    | 32
1914	  MIPS  | KVM_REG_MIPS_FPR_64(0..31)    | 64
1915	  MIPS  | KVM_REG_MIPS_VEC_128(0..31)   | 128
1916	  MIPS  | KVM_REG_MIPS_FCR_IR           | 32
1917	  MIPS  | KVM_REG_MIPS_FCR_CSR          | 32
1918	  MIPS  | KVM_REG_MIPS_MSA_IR           | 32
1919	  MIPS  | KVM_REG_MIPS_MSA_CSR          | 32
1920	
1921	ARM registers are mapped using the lower 32 bits.  The upper 16 of that
1922	is the register group type, or coprocessor number:
1923	
1924	ARM core registers have the following id bit patterns:
1925	  0x4020 0000 0010 <index into the kvm_regs struct:16>
1926	
1927	ARM 32-bit CP15 registers have the following id bit patterns:
1928	  0x4020 0000 000F <zero:1> <crn:4> <crm:4> <opc1:4> <opc2:3>
1929	
1930	ARM 64-bit CP15 registers have the following id bit patterns:
1931	  0x4030 0000 000F <zero:1> <zero:4> <crm:4> <opc1:4> <zero:3>
1932	
1933	ARM CCSIDR registers are demultiplexed by CSSELR value:
1934	  0x4020 0000 0011 00 <csselr:8>
1935	
1936	ARM 32-bit VFP control registers have the following id bit patterns:
1937	  0x4020 0000 0012 1 <regno:12>
1938	
1939	ARM 64-bit FP registers have the following id bit patterns:
1940	  0x4030 0000 0012 0 <regno:12>
1941	
1942	
1943	arm64 registers are mapped using the lower 32 bits. The upper 16 of
1944	that is the register group type, or coprocessor number:
1945	
1946	arm64 core/FP-SIMD registers have the following id bit patterns. Note
1947	that the size of the access is variable, as the kvm_regs structure
1948	contains elements ranging from 32 to 128 bits. The index is a 32bit
1949	value in the kvm_regs structure seen as a 32bit array.
1950	  0x60x0 0000 0010 <index into the kvm_regs struct:16>
1951	
1952	arm64 CCSIDR registers are demultiplexed by CSSELR value:
1953	  0x6020 0000 0011 00 <csselr:8>
1954	
1955	arm64 system registers have the following id bit patterns:
1956	  0x6030 0000 0013 <op0:2> <op1:3> <crn:4> <crm:4> <op2:3>
1957	
1958	
1959	MIPS registers are mapped using the lower 32 bits.  The upper 16 of that is
1960	the register group type:
1961	
1962	MIPS core registers (see above) have the following id bit patterns:
1963	  0x7030 0000 0000 <reg:16>
1964	
1965	MIPS CP0 registers (see KVM_REG_MIPS_CP0_* above) have the following id bit
1966	patterns depending on whether they're 32-bit or 64-bit registers:
1967	  0x7020 0000 0001 00 <reg:5> <sel:3>   (32-bit)
1968	  0x7030 0000 0001 00 <reg:5> <sel:3>   (64-bit)
1969	
1970	Note: KVM_REG_MIPS_CP0_ENTRYLO0 and KVM_REG_MIPS_CP0_ENTRYLO1 are the MIPS64
1971	versions of the EntryLo registers regardless of the word size of the host
1972	hardware, host kernel, guest, and whether XPA is present in the guest, i.e.
1973	with the RI and XI bits (if they exist) in bits 63 and 62 respectively, and
1974	the PFNX field starting at bit 30.
1975	
1976	MIPS MAARs (see KVM_REG_MIPS_CP0_MAAR(*) above) have the following id bit
1977	patterns:
1978	  0x7030 0000 0001 01 <reg:8>
1979	
1980	MIPS KVM control registers (see above) have the following id bit patterns:
1981	  0x7030 0000 0002 <reg:16>
1982	
1983	MIPS FPU registers (see KVM_REG_MIPS_FPR_{32,64}() above) have the following
1984	id bit patterns depending on the size of the register being accessed. They are
1985	always accessed according to the current guest FPU mode (Status.FR and
1986	Config5.FRE), i.e. as the guest would see them, and they become unpredictable
1987	if the guest FPU mode is changed. MIPS SIMD Architecture (MSA) vector
1988	registers (see KVM_REG_MIPS_VEC_128() above) have similar patterns as they
1989	overlap the FPU registers:
1990	  0x7020 0000 0003 00 <0:3> <reg:5> (32-bit FPU registers)
1991	  0x7030 0000 0003 00 <0:3> <reg:5> (64-bit FPU registers)
1992	  0x7040 0000 0003 00 <0:3> <reg:5> (128-bit MSA vector registers)
1993	
1994	MIPS FPU control registers (see KVM_REG_MIPS_FCR_{IR,CSR} above) have the
1995	following id bit patterns:
1996	  0x7020 0000 0003 01 <0:3> <reg:5>
1997	
1998	MIPS MSA control registers (see KVM_REG_MIPS_MSA_{IR,CSR} above) have the
1999	following id bit patterns:
2000	  0x7020 0000 0003 02 <0:3> <reg:5>
2001	
2002	
2003	4.69 KVM_GET_ONE_REG
2004	
2005	Capability: KVM_CAP_ONE_REG
2006	Architectures: all
2007	Type: vcpu ioctl
2008	Parameters: struct kvm_one_reg (in and out)
2009	Returns: 0 on success, negative value on failure
2010	
2011	This ioctl allows to receive the value of a single register implemented
2012	in a vcpu. The register to read is indicated by the "id" field of the
2013	kvm_one_reg struct passed in. On success, the register value can be found
2014	at the memory location pointed to by "addr".
2015	
2016	The list of registers accessible using this interface is identical to the
2017	list in 4.68.
2018	
2019	
2020	4.70 KVM_KVMCLOCK_CTRL
2021	
2022	Capability: KVM_CAP_KVMCLOCK_CTRL
2023	Architectures: Any that implement pvclocks (currently x86 only)
2024	Type: vcpu ioctl
2025	Parameters: None
2026	Returns: 0 on success, -1 on error
2027	
2028	This signals to the host kernel that the specified guest is being paused by
2029	userspace.  The host will set a flag in the pvclock structure that is checked
2030	from the soft lockup watchdog.  The flag is part of the pvclock structure that
2031	is shared between guest and host, specifically the second bit of the flags
2032	field of the pvclock_vcpu_time_info structure.  It will be set exclusively by
2033	the host and read/cleared exclusively by the guest.  The guest operation of
2034	checking and clearing the flag must an atomic operation so
2035	load-link/store-conditional, or equivalent must be used.  There are two cases
2036	where the guest will clear the flag: when the soft lockup watchdog timer resets
2037	itself or when a soft lockup is detected.  This ioctl can be called any time
2038	after pausing the vcpu, but before it is resumed.
2039	
2040	
2041	4.71 KVM_SIGNAL_MSI
2042	
2043	Capability: KVM_CAP_SIGNAL_MSI
2044	Architectures: x86 arm arm64
2045	Type: vm ioctl
2046	Parameters: struct kvm_msi (in)
2047	Returns: >0 on delivery, 0 if guest blocked the MSI, and -1 on error
2048	
2049	Directly inject a MSI message. Only valid with in-kernel irqchip that handles
2050	MSI messages.
2051	
2052	struct kvm_msi {
2053		__u32 address_lo;
2054		__u32 address_hi;
2055		__u32 data;
2056		__u32 flags;
2057		__u32 devid;
2058		__u8  pad[12];
2059	};
2060	
2061	flags: KVM_MSI_VALID_DEVID: devid contains a valid value.  The per-VM
2062	  KVM_CAP_MSI_DEVID capability advertises the requirement to provide
2063	  the device ID.  If this capability is not available, userspace
2064	  should never set the KVM_MSI_VALID_DEVID flag as the ioctl might fail.
2065	
2066	If KVM_MSI_VALID_DEVID is set, devid contains a unique device identifier
2067	for the device that wrote the MSI message.  For PCI, this is usually a
2068	BFD identifier in the lower 16 bits.
2069	
2070	On x86, address_hi is ignored unless the KVM_X2APIC_API_USE_32BIT_IDS
2071	feature of KVM_CAP_X2APIC_API capability is enabled.  If it is enabled,
2072	address_hi bits 31-8 provide bits 31-8 of the destination id.  Bits 7-0 of
2073	address_hi must be zero.
2074	
2075	
2076	4.71 KVM_CREATE_PIT2
2077	
2078	Capability: KVM_CAP_PIT2
2079	Architectures: x86
2080	Type: vm ioctl
2081	Parameters: struct kvm_pit_config (in)
2082	Returns: 0 on success, -1 on error
2083	
2084	Creates an in-kernel device model for the i8254 PIT. This call is only valid
2085	after enabling in-kernel irqchip support via KVM_CREATE_IRQCHIP. The following
2086	parameters have to be passed:
2087	
2088	struct kvm_pit_config {
2089		__u32 flags;
2090		__u32 pad[15];
2091	};
2092	
2093	Valid flags are:
2094	
2095	#define KVM_PIT_SPEAKER_DUMMY     1 /* emulate speaker port stub */
2096	
2097	PIT timer interrupts may use a per-VM kernel thread for injection. If it
2098	exists, this thread will have a name of the following pattern:
2099	
2100	kvm-pit/<owner-process-pid>
2101	
2102	When running a guest with elevated priorities, the scheduling parameters of
2103	this thread may have to be adjusted accordingly.
2104	
2105	This IOCTL replaces the obsolete KVM_CREATE_PIT.
2106	
2107	
2108	4.72 KVM_GET_PIT2
2109	
2110	Capability: KVM_CAP_PIT_STATE2
2111	Architectures: x86
2112	Type: vm ioctl
2113	Parameters: struct kvm_pit_state2 (out)
2114	Returns: 0 on success, -1 on error
2115	
2116	Retrieves the state of the in-kernel PIT model. Only valid after
2117	KVM_CREATE_PIT2. The state is returned in the following structure:
2118	
2119	struct kvm_pit_state2 {
2120		struct kvm_pit_channel_state channels[3];
2121		__u32 flags;
2122		__u32 reserved[9];
2123	};
2124	
2125	Valid flags are:
2126	
2127	/* disable PIT in HPET legacy mode */
2128	#define KVM_PIT_FLAGS_HPET_LEGACY  0x00000001
2129	
2130	This IOCTL replaces the obsolete KVM_GET_PIT.
2131	
2132	
2133	4.73 KVM_SET_PIT2
2134	
2135	Capability: KVM_CAP_PIT_STATE2
2136	Architectures: x86
2137	Type: vm ioctl
2138	Parameters: struct kvm_pit_state2 (in)
2139	Returns: 0 on success, -1 on error
2140	
2141	Sets the state of the in-kernel PIT model. Only valid after KVM_CREATE_PIT2.
2142	See KVM_GET_PIT2 for details on struct kvm_pit_state2.
2143	
2144	This IOCTL replaces the obsolete KVM_SET_PIT.
2145	
2146	
2147	4.74 KVM_PPC_GET_SMMU_INFO
2148	
2149	Capability: KVM_CAP_PPC_GET_SMMU_INFO
2150	Architectures: powerpc
2151	Type: vm ioctl
2152	Parameters: None
2153	Returns: 0 on success, -1 on error
2154	
2155	This populates and returns a structure describing the features of
2156	the "Server" class MMU emulation supported by KVM.
2157	This can in turn be used by userspace to generate the appropriate
2158	device-tree properties for the guest operating system.
2159	
2160	The structure contains some global information, followed by an
2161	array of supported segment page sizes:
2162	
2163	      struct kvm_ppc_smmu_info {
2164		     __u64 flags;
2165		     __u32 slb_size;
2166		     __u32 pad;
2167		     struct kvm_ppc_one_seg_page_size sps[KVM_PPC_PAGE_SIZES_MAX_SZ];
2168	      };
2169	
2170	The supported flags are:
2171	
2172	    - KVM_PPC_PAGE_SIZES_REAL:
2173	        When that flag is set, guest page sizes must "fit" the backing
2174	        store page sizes. When not set, any page size in the list can
2175	        be used regardless of how they are backed by userspace.
2176	
2177	    - KVM_PPC_1T_SEGMENTS
2178	        The emulated MMU supports 1T segments in addition to the
2179	        standard 256M ones.
2180	
2181	The "slb_size" field indicates how many SLB entries are supported
2182	
2183	The "sps" array contains 8 entries indicating the supported base
2184	page sizes for a segment in increasing order. Each entry is defined
2185	as follow:
2186	
2187	   struct kvm_ppc_one_seg_page_size {
2188		__u32 page_shift;	/* Base page shift of segment (or 0) */
2189		__u32 slb_enc;		/* SLB encoding for BookS */
2190		struct kvm_ppc_one_page_size enc[KVM_PPC_PAGE_SIZES_MAX_SZ];
2191	   };
2192	
2193	An entry with a "page_shift" of 0 is unused. Because the array is
2194	organized in increasing order, a lookup can stop when encoutering
2195	such an entry.
2196	
2197	The "slb_enc" field provides the encoding to use in the SLB for the
2198	page size. The bits are in positions such as the value can directly
2199	be OR'ed into the "vsid" argument of the slbmte instruction.
2200	
2201	The "enc" array is a list which for each of those segment base page
2202	size provides the list of supported actual page sizes (which can be
2203	only larger or equal to the base page size), along with the
2204	corresponding encoding in the hash PTE. Similarly, the array is
2205	8 entries sorted by increasing sizes and an entry with a "0" shift
2206	is an empty entry and a terminator:
2207	
2208	   struct kvm_ppc_one_page_size {
2209		__u32 page_shift;	/* Page shift (or 0) */
2210		__u32 pte_enc;		/* Encoding in the HPTE (>>12) */
2211	   };
2212	
2213	The "pte_enc" field provides a value that can OR'ed into the hash
2214	PTE's RPN field (ie, it needs to be shifted left by 12 to OR it
2215	into the hash PTE second double word).
2216	
2217	4.75 KVM_IRQFD
2218	
2219	Capability: KVM_CAP_IRQFD
2220	Architectures: x86 s390 arm arm64
2221	Type: vm ioctl
2222	Parameters: struct kvm_irqfd (in)
2223	Returns: 0 on success, -1 on error
2224	
2225	Allows setting an eventfd to directly trigger a guest interrupt.
2226	kvm_irqfd.fd specifies the file descriptor to use as the eventfd and
2227	kvm_irqfd.gsi specifies the irqchip pin toggled by this event.  When
2228	an event is triggered on the eventfd, an interrupt is injected into
2229	the guest using the specified gsi pin.  The irqfd is removed using
2230	the KVM_IRQFD_FLAG_DEASSIGN flag, specifying both kvm_irqfd.fd
2231	and kvm_irqfd.gsi.
2232	
2233	With KVM_CAP_IRQFD_RESAMPLE, KVM_IRQFD supports a de-assert and notify
2234	mechanism allowing emulation of level-triggered, irqfd-based
2235	interrupts.  When KVM_IRQFD_FLAG_RESAMPLE is set the user must pass an
2236	additional eventfd in the kvm_irqfd.resamplefd field.  When operating
2237	in resample mode, posting of an interrupt through kvm_irq.fd asserts
2238	the specified gsi in the irqchip.  When the irqchip is resampled, such
2239	as from an EOI, the gsi is de-asserted and the user is notified via
2240	kvm_irqfd.resamplefd.  It is the user's responsibility to re-queue
2241	the interrupt if the device making use of it still requires service.
2242	Note that closing the resamplefd is not sufficient to disable the
2243	irqfd.  The KVM_IRQFD_FLAG_RESAMPLE is only necessary on assignment
2244	and need not be specified with KVM_IRQFD_FLAG_DEASSIGN.
2245	
2246	On arm/arm64, gsi routing being supported, the following can happen:
2247	- in case no routing entry is associated to this gsi, injection fails
2248	- in case the gsi is associated to an irqchip routing entry,
2249	  irqchip.pin + 32 corresponds to the injected SPI ID.
2250	- in case the gsi is associated to an MSI routing entry, the MSI
2251	  message and device ID are translated into an LPI (support restricted
2252	  to GICv3 ITS in-kernel emulation).
2253	
2254	4.76 KVM_PPC_ALLOCATE_HTAB
2255	
2256	Capability: KVM_CAP_PPC_ALLOC_HTAB
2257	Architectures: powerpc
2258	Type: vm ioctl
2259	Parameters: Pointer to u32 containing hash table order (in/out)
2260	Returns: 0 on success, -1 on error
2261	
2262	This requests the host kernel to allocate an MMU hash table for a
2263	guest using the PAPR paravirtualization interface.  This only does
2264	anything if the kernel is configured to use the Book 3S HV style of
2265	virtualization.  Otherwise the capability doesn't exist and the ioctl
2266	returns an ENOTTY error.  The rest of this description assumes Book 3S
2267	HV.
2268	
2269	There must be no vcpus running when this ioctl is called; if there
2270	are, it will do nothing and return an EBUSY error.
2271	
2272	The parameter is a pointer to a 32-bit unsigned integer variable
2273	containing the order (log base 2) of the desired size of the hash
2274	table, which must be between 18 and 46.  On successful return from the
2275	ioctl, the value will not be changed by the kernel.
2276	
2277	If no hash table has been allocated when any vcpu is asked to run
2278	(with the KVM_RUN ioctl), the host kernel will allocate a
2279	default-sized hash table (16 MB).
2280	
2281	If this ioctl is called when a hash table has already been allocated,
2282	with a different order from the existing hash table, the existing hash
2283	table will be freed and a new one allocated.  If this is ioctl is
2284	called when a hash table has already been allocated of the same order
2285	as specified, the kernel will clear out the existing hash table (zero
2286	all HPTEs).  In either case, if the guest is using the virtualized
2287	real-mode area (VRMA) facility, the kernel will re-create the VMRA
2288	HPTEs on the next KVM_RUN of any vcpu.
2289	
2290	4.77 KVM_S390_INTERRUPT
2291	
2292	Capability: basic
2293	Architectures: s390
2294	Type: vm ioctl, vcpu ioctl
2295	Parameters: struct kvm_s390_interrupt (in)
2296	Returns: 0 on success, -1 on error
2297	
2298	Allows to inject an interrupt to the guest. Interrupts can be floating
2299	(vm ioctl) or per cpu (vcpu ioctl), depending on the interrupt type.
2300	
2301	Interrupt parameters are passed via kvm_s390_interrupt:
2302	
2303	struct kvm_s390_interrupt {
2304		__u32 type;
2305		__u32 parm;
2306		__u64 parm64;
2307	};
2308	
2309	type can be one of the following:
2310	
2311	KVM_S390_SIGP_STOP (vcpu) - sigp stop; optional flags in parm
2312	KVM_S390_PROGRAM_INT (vcpu) - program check; code in parm
2313	KVM_S390_SIGP_SET_PREFIX (vcpu) - sigp set prefix; prefix address in parm
2314	KVM_S390_RESTART (vcpu) - restart
2315	KVM_S390_INT_CLOCK_COMP (vcpu) - clock comparator interrupt
2316	KVM_S390_INT_CPU_TIMER (vcpu) - CPU timer interrupt
2317	KVM_S390_INT_VIRTIO (vm) - virtio external interrupt; external interrupt
2318				   parameters in parm and parm64
2319	KVM_S390_INT_SERVICE (vm) - sclp external interrupt; sclp parameter in parm
2320	KVM_S390_INT_EMERGENCY (vcpu) - sigp emergency; source cpu in parm
2321	KVM_S390_INT_EXTERNAL_CALL (vcpu) - sigp external call; source cpu in parm
2322	KVM_S390_INT_IO(ai,cssid,ssid,schid) (vm) - compound value to indicate an
2323	    I/O interrupt (ai - adapter interrupt; cssid,ssid,schid - subchannel);
2324	    I/O interruption parameters in parm (subchannel) and parm64 (intparm,
2325	    interruption subclass)
2326	KVM_S390_MCHK (vm, vcpu) - machine check interrupt; cr 14 bits in parm,
2327	                           machine check interrupt code in parm64 (note that
2328	                           machine checks needing further payload are not
2329	                           supported by this ioctl)
2330	
2331	Note that the vcpu ioctl is asynchronous to vcpu execution.
2332	
2333	4.78 KVM_PPC_GET_HTAB_FD
2334	
2335	Capability: KVM_CAP_PPC_HTAB_FD
2336	Architectures: powerpc
2337	Type: vm ioctl
2338	Parameters: Pointer to struct kvm_get_htab_fd (in)
2339	Returns: file descriptor number (>= 0) on success, -1 on error
2340	
2341	This returns a file descriptor that can be used either to read out the
2342	entries in the guest's hashed page table (HPT), or to write entries to
2343	initialize the HPT.  The returned fd can only be written to if the
2344	KVM_GET_HTAB_WRITE bit is set in the flags field of the argument, and
2345	can only be read if that bit is clear.  The argument struct looks like
2346	this:
2347	
2348	/* For KVM_PPC_GET_HTAB_FD */
2349	struct kvm_get_htab_fd {
2350		__u64	flags;
2351		__u64	start_index;
2352		__u64	reserved[2];
2353	};
2354	
2355	/* Values for kvm_get_htab_fd.flags */
2356	#define KVM_GET_HTAB_BOLTED_ONLY	((__u64)0x1)
2357	#define KVM_GET_HTAB_WRITE		((__u64)0x2)
2358	
2359	The `start_index' field gives the index in the HPT of the entry at
2360	which to start reading.  It is ignored when writing.
2361	
2362	Reads on the fd will initially supply information about all
2363	"interesting" HPT entries.  Interesting entries are those with the
2364	bolted bit set, if the KVM_GET_HTAB_BOLTED_ONLY bit is set, otherwise
2365	all entries.  When the end of the HPT is reached, the read() will
2366	return.  If read() is called again on the fd, it will start again from
2367	the beginning of the HPT, but will only return HPT entries that have
2368	changed since they were last read.
2369	
2370	Data read or written is structured as a header (8 bytes) followed by a
2371	series of valid HPT entries (16 bytes) each.  The header indicates how
2372	many valid HPT entries there are and how many invalid entries follow
2373	the valid entries.  The invalid entries are not represented explicitly
2374	in the stream.  The header format is:
2375	
2376	struct kvm_get_htab_header {
2377		__u32	index;
2378		__u16	n_valid;
2379		__u16	n_invalid;
2380	};
2381	
2382	Writes to the fd create HPT entries starting at the index given in the
2383	header; first `n_valid' valid entries with contents from the data
2384	written, then `n_invalid' invalid entries, invalidating any previously
2385	valid entries found.
2386	
2387	4.79 KVM_CREATE_DEVICE
2388	
2389	Capability: KVM_CAP_DEVICE_CTRL
2390	Type: vm ioctl
2391	Parameters: struct kvm_create_device (in/out)
2392	Returns: 0 on success, -1 on error
2393	Errors:
2394	  ENODEV: The device type is unknown or unsupported
2395	  EEXIST: Device already created, and this type of device may not
2396	          be instantiated multiple times
2397	
2398	  Other error conditions may be defined by individual device types or
2399	  have their standard meanings.
2400	
2401	Creates an emulated device in the kernel.  The file descriptor returned
2402	in fd can be used with KVM_SET/GET/HAS_DEVICE_ATTR.
2403	
2404	If the KVM_CREATE_DEVICE_TEST flag is set, only test whether the
2405	device type is supported (not necessarily whether it can be created
2406	in the current vm).
2407	
2408	Individual devices should not define flags.  Attributes should be used
2409	for specifying any behavior that is not implied by the device type
2410	number.
2411	
2412	struct kvm_create_device {
2413		__u32	type;	/* in: KVM_DEV_TYPE_xxx */
2414		__u32	fd;	/* out: device handle */
2415		__u32	flags;	/* in: KVM_CREATE_DEVICE_xxx */
2416	};
2417	
2418	4.80 KVM_SET_DEVICE_ATTR/KVM_GET_DEVICE_ATTR
2419	
2420	Capability: KVM_CAP_DEVICE_CTRL, KVM_CAP_VM_ATTRIBUTES for vm device,
2421	  KVM_CAP_VCPU_ATTRIBUTES for vcpu device
2422	Type: device ioctl, vm ioctl, vcpu ioctl
2423	Parameters: struct kvm_device_attr
2424	Returns: 0 on success, -1 on error
2425	Errors:
2426	  ENXIO:  The group or attribute is unknown/unsupported for this device
2427	          or hardware support is missing.
2428	  EPERM:  The attribute cannot (currently) be accessed this way
2429	          (e.g. read-only attribute, or attribute that only makes
2430	          sense when the device is in a different state)
2431	
2432	  Other error conditions may be defined by individual device types.
2433	
2434	Gets/sets a specified piece of device configuration and/or state.  The
2435	semantics are device-specific.  See individual device documentation in
2436	the "devices" directory.  As with ONE_REG, the size of the data
2437	transferred is defined by the particular attribute.
2438	
2439	struct kvm_device_attr {
2440		__u32	flags;		/* no flags currently defined */
2441		__u32	group;		/* device-defined */
2442		__u64	attr;		/* group-defined */
2443		__u64	addr;		/* userspace address of attr data */
2444	};
2445	
2446	4.81 KVM_HAS_DEVICE_ATTR
2447	
2448	Capability: KVM_CAP_DEVICE_CTRL, KVM_CAP_VM_ATTRIBUTES for vm device,
2449	  KVM_CAP_VCPU_ATTRIBUTES for vcpu device
2450	Type: device ioctl, vm ioctl, vcpu ioctl
2451	Parameters: struct kvm_device_attr
2452	Returns: 0 on success, -1 on error
2453	Errors:
2454	  ENXIO:  The group or attribute is unknown/unsupported for this device
2455	          or hardware support is missing.
2456	
2457	Tests whether a device supports a particular attribute.  A successful
2458	return indicates the attribute is implemented.  It does not necessarily
2459	indicate that the attribute can be read or written in the device's
2460	current state.  "addr" is ignored.
2461	
2462	4.82 KVM_ARM_VCPU_INIT
2463	
2464	Capability: basic
2465	Architectures: arm, arm64
2466	Type: vcpu ioctl
2467	Parameters: struct kvm_vcpu_init (in)
2468	Returns: 0 on success; -1 on error
2469	Errors:
2470	  EINVAL:    the target is unknown, or the combination of features is invalid.
2471	  ENOENT:    a features bit specified is unknown.
2472	
2473	This tells KVM what type of CPU to present to the guest, and what
2474	optional features it should have.  This will cause a reset of the cpu
2475	registers to their initial values.  If this is not called, KVM_RUN will
2476	return ENOEXEC for that vcpu.
2477	
2478	Note that because some registers reflect machine topology, all vcpus
2479	should be created before this ioctl is invoked.
2480	
2481	Userspace can call this function multiple times for a given vcpu, including
2482	after the vcpu has been run. This will reset the vcpu to its initial
2483	state. All calls to this function after the initial call must use the same
2484	target and same set of feature flags, otherwise EINVAL will be returned.
2485	
2486	Possible features:
2487		- KVM_ARM_VCPU_POWER_OFF: Starts the CPU in a power-off state.
2488		  Depends on KVM_CAP_ARM_PSCI.  If not set, the CPU will be powered on
2489		  and execute guest code when KVM_RUN is called.
2490		- KVM_ARM_VCPU_EL1_32BIT: Starts the CPU in a 32bit mode.
2491		  Depends on KVM_CAP_ARM_EL1_32BIT (arm64 only).
2492		- KVM_ARM_VCPU_PSCI_0_2: Emulate PSCI v0.2 for the CPU.
2493		  Depends on KVM_CAP_ARM_PSCI_0_2.
2494		- KVM_ARM_VCPU_PMU_V3: Emulate PMUv3 for the CPU.
2495		  Depends on KVM_CAP_ARM_PMU_V3.
2496	
2497	
2498	4.83 KVM_ARM_PREFERRED_TARGET
2499	
2500	Capability: basic
2501	Architectures: arm, arm64
2502	Type: vm ioctl
2503	Parameters: struct struct kvm_vcpu_init (out)
2504	Returns: 0 on success; -1 on error
2505	Errors:
2506	  ENODEV:    no preferred target available for the host
2507	
2508	This queries KVM for preferred CPU target type which can be emulated
2509	by KVM on underlying host.
2510	
2511	The ioctl returns struct kvm_vcpu_init instance containing information
2512	about preferred CPU target type and recommended features for it.  The
2513	kvm_vcpu_init->features bitmap returned will have feature bits set if
2514	the preferred target recommends setting these features, but this is
2515	not mandatory.
2516	
2517	The information returned by this ioctl can be used to prepare an instance
2518	of struct kvm_vcpu_init for KVM_ARM_VCPU_INIT ioctl which will result in
2519	in VCPU matching underlying host.
2520	
2521	
2522	4.84 KVM_GET_REG_LIST
2523	
2524	Capability: basic
2525	Architectures: arm, arm64, mips
2526	Type: vcpu ioctl
2527	Parameters: struct kvm_reg_list (in/out)
2528	Returns: 0 on success; -1 on error
2529	Errors:
2530	  E2BIG:     the reg index list is too big to fit in the array specified by
2531	             the user (the number required will be written into n).
2532	
2533	struct kvm_reg_list {
2534		__u64 n; /* number of registers in reg[] */
2535		__u64 reg[0];
2536	};
2537	
2538	This ioctl returns the guest registers that are supported for the
2539	KVM_GET_ONE_REG/KVM_SET_ONE_REG calls.
2540	
2541	
2542	4.85 KVM_ARM_SET_DEVICE_ADDR (deprecated)
2543	
2544	Capability: KVM_CAP_ARM_SET_DEVICE_ADDR
2545	Architectures: arm, arm64
2546	Type: vm ioctl
2547	Parameters: struct kvm_arm_device_address (in)
2548	Returns: 0 on success, -1 on error
2549	Errors:
2550	  ENODEV: The device id is unknown
2551	  ENXIO:  Device not supported on current system
2552	  EEXIST: Address already set
2553	  E2BIG:  Address outside guest physical address space
2554	  EBUSY:  Address overlaps with other device range
2555	
2556	struct kvm_arm_device_addr {
2557		__u64 id;
2558		__u64 addr;
2559	};
2560	
2561	Specify a device address in the guest's physical address space where guests
2562	can access emulated or directly exposed devices, which the host kernel needs
2563	to know about. The id field is an architecture specific identifier for a
2564	specific device.
2565	
2566	ARM/arm64 divides the id field into two parts, a device id and an
2567	address type id specific to the individual device.
2568	
2569	  bits:  | 63        ...       32 | 31    ...    16 | 15    ...    0 |
2570	  field: |        0x00000000      |     device id   |  addr type id  |
2571	
2572	ARM/arm64 currently only require this when using the in-kernel GIC
2573	support for the hardware VGIC features, using KVM_ARM_DEVICE_VGIC_V2
2574	as the device id.  When setting the base address for the guest's
2575	mapping of the VGIC virtual CPU and distributor interface, the ioctl
2576	must be called after calling KVM_CREATE_IRQCHIP, but before calling
2577	KVM_RUN on any of the VCPUs.  Calling this ioctl twice for any of the
2578	base addresses will return -EEXIST.
2579	
2580	Note, this IOCTL is deprecated and the more flexible SET/GET_DEVICE_ATTR API
2581	should be used instead.
2582	
2583	
2584	4.86 KVM_PPC_RTAS_DEFINE_TOKEN
2585	
2586	Capability: KVM_CAP_PPC_RTAS
2587	Architectures: ppc
2588	Type: vm ioctl
2589	Parameters: struct kvm_rtas_token_args
2590	Returns: 0 on success, -1 on error
2591	
2592	Defines a token value for a RTAS (Run Time Abstraction Services)
2593	service in order to allow it to be handled in the kernel.  The
2594	argument struct gives the name of the service, which must be the name
2595	of a service that has a kernel-side implementation.  If the token
2596	value is non-zero, it will be associated with that service, and
2597	subsequent RTAS calls by the guest specifying that token will be
2598	handled by the kernel.  If the token value is 0, then any token
2599	associated with the service will be forgotten, and subsequent RTAS
2600	calls by the guest for that service will be passed to userspace to be
2601	handled.
2602	
2603	4.87 KVM_SET_GUEST_DEBUG
2604	
2605	Capability: KVM_CAP_SET_GUEST_DEBUG
2606	Architectures: x86, s390, ppc, arm64
2607	Type: vcpu ioctl
2608	Parameters: struct kvm_guest_debug (in)
2609	Returns: 0 on success; -1 on error
2610	
2611	struct kvm_guest_debug {
2612	       __u32 control;
2613	       __u32 pad;
2614	       struct kvm_guest_debug_arch arch;
2615	};
2616	
2617	Set up the processor specific debug registers and configure vcpu for
2618	handling guest debug events. There are two parts to the structure, the
2619	first a control bitfield indicates the type of debug events to handle
2620	when running. Common control bits are:
2621	
2622	  - KVM_GUESTDBG_ENABLE:        guest debugging is enabled
2623	  - KVM_GUESTDBG_SINGLESTEP:    the next run should single-step
2624	
2625	The top 16 bits of the control field are architecture specific control
2626	flags which can include the following:
2627	
2628	  - KVM_GUESTDBG_USE_SW_BP:     using software breakpoints [x86, arm64]
2629	  - KVM_GUESTDBG_USE_HW_BP:     using hardware breakpoints [x86, s390, arm64]
2630	  - KVM_GUESTDBG_INJECT_DB:     inject DB type exception [x86]
2631	  - KVM_GUESTDBG_INJECT_BP:     inject BP type exception [x86]
2632	  - KVM_GUESTDBG_EXIT_PENDING:  trigger an immediate guest exit [s390]
2633	
2634	For example KVM_GUESTDBG_USE_SW_BP indicates that software breakpoints
2635	are enabled in memory so we need to ensure breakpoint exceptions are
2636	correctly trapped and the KVM run loop exits at the breakpoint and not
2637	running off into the normal guest vector. For KVM_GUESTDBG_USE_HW_BP
2638	we need to ensure the guest vCPUs architecture specific registers are
2639	updated to the correct (supplied) values.
2640	
2641	The second part of the structure is architecture specific and
2642	typically contains a set of debug registers.
2643	
2644	For arm64 the number of debug registers is implementation defined and
2645	can be determined by querying the KVM_CAP_GUEST_DEBUG_HW_BPS and
2646	KVM_CAP_GUEST_DEBUG_HW_WPS capabilities which return a positive number
2647	indicating the number of supported registers.
2648	
2649	When debug events exit the main run loop with the reason
2650	KVM_EXIT_DEBUG with the kvm_debug_exit_arch part of the kvm_run
2651	structure containing architecture specific debug information.
2652	
2653	4.88 KVM_GET_EMULATED_CPUID
2654	
2655	Capability: KVM_CAP_EXT_EMUL_CPUID
2656	Architectures: x86
2657	Type: system ioctl
2658	Parameters: struct kvm_cpuid2 (in/out)
2659	Returns: 0 on success, -1 on error
2660	
2661	struct kvm_cpuid2 {
2662		__u32 nent;
2663		__u32 flags;
2664		struct kvm_cpuid_entry2 entries[0];
2665	};
2666	
2667	The member 'flags' is used for passing flags from userspace.
2668	
2669	#define KVM_CPUID_FLAG_SIGNIFCANT_INDEX		BIT(0)
2670	#define KVM_CPUID_FLAG_STATEFUL_FUNC		BIT(1)
2671	#define KVM_CPUID_FLAG_STATE_READ_NEXT		BIT(2)
2672	
2673	struct kvm_cpuid_entry2 {
2674		__u32 function;
2675		__u32 index;
2676		__u32 flags;
2677		__u32 eax;
2678		__u32 ebx;
2679		__u32 ecx;
2680		__u32 edx;
2681		__u32 padding[3];
2682	};
2683	
2684	This ioctl returns x86 cpuid features which are emulated by
2685	kvm.Userspace can use the information returned by this ioctl to query
2686	which features are emulated by kvm instead of being present natively.
2687	
2688	Userspace invokes KVM_GET_EMULATED_CPUID by passing a kvm_cpuid2
2689	structure with the 'nent' field indicating the number of entries in
2690	the variable-size array 'entries'. If the number of entries is too low
2691	to describe the cpu capabilities, an error (E2BIG) is returned. If the
2692	number is too high, the 'nent' field is adjusted and an error (ENOMEM)
2693	is returned. If the number is just right, the 'nent' field is adjusted
2694	to the number of valid entries in the 'entries' array, which is then
2695	filled.
2696	
2697	The entries returned are the set CPUID bits of the respective features
2698	which kvm emulates, as returned by the CPUID instruction, with unknown
2699	or unsupported feature bits cleared.
2700	
2701	Features like x2apic, for example, may not be present in the host cpu
2702	but are exposed by kvm in KVM_GET_SUPPORTED_CPUID because they can be
2703	emulated efficiently and thus not included here.
2704	
2705	The fields in each entry are defined as follows:
2706	
2707	  function: the eax value used to obtain the entry
2708	  index: the ecx value used to obtain the entry (for entries that are
2709	         affected by ecx)
2710	  flags: an OR of zero or more of the following:
2711	        KVM_CPUID_FLAG_SIGNIFCANT_INDEX:
2712	           if the index field is valid
2713	        KVM_CPUID_FLAG_STATEFUL_FUNC:
2714	           if cpuid for this function returns different values for successive
2715	           invocations; there will be several entries with the same function,
2716	           all with this flag set
2717	        KVM_CPUID_FLAG_STATE_READ_NEXT:
2718	           for KVM_CPUID_FLAG_STATEFUL_FUNC entries, set if this entry is
2719	           the first entry to be read by a cpu
2720	   eax, ebx, ecx, edx: the values returned by the cpuid instruction for
2721	         this function/index combination
2722	
2723	4.89 KVM_S390_MEM_OP
2724	
2725	Capability: KVM_CAP_S390_MEM_OP
2726	Architectures: s390
2727	Type: vcpu ioctl
2728	Parameters: struct kvm_s390_mem_op (in)
2729	Returns: = 0 on success,
2730	         < 0 on generic error (e.g. -EFAULT or -ENOMEM),
2731	         > 0 if an exception occurred while walking the page tables
2732	
2733	Read or write data from/to the logical (virtual) memory of a VCPU.
2734	
2735	Parameters are specified via the following structure:
2736	
2737	struct kvm_s390_mem_op {
2738		__u64 gaddr;		/* the guest address */
2739		__u64 flags;		/* flags */
2740		__u32 size;		/* amount of bytes */
2741		__u32 op;		/* type of operation */
2742		__u64 buf;		/* buffer in userspace */
2743		__u8 ar;		/* the access register number */
2744		__u8 reserved[31];	/* should be set to 0 */
2745	};
2746	
2747	The type of operation is specified in the "op" field. It is either
2748	KVM_S390_MEMOP_LOGICAL_READ for reading from logical memory space or
2749	KVM_S390_MEMOP_LOGICAL_WRITE for writing to logical memory space. The
2750	KVM_S390_MEMOP_F_CHECK_ONLY flag can be set in the "flags" field to check
2751	whether the corresponding memory access would create an access exception
2752	(without touching the data in the memory at the destination). In case an
2753	access exception occurred while walking the MMU tables of the guest, the
2754	ioctl returns a positive error number to indicate the type of exception.
2755	This exception is also raised directly at the corresponding VCPU if the
2756	flag KVM_S390_MEMOP_F_INJECT_EXCEPTION is set in the "flags" field.
2757	
2758	The start address of the memory region has to be specified in the "gaddr"
2759	field, and the length of the region in the "size" field. "buf" is the buffer
2760	supplied by the userspace application where the read data should be written
2761	to for KVM_S390_MEMOP_LOGICAL_READ, or where the data that should be written
2762	is stored for a KVM_S390_MEMOP_LOGICAL_WRITE. "buf" is unused and can be NULL
2763	when KVM_S390_MEMOP_F_CHECK_ONLY is specified. "ar" designates the access
2764	register number to be used.
2765	
2766	The "reserved" field is meant for future extensions. It is not used by
2767	KVM with the currently defined set of flags.
2768	
2769	4.90 KVM_S390_GET_SKEYS
2770	
2771	Capability: KVM_CAP_S390_SKEYS
2772	Architectures: s390
2773	Type: vm ioctl
2774	Parameters: struct kvm_s390_skeys
2775	Returns: 0 on success, KVM_S390_GET_KEYS_NONE if guest is not using storage
2776	         keys, negative value on error
2777	
2778	This ioctl is used to get guest storage key values on the s390
2779	architecture. The ioctl takes parameters via the kvm_s390_skeys struct.
2780	
2781	struct kvm_s390_skeys {
2782		__u64 start_gfn;
2783		__u64 count;
2784		__u64 skeydata_addr;
2785		__u32 flags;
2786		__u32 reserved[9];
2787	};
2788	
2789	The start_gfn field is the number of the first guest frame whose storage keys
2790	you want to get.
2791	
2792	The count field is the number of consecutive frames (starting from start_gfn)
2793	whose storage keys to get. The count field must be at least 1 and the maximum
2794	allowed value is defined as KVM_S390_SKEYS_ALLOC_MAX. Values outside this range
2795	will cause the ioctl to return -EINVAL.
2796	
2797	The skeydata_addr field is the address to a buffer large enough to hold count
2798	bytes. This buffer will be filled with storage key data by the ioctl.
2799	
2800	4.91 KVM_S390_SET_SKEYS
2801	
2802	Capability: KVM_CAP_S390_SKEYS
2803	Architectures: s390
2804	Type: vm ioctl
2805	Parameters: struct kvm_s390_skeys
2806	Returns: 0 on success, negative value on error
2807	
2808	This ioctl is used to set guest storage key values on the s390
2809	architecture. The ioctl takes parameters via the kvm_s390_skeys struct.
2810	See section on KVM_S390_GET_SKEYS for struct definition.
2811	
2812	The start_gfn field is the number of the first guest frame whose storage keys
2813	you want to set.
2814	
2815	The count field is the number of consecutive frames (starting from start_gfn)
2816	whose storage keys to get. The count field must be at least 1 and the maximum
2817	allowed value is defined as KVM_S390_SKEYS_ALLOC_MAX. Values outside this range
2818	will cause the ioctl to return -EINVAL.
2819	
2820	The skeydata_addr field is the address to a buffer containing count bytes of
2821	storage keys. Each byte in the buffer will be set as the storage key for a
2822	single frame starting at start_gfn for count frames.
2823	
2824	Note: If any architecturally invalid key value is found in the given data then
2825	the ioctl will return -EINVAL.
2826	
2827	4.92 KVM_S390_IRQ
2828	
2829	Capability: KVM_CAP_S390_INJECT_IRQ
2830	Architectures: s390
2831	Type: vcpu ioctl
2832	Parameters: struct kvm_s390_irq (in)
2833	Returns: 0 on success, -1 on error
2834	Errors:
2835	  EINVAL: interrupt type is invalid
2836	          type is KVM_S390_SIGP_STOP and flag parameter is invalid value
2837	          type is KVM_S390_INT_EXTERNAL_CALL and code is bigger
2838	            than the maximum of VCPUs
2839	  EBUSY:  type is KVM_S390_SIGP_SET_PREFIX and vcpu is not stopped
2840	          type is KVM_S390_SIGP_STOP and a stop irq is already pending
2841	          type is KVM_S390_INT_EXTERNAL_CALL and an external call interrupt
2842	            is already pending
2843	
2844	Allows to inject an interrupt to the guest.
2845	
2846	Using struct kvm_s390_irq as a parameter allows
2847	to inject additional payload which is not
2848	possible via KVM_S390_INTERRUPT.
2849	
2850	Interrupt parameters are passed via kvm_s390_irq:
2851	
2852	struct kvm_s390_irq {
2853		__u64 type;
2854		union {
2855			struct kvm_s390_io_info io;
2856			struct kvm_s390_ext_info ext;
2857			struct kvm_s390_pgm_info pgm;
2858			struct kvm_s390_emerg_info emerg;
2859			struct kvm_s390_extcall_info extcall;
2860			struct kvm_s390_prefix_info prefix;
2861			struct kvm_s390_stop_info stop;
2862			struct kvm_s390_mchk_info mchk;
2863			char reserved[64];
2864		} u;
2865	};
2866	
2867	type can be one of the following:
2868	
2869	KVM_S390_SIGP_STOP - sigp stop; parameter in .stop
2870	KVM_S390_PROGRAM_INT - program check; parameters in .pgm
2871	KVM_S390_SIGP_SET_PREFIX - sigp set prefix; parameters in .prefix
2872	KVM_S390_RESTART - restart; no parameters
2873	KVM_S390_INT_CLOCK_COMP - clock comparator interrupt; no parameters
2874	KVM_S390_INT_CPU_TIMER - CPU timer interrupt; no parameters
2875	KVM_S390_INT_EMERGENCY - sigp emergency; parameters in .emerg
2876	KVM_S390_INT_EXTERNAL_CALL - sigp external call; parameters in .extcall
2877	KVM_S390_MCHK - machine check interrupt; parameters in .mchk
2878	
2879	
2880	Note that the vcpu ioctl is asynchronous to vcpu execution.
2881	
2882	4.94 KVM_S390_GET_IRQ_STATE
2883	
2884	Capability: KVM_CAP_S390_IRQ_STATE
2885	Architectures: s390
2886	Type: vcpu ioctl
2887	Parameters: struct kvm_s390_irq_state (out)
2888	Returns: >= number of bytes copied into buffer,
2889	         -EINVAL if buffer size is 0,
2890	         -ENOBUFS if buffer size is too small to fit all pending interrupts,
2891	         -EFAULT if the buffer address was invalid
2892	
2893	This ioctl allows userspace to retrieve the complete state of all currently
2894	pending interrupts in a single buffer. Use cases include migration
2895	and introspection. The parameter structure contains the address of a
2896	userspace buffer and its length:
2897	
2898	struct kvm_s390_irq_state {
2899		__u64 buf;
2900		__u32 flags;
2901		__u32 len;
2902		__u32 reserved[4];
2903	};
2904	
2905	Userspace passes in the above struct and for each pending interrupt a
2906	struct kvm_s390_irq is copied to the provided buffer.
2907	
2908	If -ENOBUFS is returned the buffer provided was too small and userspace
2909	may retry with a bigger buffer.
2910	
2911	4.95 KVM_S390_SET_IRQ_STATE
2912	
2913	Capability: KVM_CAP_S390_IRQ_STATE
2914	Architectures: s390
2915	Type: vcpu ioctl
2916	Parameters: struct kvm_s390_irq_state (in)
2917	Returns: 0 on success,
2918	         -EFAULT if the buffer address was invalid,
2919	         -EINVAL for an invalid buffer length (see below),
2920	         -EBUSY if there were already interrupts pending,
2921	         errors occurring when actually injecting the
2922	          interrupt. See KVM_S390_IRQ.
2923	
2924	This ioctl allows userspace to set the complete state of all cpu-local
2925	interrupts currently pending for the vcpu. It is intended for restoring
2926	interrupt state after a migration. The input parameter is a userspace buffer
2927	containing a struct kvm_s390_irq_state:
2928	
2929	struct kvm_s390_irq_state {
2930		__u64 buf;
2931		__u32 len;
2932		__u32 pad;
2933	};
2934	
2935	The userspace memory referenced by buf contains a struct kvm_s390_irq
2936	for each interrupt to be injected into the guest.
2937	If one of the interrupts could not be injected for some reason the
2938	ioctl aborts.
2939	
2940	len must be a multiple of sizeof(struct kvm_s390_irq). It must be > 0
2941	and it must not exceed (max_vcpus + 32) * sizeof(struct kvm_s390_irq),
2942	which is the maximum number of possibly pending cpu-local interrupts.
2943	
2944	4.96 KVM_SMI
2945	
2946	Capability: KVM_CAP_X86_SMM
2947	Architectures: x86
2948	Type: vcpu ioctl
2949	Parameters: none
2950	Returns: 0 on success, -1 on error
2951	
2952	Queues an SMI on the thread's vcpu.
2953	
2954	4.97 KVM_CAP_PPC_MULTITCE
2955	
2956	Capability: KVM_CAP_PPC_MULTITCE
2957	Architectures: ppc
2958	Type: vm
2959	
2960	This capability means the kernel is capable of handling hypercalls
2961	H_PUT_TCE_INDIRECT and H_STUFF_TCE without passing those into the user
2962	space. This significantly accelerates DMA operations for PPC KVM guests.
2963	User space should expect that its handlers for these hypercalls
2964	are not going to be called if user space previously registered LIOBN
2965	in KVM (via KVM_CREATE_SPAPR_TCE or similar calls).
2966	
2967	In order to enable H_PUT_TCE_INDIRECT and H_STUFF_TCE use in the guest,
2968	user space might have to advertise it for the guest. For example,
2969	IBM pSeries (sPAPR) guest starts using them if "hcall-multi-tce" is
2970	present in the "ibm,hypertas-functions" device-tree property.
2971	
2972	The hypercalls mentioned above may or may not be processed successfully
2973	in the kernel based fast path. If they can not be handled by the kernel,
2974	they will get passed on to user space. So user space still has to have
2975	an implementation for these despite the in kernel acceleration.
2976	
2977	This capability is always enabled.
2978	
2979	4.98 KVM_CREATE_SPAPR_TCE_64
2980	
2981	Capability: KVM_CAP_SPAPR_TCE_64
2982	Architectures: powerpc
2983	Type: vm ioctl
2984	Parameters: struct kvm_create_spapr_tce_64 (in)
2985	Returns: file descriptor for manipulating the created TCE table
2986	
2987	This is an extension for KVM_CAP_SPAPR_TCE which only supports 32bit
2988	windows, described in 4.62 KVM_CREATE_SPAPR_TCE
2989	
2990	This capability uses extended struct in ioctl interface:
2991	
2992	/* for KVM_CAP_SPAPR_TCE_64 */
2993	struct kvm_create_spapr_tce_64 {
2994		__u64 liobn;
2995		__u32 page_shift;
2996		__u32 flags;
2997		__u64 offset;	/* in pages */
2998		__u64 size; 	/* in pages */
2999	};
3000	
3001	The aim of extension is to support an additional bigger DMA window with
3002	a variable page size.
3003	KVM_CREATE_SPAPR_TCE_64 receives a 64bit window size, an IOMMU page shift and
3004	a bus offset of the corresponding DMA window, @size and @offset are numbers
3005	of IOMMU pages.
3006	
3007	@flags are not used at the moment.
3008	
3009	The rest of functionality is identical to KVM_CREATE_SPAPR_TCE.
3010	
3011	4.99 KVM_REINJECT_CONTROL
3012	
3013	Capability: KVM_CAP_REINJECT_CONTROL
3014	Architectures: x86
3015	Type: vm ioctl
3016	Parameters: struct kvm_reinject_control (in)
3017	Returns: 0 on success,
3018	         -EFAULT if struct kvm_reinject_control cannot be read,
3019	         -ENXIO if KVM_CREATE_PIT or KVM_CREATE_PIT2 didn't succeed earlier.
3020	
3021	i8254 (PIT) has two modes, reinject and !reinject.  The default is reinject,
3022	where KVM queues elapsed i8254 ticks and monitors completion of interrupt from
3023	vector(s) that i8254 injects.  Reinject mode dequeues a tick and injects its
3024	interrupt whenever there isn't a pending interrupt from i8254.
3025	!reinject mode injects an interrupt as soon as a tick arrives.
3026	
3027	struct kvm_reinject_control {
3028		__u8 pit_reinject;
3029		__u8 reserved[31];
3030	};
3031	
3032	pit_reinject = 0 (!reinject mode) is recommended, unless running an old
3033	operating system that uses the PIT for timing (e.g. Linux 2.4.x).
3034	
3035	4.100 KVM_PPC_CONFIGURE_V3_MMU
3036	
3037	Capability: KVM_CAP_PPC_RADIX_MMU or KVM_CAP_PPC_HASH_MMU_V3
3038	Architectures: ppc
3039	Type: vm ioctl
3040	Parameters: struct kvm_ppc_mmuv3_cfg (in)
3041	Returns: 0 on success,
3042	         -EFAULT if struct kvm_ppc_mmuv3_cfg cannot be read,
3043	         -EINVAL if the configuration is invalid
3044	
3045	This ioctl controls whether the guest will use radix or HPT (hashed
3046	page table) translation, and sets the pointer to the process table for
3047	the guest.
3048	
3049	struct kvm_ppc_mmuv3_cfg {
3050		__u64	flags;
3051		__u64	process_table;
3052	};
3053	
3054	There are two bits that can be set in flags; KVM_PPC_MMUV3_RADIX and
3055	KVM_PPC_MMUV3_GTSE.  KVM_PPC_MMUV3_RADIX, if set, configures the guest
3056	to use radix tree translation, and if clear, to use HPT translation.
3057	KVM_PPC_MMUV3_GTSE, if set and if KVM permits it, configures the guest
3058	to be able to use the global TLB and SLB invalidation instructions;
3059	if clear, the guest may not use these instructions.
3060	
3061	The process_table field specifies the address and size of the guest
3062	process table, which is in the guest's space.  This field is formatted
3063	as the second doubleword of the partition table entry, as defined in
3064	the Power ISA V3.00, Book III section 5.7.6.1.
3065	
3066	4.101 KVM_PPC_GET_RMMU_INFO
3067	
3068	Capability: KVM_CAP_PPC_RADIX_MMU
3069	Architectures: ppc
3070	Type: vm ioctl
3071	Parameters: struct kvm_ppc_rmmu_info (out)
3072	Returns: 0 on success,
3073		 -EFAULT if struct kvm_ppc_rmmu_info cannot be written,
3074		 -EINVAL if no useful information can be returned
3075	
3076	This ioctl returns a structure containing two things: (a) a list
3077	containing supported radix tree geometries, and (b) a list that maps
3078	page sizes to put in the "AP" (actual page size) field for the tlbie
3079	(TLB invalidate entry) instruction.
3080	
3081	struct kvm_ppc_rmmu_info {
3082		struct kvm_ppc_radix_geom {
3083			__u8	page_shift;
3084			__u8	level_bits[4];
3085			__u8	pad[3];
3086		}	geometries[8];
3087		__u32	ap_encodings[8];
3088	};
3089	
3090	The geometries[] field gives up to 8 supported geometries for the
3091	radix page table, in terms of the log base 2 of the smallest page
3092	size, and the number of bits indexed at each level of the tree, from
3093	the PTE level up to the PGD level in that order.  Any unused entries
3094	will have 0 in the page_shift field.
3095	
3096	The ap_encodings gives the supported page sizes and their AP field
3097	encodings, encoded with the AP value in the top 3 bits and the log
3098	base 2 of the page size in the bottom 6 bits.
3099	
3100	4.102 KVM_PPC_RESIZE_HPT_PREPARE
3101	
3102	Capability: KVM_CAP_SPAPR_RESIZE_HPT
3103	Architectures: powerpc
3104	Type: vm ioctl
3105	Parameters: struct kvm_ppc_resize_hpt (in)
3106	Returns: 0 on successful completion,
3107		 >0 if a new HPT is being prepared, the value is an estimated
3108	             number of milliseconds until preparation is complete
3109	         -EFAULT if struct kvm_reinject_control cannot be read,
3110		 -EINVAL if the supplied shift or flags are invalid
3111		 -ENOMEM if unable to allocate the new HPT
3112		 -ENOSPC if there was a hash collision when moving existing
3113	                  HPT entries to the new HPT
3114		 -EIO on other error conditions
3115	
3116	Used to implement the PAPR extension for runtime resizing of a guest's
3117	Hashed Page Table (HPT).  Specifically this starts, stops or monitors
3118	the preparation of a new potential HPT for the guest, essentially
3119	implementing the H_RESIZE_HPT_PREPARE hypercall.
3120	
3121	If called with shift > 0 when there is no pending HPT for the guest,
3122	this begins preparation of a new pending HPT of size 2^(shift) bytes.
3123	It then returns a positive integer with the estimated number of
3124	milliseconds until preparation is complete.
3125	
3126	If called when there is a pending HPT whose size does not match that
3127	requested in the parameters, discards the existing pending HPT and
3128	creates a new one as above.
3129	
3130	If called when there is a pending HPT of the size requested, will:
3131	  * If preparation of the pending HPT is already complete, return 0
3132	  * If preparation of the pending HPT has failed, return an error
3133	    code, then discard the pending HPT.
3134	  * If preparation of the pending HPT is still in progress, return an
3135	    estimated number of milliseconds until preparation is complete.
3136	
3137	If called with shift == 0, discards any currently pending HPT and
3138	returns 0 (i.e. cancels any in-progress preparation).
3139	
3140	flags is reserved for future expansion, currently setting any bits in
3141	flags will result in an -EINVAL.
3142	
3143	Normally this will be called repeatedly with the same parameters until
3144	it returns <= 0.  The first call will initiate preparation, subsequent
3145	ones will monitor preparation until it completes or fails.
3146	
3147	struct kvm_ppc_resize_hpt {
3148		__u64 flags;
3149		__u32 shift;
3150		__u32 pad;
3151	};
3152	
3153	4.103 KVM_PPC_RESIZE_HPT_COMMIT
3154	
3155	Capability: KVM_CAP_SPAPR_RESIZE_HPT
3156	Architectures: powerpc
3157	Type: vm ioctl
3158	Parameters: struct kvm_ppc_resize_hpt (in)
3159	Returns: 0 on successful completion,
3160	         -EFAULT if struct kvm_reinject_control cannot be read,
3161		 -EINVAL if the supplied shift or flags are invalid
3162		 -ENXIO is there is no pending HPT, or the pending HPT doesn't
3163	                 have the requested size
3164		 -EBUSY if the pending HPT is not fully prepared
3165		 -ENOSPC if there was a hash collision when moving existing
3166	                  HPT entries to the new HPT
3167		 -EIO on other error conditions
3168	
3169	Used to implement the PAPR extension for runtime resizing of a guest's
3170	Hashed Page Table (HPT).  Specifically this requests that the guest be
3171	transferred to working with the new HPT, essentially implementing the
3172	H_RESIZE_HPT_COMMIT hypercall.
3173	
3174	This should only be called after KVM_PPC_RESIZE_HPT_PREPARE has
3175	returned 0 with the same parameters.  In other cases
3176	KVM_PPC_RESIZE_HPT_COMMIT will return an error (usually -ENXIO or
3177	-EBUSY, though others may be possible if the preparation was started,
3178	but failed).
3179	
3180	This will have undefined effects on the guest if it has not already
3181	placed itself in a quiescent state where no vcpu will make MMU enabled
3182	memory accesses.
3183	
3184	On succsful completion, the pending HPT will become the guest's active
3185	HPT and the previous HPT will be discarded.
3186	
3187	On failure, the guest will still be operating on its previous HPT.
3188	
3189	struct kvm_ppc_resize_hpt {
3190		__u64 flags;
3191		__u32 shift;
3192		__u32 pad;
3193	};
3194	
3195	4.104 KVM_X86_GET_MCE_CAP_SUPPORTED
3196	
3197	Capability: KVM_CAP_MCE
3198	Architectures: x86
3199	Type: system ioctl
3200	Parameters: u64 mce_cap (out)
3201	Returns: 0 on success, -1 on error
3202	
3203	Returns supported MCE capabilities. The u64 mce_cap parameter
3204	has the same format as the MSR_IA32_MCG_CAP register. Supported
3205	capabilities will have the corresponding bits set.
3206	
3207	4.105 KVM_X86_SETUP_MCE
3208	
3209	Capability: KVM_CAP_MCE
3210	Architectures: x86
3211	Type: vcpu ioctl
3212	Parameters: u64 mcg_cap (in)
3213	Returns: 0 on success,
3214	         -EFAULT if u64 mcg_cap cannot be read,
3215	         -EINVAL if the requested number of banks is invalid,
3216	         -EINVAL if requested MCE capability is not supported.
3217	
3218	Initializes MCE support for use. The u64 mcg_cap parameter
3219	has the same format as the MSR_IA32_MCG_CAP register and
3220	specifies which capabilities should be enabled. The maximum
3221	supported number of error-reporting banks can be retrieved when
3222	checking for KVM_CAP_MCE. The supported capabilities can be
3223	retrieved with KVM_X86_GET_MCE_CAP_SUPPORTED.
3224	
3225	4.106 KVM_X86_SET_MCE
3226	
3227	Capability: KVM_CAP_MCE
3228	Architectures: x86
3229	Type: vcpu ioctl
3230	Parameters: struct kvm_x86_mce (in)
3231	Returns: 0 on success,
3232	         -EFAULT if struct kvm_x86_mce cannot be read,
3233	         -EINVAL if the bank number is invalid,
3234	         -EINVAL if VAL bit is not set in status field.
3235	
3236	Inject a machine check error (MCE) into the guest. The input
3237	parameter is:
3238	
3239	struct kvm_x86_mce {
3240		__u64 status;
3241		__u64 addr;
3242		__u64 misc;
3243		__u64 mcg_status;
3244		__u8 bank;
3245		__u8 pad1[7];
3246		__u64 pad2[3];
3247	};
3248	
3249	If the MCE being reported is an uncorrected error, KVM will
3250	inject it as an MCE exception into the guest. If the guest
3251	MCG_STATUS register reports that an MCE is in progress, KVM
3252	causes an KVM_EXIT_SHUTDOWN vmexit.
3253	
3254	Otherwise, if the MCE is a corrected error, KVM will just
3255	store it in the corresponding bank (provided this bank is
3256	not holding a previously reported uncorrected error).
3257	
3258	4.107 KVM_S390_GET_CMMA_BITS
3259	
3260	Capability: KVM_CAP_S390_CMMA_MIGRATION
3261	Architectures: s390
3262	Type: vm ioctl
3263	Parameters: struct kvm_s390_cmma_log (in, out)
3264	Returns: 0 on success, a negative value on error
3265	
3266	This ioctl is used to get the values of the CMMA bits on the s390
3267	architecture. It is meant to be used in two scenarios:
3268	- During live migration to save the CMMA values. Live migration needs
3269	  to be enabled via the KVM_REQ_START_MIGRATION VM property.
3270	- To non-destructively peek at the CMMA values, with the flag
3271	  KVM_S390_CMMA_PEEK set.
3272	
3273	The ioctl takes parameters via the kvm_s390_cmma_log struct. The desired
3274	values are written to a buffer whose location is indicated via the "values"
3275	member in the kvm_s390_cmma_log struct.  The values in the input struct are
3276	also updated as needed.
3277	Each CMMA value takes up one byte.
3278	
3279	struct kvm_s390_cmma_log {
3280		__u64 start_gfn;
3281		__u32 count;
3282		__u32 flags;
3283		union {
3284			__u64 remaining;
3285			__u64 mask;
3286		};
3287		__u64 values;
3288	};
3289	
3290	start_gfn is the number of the first guest frame whose CMMA values are
3291	to be retrieved,
3292	
3293	count is the length of the buffer in bytes,
3294	
3295	values points to the buffer where the result will be written to.
3296	
3297	If count is greater than KVM_S390_SKEYS_MAX, then it is considered to be
3298	KVM_S390_SKEYS_MAX. KVM_S390_SKEYS_MAX is re-used for consistency with
3299	other ioctls.
3300	
3301	The result is written in the buffer pointed to by the field values, and
3302	the values of the input parameter are updated as follows.
3303	
3304	Depending on the flags, different actions are performed. The only
3305	supported flag so far is KVM_S390_CMMA_PEEK.
3306	
3307	The default behaviour if KVM_S390_CMMA_PEEK is not set is:
3308	start_gfn will indicate the first page frame whose CMMA bits were dirty.
3309	It is not necessarily the same as the one passed as input, as clean pages
3310	are skipped.
3311	
3312	count will indicate the number of bytes actually written in the buffer.
3313	It can (and very often will) be smaller than the input value, since the
3314	buffer is only filled until 16 bytes of clean values are found (which
3315	are then not copied in the buffer). Since a CMMA migration block needs
3316	the base address and the length, for a total of 16 bytes, we will send
3317	back some clean data if there is some dirty data afterwards, as long as
3318	the size of the clean data does not exceed the size of the header. This
3319	allows to minimize the amount of data to be saved or transferred over
3320	the network at the expense of more roundtrips to userspace. The next
3321	invocation of the ioctl will skip over all the clean values, saving
3322	potentially more than just the 16 bytes we found.
3323	
3324	If KVM_S390_CMMA_PEEK is set:
3325	the existing storage attributes are read even when not in migration
3326	mode, and no other action is performed;
3327	
3328	the output start_gfn will be equal to the input start_gfn,
3329	
3330	the output count will be equal to the input count, except if the end of
3331	memory has been reached.
3332	
3333	In both cases:
3334	the field "remaining" will indicate the total number of dirty CMMA values
3335	still remaining, or 0 if KVM_S390_CMMA_PEEK is set and migration mode is
3336	not enabled.
3337	
3338	mask is unused.
3339	
3340	values points to the userspace buffer where the result will be stored.
3341	
3342	This ioctl can fail with -ENOMEM if not enough memory can be allocated to
3343	complete the task, with -ENXIO if CMMA is not enabled, with -EINVAL if
3344	KVM_S390_CMMA_PEEK is not set but migration mode was not enabled, with
3345	-EFAULT if the userspace address is invalid or if no page table is
3346	present for the addresses (e.g. when using hugepages).
3347	
3348	4.108 KVM_S390_SET_CMMA_BITS
3349	
3350	Capability: KVM_CAP_S390_CMMA_MIGRATION
3351	Architectures: s390
3352	Type: vm ioctl
3353	Parameters: struct kvm_s390_cmma_log (in)
3354	Returns: 0 on success, a negative value on error
3355	
3356	This ioctl is used to set the values of the CMMA bits on the s390
3357	architecture. It is meant to be used during live migration to restore
3358	the CMMA values, but there are no restrictions on its use.
3359	The ioctl takes parameters via the kvm_s390_cmma_values struct.
3360	Each CMMA value takes up one byte.
3361	
3362	struct kvm_s390_cmma_log {
3363		__u64 start_gfn;
3364		__u32 count;
3365		__u32 flags;
3366		union {
3367			__u64 remaining;
3368			__u64 mask;
3369		};
3370		__u64 values;
3371	};
3372	
3373	start_gfn indicates the starting guest frame number,
3374	
3375	count indicates how many values are to be considered in the buffer,
3376	
3377	flags is not used and must be 0.
3378	
3379	mask indicates which PGSTE bits are to be considered.
3380	
3381	remaining is not used.
3382	
3383	values points to the buffer in userspace where to store the values.
3384	
3385	This ioctl can fail with -ENOMEM if not enough memory can be allocated to
3386	complete the task, with -ENXIO if CMMA is not enabled, with -EINVAL if
3387	the count field is too large (e.g. more than KVM_S390_CMMA_SIZE_MAX) or
3388	if the flags field was not 0, with -EFAULT if the userspace address is
3389	invalid, if invalid pages are written to (e.g. after the end of memory)
3390	or if no page table is present for the addresses (e.g. when using
3391	hugepages).
3392	
3393	5. The kvm_run structure
3394	------------------------
3395	
3396	Application code obtains a pointer to the kvm_run structure by
3397	mmap()ing a vcpu fd.  From that point, application code can control
3398	execution by changing fields in kvm_run prior to calling the KVM_RUN
3399	ioctl, and obtain information about the reason KVM_RUN returned by
3400	looking up structure members.
3401	
3402	struct kvm_run {
3403		/* in */
3404		__u8 request_interrupt_window;
3405	
3406	Request that KVM_RUN return when it becomes possible to inject external
3407	interrupts into the guest.  Useful in conjunction with KVM_INTERRUPT.
3408	
3409		__u8 immediate_exit;
3410	
3411	This field is polled once when KVM_RUN starts; if non-zero, KVM_RUN
3412	exits immediately, returning -EINTR.  In the common scenario where a
3413	signal is used to "kick" a VCPU out of KVM_RUN, this field can be used
3414	to avoid usage of KVM_SET_SIGNAL_MASK, which has worse scalability.
3415	Rather than blocking the signal outside KVM_RUN, userspace can set up
3416	a signal handler that sets run->immediate_exit to a non-zero value.
3417	
3418	This field is ignored if KVM_CAP_IMMEDIATE_EXIT is not available.
3419	
3420		__u8 padding1[6];
3421	
3422		/* out */
3423		__u32 exit_reason;
3424	
3425	When KVM_RUN has returned successfully (return value 0), this informs
3426	application code why KVM_RUN has returned.  Allowable values for this
3427	field are detailed below.
3428	
3429		__u8 ready_for_interrupt_injection;
3430	
3431	If request_interrupt_window has been specified, this field indicates
3432	an interrupt can be injected now with KVM_INTERRUPT.
3433	
3434		__u8 if_flag;
3435	
3436	The value of the current interrupt flag.  Only valid if in-kernel
3437	local APIC is not used.
3438	
3439		__u16 flags;
3440	
3441	More architecture-specific flags detailing state of the VCPU that may
3442	affect the device's behavior.  The only currently defined flag is
3443	KVM_RUN_X86_SMM, which is valid on x86 machines and is set if the
3444	VCPU is in system management mode.
3445	
3446		/* in (pre_kvm_run), out (post_kvm_run) */
3447		__u64 cr8;
3448	
3449	The value of the cr8 register.  Only valid if in-kernel local APIC is
3450	not used.  Both input and output.
3451	
3452		__u64 apic_base;
3453	
3454	The value of the APIC BASE msr.  Only valid if in-kernel local
3455	APIC is not used.  Both input and output.
3456	
3457		union {
3458			/* KVM_EXIT_UNKNOWN */
3459			struct {
3460				__u64 hardware_exit_reason;
3461			} hw;
3462	
3463	If exit_reason is KVM_EXIT_UNKNOWN, the vcpu has exited due to unknown
3464	reasons.  Further architecture-specific information is available in
3465	hardware_exit_reason.
3466	
3467			/* KVM_EXIT_FAIL_ENTRY */
3468			struct {
3469				__u64 hardware_entry_failure_reason;
3470			} fail_entry;
3471	
3472	If exit_reason is KVM_EXIT_FAIL_ENTRY, the vcpu could not be run due
3473	to unknown reasons.  Further architecture-specific information is
3474	available in hardware_entry_failure_reason.
3475	
3476			/* KVM_EXIT_EXCEPTION */
3477			struct {
3478				__u32 exception;
3479				__u32 error_code;
3480			} ex;
3481	
3482	Unused.
3483	
3484			/* KVM_EXIT_IO */
3485			struct {
3486	#define KVM_EXIT_IO_IN  0
3487	#define KVM_EXIT_IO_OUT 1
3488				__u8 direction;
3489				__u8 size; /* bytes */
3490				__u16 port;
3491				__u32 count;
3492				__u64 data_offset; /* relative to kvm_run start */
3493			} io;
3494	
3495	If exit_reason is KVM_EXIT_IO, then the vcpu has
3496	executed a port I/O instruction which could not be satisfied by kvm.
3497	data_offset describes where the data is located (KVM_EXIT_IO_OUT) or
3498	where kvm expects application code to place the data for the next
3499	KVM_RUN invocation (KVM_EXIT_IO_IN).  Data format is a packed array.
3500	
3501			/* KVM_EXIT_DEBUG */
3502			struct {
3503				struct kvm_debug_exit_arch arch;
3504			} debug;
3505	
3506	If the exit_reason is KVM_EXIT_DEBUG, then a vcpu is processing a debug event
3507	for which architecture specific information is returned.
3508	
3509			/* KVM_EXIT_MMIO */
3510			struct {
3511				__u64 phys_addr;
3512				__u8  data[8];
3513				__u32 len;
3514				__u8  is_write;
3515			} mmio;
3516	
3517	If exit_reason is KVM_EXIT_MMIO, then the vcpu has
3518	executed a memory-mapped I/O instruction which could not be satisfied
3519	by kvm.  The 'data' member contains the written data if 'is_write' is
3520	true, and should be filled by application code otherwise.
3521	
3522	The 'data' member contains, in its first 'len' bytes, the value as it would
3523	appear if the VCPU performed a load or store of the appropriate width directly
3524	to the byte array.
3525	
3526	NOTE: For KVM_EXIT_IO, KVM_EXIT_MMIO, KVM_EXIT_OSI, KVM_EXIT_PAPR and
3527	      KVM_EXIT_EPR the corresponding
3528	operations are complete (and guest state is consistent) only after userspace
3529	has re-entered the kernel with KVM_RUN.  The kernel side will first finish
3530	incomplete operations and then check for pending signals.  Userspace
3531	can re-enter the guest with an unmasked signal pending to complete
3532	pending operations.
3533	
3534			/* KVM_EXIT_HYPERCALL */
3535			struct {
3536				__u64 nr;
3537				__u64 args[6];
3538				__u64 ret;
3539				__u32 longmode;
3540				__u32 pad;
3541			} hypercall;
3542	
3543	Unused.  This was once used for 'hypercall to userspace'.  To implement
3544	such functionality, use KVM_EXIT_IO (x86) or KVM_EXIT_MMIO (all except s390).
3545	Note KVM_EXIT_IO is significantly faster than KVM_EXIT_MMIO.
3546	
3547			/* KVM_EXIT_TPR_ACCESS */
3548			struct {
3549				__u64 rip;
3550				__u32 is_write;
3551				__u32 pad;
3552			} tpr_access;
3553	
3554	To be documented (KVM_TPR_ACCESS_REPORTING).
3555	
3556			/* KVM_EXIT_S390_SIEIC */
3557			struct {
3558				__u8 icptcode;
3559				__u64 mask; /* psw upper half */
3560				__u64 addr; /* psw lower half */
3561				__u16 ipa;
3562				__u32 ipb;
3563			} s390_sieic;
3564	
3565	s390 specific.
3566	
3567			/* KVM_EXIT_S390_RESET */
3568	#define KVM_S390_RESET_POR       1
3569	#define KVM_S390_RESET_CLEAR     2
3570	#define KVM_S390_RESET_SUBSYSTEM 4
3571	#define KVM_S390_RESET_CPU_INIT  8
3572	#define KVM_S390_RESET_IPL       16
3573			__u64 s390_reset_flags;
3574	
3575	s390 specific.
3576	
3577			/* KVM_EXIT_S390_UCONTROL */
3578			struct {
3579				__u64 trans_exc_code;
3580				__u32 pgm_code;
3581			} s390_ucontrol;
3582	
3583	s390 specific. A page fault has occurred for a user controlled virtual
3584	machine (KVM_VM_S390_UNCONTROL) on it's host page table that cannot be
3585	resolved by the kernel.
3586	The program code and the translation exception code that were placed
3587	in the cpu's lowcore are presented here as defined by the z Architecture
3588	Principles of Operation Book in the Chapter for Dynamic Address Translation
3589	(DAT)
3590	
3591			/* KVM_EXIT_DCR */
3592			struct {
3593				__u32 dcrn;
3594				__u32 data;
3595				__u8  is_write;
3596			} dcr;
3597	
3598	Deprecated - was used for 440 KVM.
3599	
3600			/* KVM_EXIT_OSI */
3601			struct {
3602				__u64 gprs[32];
3603			} osi;
3604	
3605	MOL uses a special hypercall interface it calls 'OSI'. To enable it, we catch
3606	hypercalls and exit with this exit struct that contains all the guest gprs.
3607	
3608	If exit_reason is KVM_EXIT_OSI, then the vcpu has triggered such a hypercall.
3609	Userspace can now handle the hypercall and when it's done modify the gprs as
3610	necessary. Upon guest entry all guest GPRs will then be replaced by the values
3611	in this struct.
3612	
3613			/* KVM_EXIT_PAPR_HCALL */
3614			struct {
3615				__u64 nr;
3616				__u64 ret;
3617				__u64 args[9];
3618			} papr_hcall;
3619	
3620	This is used on 64-bit PowerPC when emulating a pSeries partition,
3621	e.g. with the 'pseries' machine type in qemu.  It occurs when the
3622	guest does a hypercall using the 'sc 1' instruction.  The 'nr' field
3623	contains the hypercall number (from the guest R3), and 'args' contains
3624	the arguments (from the guest R4 - R12).  Userspace should put the
3625	return code in 'ret' and any extra returned values in args[].
3626	The possible hypercalls are defined in the Power Architecture Platform
3627	Requirements (PAPR) document available from www.power.org (free
3628	developer registration required to access it).
3629	
3630			/* KVM_EXIT_S390_TSCH */
3631			struct {
3632				__u16 subchannel_id;
3633				__u16 subchannel_nr;
3634				__u32 io_int_parm;
3635				__u32 io_int_word;
3636				__u32 ipb;
3637				__u8 dequeued;
3638			} s390_tsch;
3639	
3640	s390 specific. This exit occurs when KVM_CAP_S390_CSS_SUPPORT has been enabled
3641	and TEST SUBCHANNEL was intercepted. If dequeued is set, a pending I/O
3642	interrupt for the target subchannel has been dequeued and subchannel_id,
3643	subchannel_nr, io_int_parm and io_int_word contain the parameters for that
3644	interrupt. ipb is needed for instruction parameter decoding.
3645	
3646			/* KVM_EXIT_EPR */
3647			struct {
3648				__u32 epr;
3649			} epr;
3650	
3651	On FSL BookE PowerPC chips, the interrupt controller has a fast patch
3652	interrupt acknowledge path to the core. When the core successfully
3653	delivers an interrupt, it automatically populates the EPR register with
3654	the interrupt vector number and acknowledges the interrupt inside
3655	the interrupt controller.
3656	
3657	In case the interrupt controller lives in user space, we need to do
3658	the interrupt acknowledge cycle through it to fetch the next to be
3659	delivered interrupt vector using this exit.
3660	
3661	It gets triggered whenever both KVM_CAP_PPC_EPR are enabled and an
3662	external interrupt has just been delivered into the guest. User space
3663	should put the acknowledged interrupt vector into the 'epr' field.
3664	
3665			/* KVM_EXIT_SYSTEM_EVENT */
3666			struct {
3667	#define KVM_SYSTEM_EVENT_SHUTDOWN       1
3668	#define KVM_SYSTEM_EVENT_RESET          2
3669	#define KVM_SYSTEM_EVENT_CRASH          3
3670				__u32 type;
3671				__u64 flags;
3672			} system_event;
3673	
3674	If exit_reason is KVM_EXIT_SYSTEM_EVENT then the vcpu has triggered
3675	a system-level event using some architecture specific mechanism (hypercall
3676	or some special instruction). In case of ARM/ARM64, this is triggered using
3677	HVC instruction based PSCI call from the vcpu. The 'type' field describes
3678	the system-level event type. The 'flags' field describes architecture
3679	specific flags for the system-level event.
3680	
3681	Valid values for 'type' are:
3682	  KVM_SYSTEM_EVENT_SHUTDOWN -- the guest has requested a shutdown of the
3683	   VM. Userspace is not obliged to honour this, and if it does honour
3684	   this does not need to destroy the VM synchronously (ie it may call
3685	   KVM_RUN again before shutdown finally occurs).
3686	  KVM_SYSTEM_EVENT_RESET -- the guest has requested a reset of the VM.
3687	   As with SHUTDOWN, userspace can choose to ignore the request, or
3688	   to schedule the reset to occur in the future and may call KVM_RUN again.
3689	  KVM_SYSTEM_EVENT_CRASH -- the guest crash occurred and the guest
3690	   has requested a crash condition maintenance. Userspace can choose
3691	   to ignore the request, or to gather VM memory core dump and/or
3692	   reset/shutdown of the VM.
3693	
3694			/* KVM_EXIT_IOAPIC_EOI */
3695			struct {
3696				__u8 vector;
3697			} eoi;
3698	
3699	Indicates that the VCPU's in-kernel local APIC received an EOI for a
3700	level-triggered IOAPIC interrupt.  This exit only triggers when the
3701	IOAPIC is implemented in userspace (i.e. KVM_CAP_SPLIT_IRQCHIP is enabled);
3702	the userspace IOAPIC should process the EOI and retrigger the interrupt if
3703	it is still asserted.  Vector is the LAPIC interrupt vector for which the
3704	EOI was received.
3705	
3706			struct kvm_hyperv_exit {
3707	#define KVM_EXIT_HYPERV_SYNIC          1
3708	#define KVM_EXIT_HYPERV_HCALL          2
3709				__u32 type;
3710				union {
3711					struct {
3712						__u32 msr;
3713						__u64 control;
3714						__u64 evt_page;
3715						__u64 msg_page;
3716					} synic;
3717					struct {
3718						__u64 input;
3719						__u64 result;
3720						__u64 params[2];
3721					} hcall;
3722				} u;
3723			};
3724			/* KVM_EXIT_HYPERV */
3725	                struct kvm_hyperv_exit hyperv;
3726	Indicates that the VCPU exits into userspace to process some tasks
3727	related to Hyper-V emulation.
3728	Valid values for 'type' are:
3729		KVM_EXIT_HYPERV_SYNIC -- synchronously notify user-space about
3730	Hyper-V SynIC state change. Notification is used to remap SynIC
3731	event/message pages and to enable/disable SynIC messages/events processing
3732	in userspace.
3733	
3734			/* Fix the size of the union. */
3735			char padding[256];
3736		};
3737	
3738		/*
3739		 * shared registers between kvm and userspace.
3740		 * kvm_valid_regs specifies the register classes set by the host
3741		 * kvm_dirty_regs specified the register classes dirtied by userspace
3742		 * struct kvm_sync_regs is architecture specific, as well as the
3743		 * bits for kvm_valid_regs and kvm_dirty_regs
3744		 */
3745		__u64 kvm_valid_regs;
3746		__u64 kvm_dirty_regs;
3747		union {
3748			struct kvm_sync_regs regs;
3749			char padding[1024];
3750		} s;
3751	
3752	If KVM_CAP_SYNC_REGS is defined, these fields allow userspace to access
3753	certain guest registers without having to call SET/GET_*REGS. Thus we can
3754	avoid some system call overhead if userspace has to handle the exit.
3755	Userspace can query the validity of the structure by checking
3756	kvm_valid_regs for specific bits. These bits are architecture specific
3757	and usually define the validity of a groups of registers. (e.g. one bit
3758	 for general purpose registers)
3759	
3760	Please note that the kernel is allowed to use the kvm_run structure as the
3761	primary storage for certain register types. Therefore, the kernel may use the
3762	values in kvm_run even if the corresponding bit in kvm_dirty_regs is not set.
3763	
3764	};
3765	
3766	
3767	
3768	6. Capabilities that can be enabled on vCPUs
3769	--------------------------------------------
3770	
3771	There are certain capabilities that change the behavior of the virtual CPU or
3772	the virtual machine when enabled. To enable them, please see section 4.37.
3773	Below you can find a list of capabilities and what their effect on the vCPU or
3774	the virtual machine is when enabling them.
3775	
3776	The following information is provided along with the description:
3777	
3778	  Architectures: which instruction set architectures provide this ioctl.
3779	      x86 includes both i386 and x86_64.
3780	
3781	  Target: whether this is a per-vcpu or per-vm capability.
3782	
3783	  Parameters: what parameters are accepted by the capability.
3784	
3785	  Returns: the return value.  General error numbers (EBADF, ENOMEM, EINVAL)
3786	      are not detailed, but errors with specific meanings are.
3787	
3788	
3789	6.1 KVM_CAP_PPC_OSI
3790	
3791	Architectures: ppc
3792	Target: vcpu
3793	Parameters: none
3794	Returns: 0 on success; -1 on error
3795	
3796	This capability enables interception of OSI hypercalls that otherwise would
3797	be treated as normal system calls to be injected into the guest. OSI hypercalls
3798	were invented by Mac-on-Linux to have a standardized communication mechanism
3799	between the guest and the host.
3800	
3801	When this capability is enabled, KVM_EXIT_OSI can occur.
3802	
3803	
3804	6.2 KVM_CAP_PPC_PAPR
3805	
3806	Architectures: ppc
3807	Target: vcpu
3808	Parameters: none
3809	Returns: 0 on success; -1 on error
3810	
3811	This capability enables interception of PAPR hypercalls. PAPR hypercalls are
3812	done using the hypercall instruction "sc 1".
3813	
3814	It also sets the guest privilege level to "supervisor" mode. Usually the guest
3815	runs in "hypervisor" privilege mode with a few missing features.
3816	
3817	In addition to the above, it changes the semantics of SDR1. In this mode, the
3818	HTAB address part of SDR1 contains an HVA instead of a GPA, as PAPR keeps the
3819	HTAB invisible to the guest.
3820	
3821	When this capability is enabled, KVM_EXIT_PAPR_HCALL can occur.
3822	
3823	
3824	6.3 KVM_CAP_SW_TLB
3825	
3826	Architectures: ppc
3827	Target: vcpu
3828	Parameters: args[0] is the address of a struct kvm_config_tlb
3829	Returns: 0 on success; -1 on error
3830	
3831	struct kvm_config_tlb {
3832		__u64 params;
3833		__u64 array;
3834		__u32 mmu_type;
3835		__u32 array_len;
3836	};
3837	
3838	Configures the virtual CPU's TLB array, establishing a shared memory area
3839	between userspace and KVM.  The "params" and "array" fields are userspace
3840	addresses of mmu-type-specific data structures.  The "array_len" field is an
3841	safety mechanism, and should be set to the size in bytes of the memory that
3842	userspace has reserved for the array.  It must be at least the size dictated
3843	by "mmu_type" and "params".
3844	
3845	While KVM_RUN is active, the shared region is under control of KVM.  Its
3846	contents are undefined, and any modification by userspace results in
3847	boundedly undefined behavior.
3848	
3849	On return from KVM_RUN, the shared region will reflect the current state of
3850	the guest's TLB.  If userspace makes any changes, it must call KVM_DIRTY_TLB
3851	to tell KVM which entries have been changed, prior to calling KVM_RUN again
3852	on this vcpu.
3853	
3854	For mmu types KVM_MMU_FSL_BOOKE_NOHV and KVM_MMU_FSL_BOOKE_HV:
3855	 - The "params" field is of type "struct kvm_book3e_206_tlb_params".
3856	 - The "array" field points to an array of type "struct
3857	   kvm_book3e_206_tlb_entry".
3858	 - The array consists of all entries in the first TLB, followed by all
3859	   entries in the second TLB.
3860	 - Within a TLB, entries are ordered first by increasing set number.  Within a
3861	   set, entries are ordered by way (increasing ESEL).
3862	 - The hash for determining set number in TLB0 is: (MAS2 >> 12) & (num_sets - 1)
3863	   where "num_sets" is the tlb_sizes[] value divided by the tlb_ways[] value.
3864	 - The tsize field of mas1 shall be set to 4K on TLB0, even though the
3865	   hardware ignores this value for TLB0.
3866	
3867	6.4 KVM_CAP_S390_CSS_SUPPORT
3868	
3869	Architectures: s390
3870	Target: vcpu
3871	Parameters: none
3872	Returns: 0 on success; -1 on error
3873	
3874	This capability enables support for handling of channel I/O instructions.
3875	
3876	TEST PENDING INTERRUPTION and the interrupt portion of TEST SUBCHANNEL are
3877	handled in-kernel, while the other I/O instructions are passed to userspace.
3878	
3879	When this capability is enabled, KVM_EXIT_S390_TSCH will occur on TEST
3880	SUBCHANNEL intercepts.
3881	
3882	Note that even though this capability is enabled per-vcpu, the complete
3883	virtual machine is affected.
3884	
3885	6.5 KVM_CAP_PPC_EPR
3886	
3887	Architectures: ppc
3888	Target: vcpu
3889	Parameters: args[0] defines whether the proxy facility is active
3890	Returns: 0 on success; -1 on error
3891	
3892	This capability enables or disables the delivery of interrupts through the
3893	external proxy facility.
3894	
3895	When enabled (args[0] != 0), every time the guest gets an external interrupt
3896	delivered, it automatically exits into user space with a KVM_EXIT_EPR exit
3897	to receive the topmost interrupt vector.
3898	
3899	When disabled (args[0] == 0), behavior is as if this facility is unsupported.
3900	
3901	When this capability is enabled, KVM_EXIT_EPR can occur.
3902	
3903	6.6 KVM_CAP_IRQ_MPIC
3904	
3905	Architectures: ppc
3906	Parameters: args[0] is the MPIC device fd
3907	            args[1] is the MPIC CPU number for this vcpu
3908	
3909	This capability connects the vcpu to an in-kernel MPIC device.
3910	
3911	6.7 KVM_CAP_IRQ_XICS
3912	
3913	Architectures: ppc
3914	Target: vcpu
3915	Parameters: args[0] is the XICS device fd
3916	            args[1] is the XICS CPU number (server ID) for this vcpu
3917	
3918	This capability connects the vcpu to an in-kernel XICS device.
3919	
3920	6.8 KVM_CAP_S390_IRQCHIP
3921	
3922	Architectures: s390
3923	Target: vm
3924	Parameters: none
3925	
3926	This capability enables the in-kernel irqchip for s390. Please refer to
3927	"4.24 KVM_CREATE_IRQCHIP" for details.
3928	
3929	6.9 KVM_CAP_MIPS_FPU
3930	
3931	Architectures: mips
3932	Target: vcpu
3933	Parameters: args[0] is reserved for future use (should be 0).
3934	
3935	This capability allows the use of the host Floating Point Unit by the guest. It
3936	allows the Config1.FP bit to be set to enable the FPU in the guest. Once this is
3937	done the KVM_REG_MIPS_FPR_* and KVM_REG_MIPS_FCR_* registers can be accessed
3938	(depending on the current guest FPU register mode), and the Status.FR,
3939	Config5.FRE bits are accessible via the KVM API and also from the guest,
3940	depending on them being supported by the FPU.
3941	
3942	6.10 KVM_CAP_MIPS_MSA
3943	
3944	Architectures: mips
3945	Target: vcpu
3946	Parameters: args[0] is reserved for future use (should be 0).
3947	
3948	This capability allows the use of the MIPS SIMD Architecture (MSA) by the guest.
3949	It allows the Config3.MSAP bit to be set to enable the use of MSA by the guest.
3950	Once this is done the KVM_REG_MIPS_VEC_* and KVM_REG_MIPS_MSA_* registers can be
3951	accessed, and the Config5.MSAEn bit is accessible via the KVM API and also from
3952	the guest.
3953	
3954	7. Capabilities that can be enabled on VMs
3955	------------------------------------------
3956	
3957	There are certain capabilities that change the behavior of the virtual
3958	machine when enabled. To enable them, please see section 4.37. Below
3959	you can find a list of capabilities and what their effect on the VM
3960	is when enabling them.
3961	
3962	The following information is provided along with the description:
3963	
3964	  Architectures: which instruction set architectures provide this ioctl.
3965	      x86 includes both i386 and x86_64.
3966	
3967	  Parameters: what parameters are accepted by the capability.
3968	
3969	  Returns: the return value.  General error numbers (EBADF, ENOMEM, EINVAL)
3970	      are not detailed, but errors with specific meanings are.
3971	
3972	
3973	7.1 KVM_CAP_PPC_ENABLE_HCALL
3974	
3975	Architectures: ppc
3976	Parameters: args[0] is the sPAPR hcall number
3977		    args[1] is 0 to disable, 1 to enable in-kernel handling
3978	
3979	This capability controls whether individual sPAPR hypercalls (hcalls)
3980	get handled by the kernel or not.  Enabling or disabling in-kernel
3981	handling of an hcall is effective across the VM.  On creation, an
3982	initial set of hcalls are enabled for in-kernel handling, which
3983	consists of those hcalls for which in-kernel handlers were implemented
3984	before this capability was implemented.  If disabled, the kernel will
3985	not to attempt to handle the hcall, but will always exit to userspace
3986	to handle it.  Note that it may not make sense to enable some and
3987	disable others of a group of related hcalls, but KVM does not prevent
3988	userspace from doing that.
3989	
3990	If the hcall number specified is not one that has an in-kernel
3991	implementation, the KVM_ENABLE_CAP ioctl will fail with an EINVAL
3992	error.
3993	
3994	7.2 KVM_CAP_S390_USER_SIGP
3995	
3996	Architectures: s390
3997	Parameters: none
3998	
3999	This capability controls which SIGP orders will be handled completely in user
4000	space. With this capability enabled, all fast orders will be handled completely
4001	in the kernel:
4002	- SENSE
4003	- SENSE RUNNING
4004	- EXTERNAL CALL
4005	- EMERGENCY SIGNAL
4006	- CONDITIONAL EMERGENCY SIGNAL
4007	
4008	All other orders will be handled completely in user space.
4009	
4010	Only privileged operation exceptions will be checked for in the kernel (or even
4011	in the hardware prior to interception). If this capability is not enabled, the
4012	old way of handling SIGP orders is used (partially in kernel and user space).
4013	
4014	7.3 KVM_CAP_S390_VECTOR_REGISTERS
4015	
4016	Architectures: s390
4017	Parameters: none
4018	Returns: 0 on success, negative value on error
4019	
4020	Allows use of the vector registers introduced with z13 processor, and
4021	provides for the synchronization between host and user space.  Will
4022	return -EINVAL if the machine does not support vectors.
4023	
4024	7.4 KVM_CAP_S390_USER_STSI
4025	
4026	Architectures: s390
4027	Parameters: none
4028	
4029	This capability allows post-handlers for the STSI instruction. After
4030	initial handling in the kernel, KVM exits to user space with
4031	KVM_EXIT_S390_STSI to allow user space to insert further data.
4032	
4033	Before exiting to userspace, kvm handlers should fill in s390_stsi field of
4034	vcpu->run:
4035	struct {
4036		__u64 addr;
4037		__u8 ar;
4038		__u8 reserved;
4039		__u8 fc;
4040		__u8 sel1;
4041		__u16 sel2;
4042	} s390_stsi;
4043	
4044	@addr - guest address of STSI SYSIB
4045	@fc   - function code
4046	@sel1 - selector 1
4047	@sel2 - selector 2
4048	@ar   - access register number
4049	
4050	KVM handlers should exit to userspace with rc = -EREMOTE.
4051	
4052	7.5 KVM_CAP_SPLIT_IRQCHIP
4053	
4054	Architectures: x86
4055	Parameters: args[0] - number of routes reserved for userspace IOAPICs
4056	Returns: 0 on success, -1 on error
4057	
4058	Create a local apic for each processor in the kernel. This can be used
4059	instead of KVM_CREATE_IRQCHIP if the userspace VMM wishes to emulate the
4060	IOAPIC and PIC (and also the PIT, even though this has to be enabled
4061	separately).
4062	
4063	This capability also enables in kernel routing of interrupt requests;
4064	when KVM_CAP_SPLIT_IRQCHIP only routes of KVM_IRQ_ROUTING_MSI type are
4065	used in the IRQ routing table.  The first args[0] MSI routes are reserved
4066	for the IOAPIC pins.  Whenever the LAPIC receives an EOI for these routes,
4067	a KVM_EXIT_IOAPIC_EOI vmexit will be reported to userspace.
4068	
4069	Fails if VCPU has already been created, or if the irqchip is already in the
4070	kernel (i.e. KVM_CREATE_IRQCHIP has already been called).
4071	
4072	7.6 KVM_CAP_S390_RI
4073	
4074	Architectures: s390
4075	Parameters: none
4076	
4077	Allows use of runtime-instrumentation introduced with zEC12 processor.
4078	Will return -EINVAL if the machine does not support runtime-instrumentation.
4079	Will return -EBUSY if a VCPU has already been created.
4080	
4081	7.7 KVM_CAP_X2APIC_API
4082	
4083	Architectures: x86
4084	Parameters: args[0] - features that should be enabled
4085	Returns: 0 on success, -EINVAL when args[0] contains invalid features
4086	
4087	Valid feature flags in args[0] are
4088	
4089	#define KVM_X2APIC_API_USE_32BIT_IDS            (1ULL << 0)
4090	#define KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK  (1ULL << 1)
4091	
4092	Enabling KVM_X2APIC_API_USE_32BIT_IDS changes the behavior of
4093	KVM_SET_GSI_ROUTING, KVM_SIGNAL_MSI, KVM_SET_LAPIC, and KVM_GET_LAPIC,
4094	allowing the use of 32-bit APIC IDs.  See KVM_CAP_X2APIC_API in their
4095	respective sections.
4096	
4097	KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK must be enabled for x2APIC to work
4098	in logical mode or with more than 255 VCPUs.  Otherwise, KVM treats 0xff
4099	as a broadcast even in x2APIC mode in order to support physical x2APIC
4100	without interrupt remapping.  This is undesirable in logical mode,
4101	where 0xff represents CPUs 0-7 in cluster 0.
4102	
4103	7.8 KVM_CAP_S390_USER_INSTR0
4104	
4105	Architectures: s390
4106	Parameters: none
4107	
4108	With this capability enabled, all illegal instructions 0x0000 (2 bytes) will
4109	be intercepted and forwarded to user space. User space can use this
4110	mechanism e.g. to realize 2-byte software breakpoints. The kernel will
4111	not inject an operating exception for these instructions, user space has
4112	to take care of that.
4113	
4114	This capability can be enabled dynamically even if VCPUs were already
4115	created and are running.
4116	
4117	7.9 KVM_CAP_S390_GS
4118	
4119	Architectures: s390
4120	Parameters: none
4121	Returns: 0 on success; -EINVAL if the machine does not support
4122		 guarded storage; -EBUSY if a VCPU has already been created.
4123	
4124	Allows use of guarded storage for the KVM guest.
4125	
4126	7.10 KVM_CAP_S390_AIS
4127	
4128	Architectures: s390
4129	Parameters: none
4130	
4131	Allow use of adapter-interruption suppression.
4132	Returns: 0 on success; -EBUSY if a VCPU has already been created.
4133	
4134	7.11 KVM_CAP_PPC_SMT
4135	
4136	Architectures: ppc
4137	Parameters: vsmt_mode, flags
4138	
4139	Enabling this capability on a VM provides userspace with a way to set
4140	the desired virtual SMT mode (i.e. the number of virtual CPUs per
4141	virtual core).  The virtual SMT mode, vsmt_mode, must be a power of 2
4142	between 1 and 8.  On POWER8, vsmt_mode must also be no greater than
4143	the number of threads per subcore for the host.  Currently flags must
4144	be 0.  A successful call to enable this capability will result in
4145	vsmt_mode being returned when the KVM_CAP_PPC_SMT capability is
4146	subsequently queried for the VM.  This capability is only supported by
4147	HV KVM, and can only be set before any VCPUs have been created.
4148	The KVM_CAP_PPC_SMT_POSSIBLE capability indicates which virtual SMT
4149	modes are available.
4150	
4151	7.12 KVM_CAP_PPC_FWNMI
4152	
4153	Architectures: ppc
4154	Parameters: none
4155	
4156	With this capability a machine check exception in the guest address
4157	space will cause KVM to exit the guest with NMI exit reason. This
4158	enables QEMU to build error log and branch to guest kernel registered
4159	machine check handling routine. Without this capability KVM will
4160	branch to guests' 0x200 interrupt vector.
4161	
4162	8. Other capabilities.
4163	----------------------
4164	
4165	This section lists capabilities that give information about other
4166	features of the KVM implementation.
4167	
4168	8.1 KVM_CAP_PPC_HWRNG
4169	
4170	Architectures: ppc
4171	
4172	This capability, if KVM_CHECK_EXTENSION indicates that it is
4173	available, means that that the kernel has an implementation of the
4174	H_RANDOM hypercall backed by a hardware random-number generator.
4175	If present, the kernel H_RANDOM handler can be enabled for guest use
4176	with the KVM_CAP_PPC_ENABLE_HCALL capability.
4177	
4178	8.2 KVM_CAP_HYPERV_SYNIC
4179	
4180	Architectures: x86
4181	This capability, if KVM_CHECK_EXTENSION indicates that it is
4182	available, means that that the kernel has an implementation of the
4183	Hyper-V Synthetic interrupt controller(SynIC). Hyper-V SynIC is
4184	used to support Windows Hyper-V based guest paravirt drivers(VMBus).
4185	
4186	In order to use SynIC, it has to be activated by setting this
4187	capability via KVM_ENABLE_CAP ioctl on the vcpu fd. Note that this
4188	will disable the use of APIC hardware virtualization even if supported
4189	by the CPU, as it's incompatible with SynIC auto-EOI behavior.
4190	
4191	8.3 KVM_CAP_PPC_RADIX_MMU
4192	
4193	Architectures: ppc
4194	
4195	This capability, if KVM_CHECK_EXTENSION indicates that it is
4196	available, means that that the kernel can support guests using the
4197	radix MMU defined in Power ISA V3.00 (as implemented in the POWER9
4198	processor).
4199	
4200	8.4 KVM_CAP_PPC_HASH_MMU_V3
4201	
4202	Architectures: ppc
4203	
4204	This capability, if KVM_CHECK_EXTENSION indicates that it is
4205	available, means that that the kernel can support guests using the
4206	hashed page table MMU defined in Power ISA V3.00 (as implemented in
4207	the POWER9 processor), including in-memory segment tables.
4208	
4209	8.5 KVM_CAP_MIPS_VZ
4210	
4211	Architectures: mips
4212	
4213	This capability, if KVM_CHECK_EXTENSION on the main kvm handle indicates that
4214	it is available, means that full hardware assisted virtualization capabilities
4215	of the hardware are available for use through KVM. An appropriate
4216	KVM_VM_MIPS_* type must be passed to KVM_CREATE_VM to create a VM which
4217	utilises it.
4218	
4219	If KVM_CHECK_EXTENSION on a kvm VM handle indicates that this capability is
4220	available, it means that the VM is using full hardware assisted virtualization
4221	capabilities of the hardware. This is useful to check after creating a VM with
4222	KVM_VM_MIPS_DEFAULT.
4223	
4224	The value returned by KVM_CHECK_EXTENSION should be compared against known
4225	values (see below). All other values are reserved. This is to allow for the
4226	possibility of other hardware assisted virtualization implementations which
4227	may be incompatible with the MIPS VZ ASE.
4228	
4229	 0: The trap & emulate implementation is in use to run guest code in user
4230	    mode. Guest virtual memory segments are rearranged to fit the guest in the
4231	    user mode address space.
4232	
4233	 1: The MIPS VZ ASE is in use, providing full hardware assisted
4234	    virtualization, including standard guest virtual memory segments.
4235	
4236	8.6 KVM_CAP_MIPS_TE
4237	
4238	Architectures: mips
4239	
4240	This capability, if KVM_CHECK_EXTENSION on the main kvm handle indicates that
4241	it is available, means that the trap & emulate implementation is available to
4242	run guest code in user mode, even if KVM_CAP_MIPS_VZ indicates that hardware
4243	assisted virtualisation is also available. KVM_VM_MIPS_TE (0) must be passed
4244	to KVM_CREATE_VM to create a VM which utilises it.
4245	
4246	If KVM_CHECK_EXTENSION on a kvm VM handle indicates that this capability is
4247	available, it means that the VM is using trap & emulate.
4248	
4249	8.7 KVM_CAP_MIPS_64BIT
4250	
4251	Architectures: mips
4252	
4253	This capability indicates the supported architecture type of the guest, i.e. the
4254	supported register and address width.
4255	
4256	The values returned when this capability is checked by KVM_CHECK_EXTENSION on a
4257	kvm VM handle correspond roughly to the CP0_Config.AT register field, and should
4258	be checked specifically against known values (see below). All other values are
4259	reserved.
4260	
4261	 0: MIPS32 or microMIPS32.
4262	    Both registers and addresses are 32-bits wide.
4263	    It will only be possible to run 32-bit guest code.
4264	
4265	 1: MIPS64 or microMIPS64 with access only to 32-bit compatibility segments.
4266	    Registers are 64-bits wide, but addresses are 32-bits wide.
4267	    64-bit guest code may run but cannot access MIPS64 memory segments.
4268	    It will also be possible to run 32-bit guest code.
4269	
4270	 2: MIPS64 or microMIPS64 with access to all address segments.
4271	    Both registers and addresses are 64-bits wide.
4272	    It will be possible to run 64-bit or 32-bit guest code.
4273	
4274	8.8 KVM_CAP_X86_GUEST_MWAIT
4275	
4276	Architectures: x86
4277	
4278	This capability indicates that guest using memory monotoring instructions
4279	(MWAIT/MWAITX) to stop the virtual CPU will not cause a VM exit.  As such time
4280	spent while virtual CPU is halted in this way will then be accounted for as
4281	guest running time on the host (as opposed to e.g. HLT).
4282	
4283	8.9 KVM_CAP_ARM_USER_IRQ
4284	
4285	Architectures: arm, arm64
4286	This capability, if KVM_CHECK_EXTENSION indicates that it is available, means
4287	that if userspace creates a VM without an in-kernel interrupt controller, it
4288	will be notified of changes to the output level of in-kernel emulated devices,
4289	which can generate virtual interrupts, presented to the VM.
4290	For such VMs, on every return to userspace, the kernel
4291	updates the vcpu's run->s.regs.device_irq_level field to represent the actual
4292	output level of the device.
4293	
4294	Whenever kvm detects a change in the device output level, kvm guarantees at
4295	least one return to userspace before running the VM.  This exit could either
4296	be a KVM_EXIT_INTR or any other exit event, like KVM_EXIT_MMIO. This way,
4297	userspace can always sample the device output level and re-compute the state of
4298	the userspace interrupt controller.  Userspace should always check the state
4299	of run->s.regs.device_irq_level on every kvm exit.
4300	The value in run->s.regs.device_irq_level can represent both level and edge
4301	triggered interrupt signals, depending on the device.  Edge triggered interrupt
4302	signals will exit to userspace with the bit in run->s.regs.device_irq_level
4303	set exactly once per edge signal.
4304	
4305	The field run->s.regs.device_irq_level is available independent of
4306	run->kvm_valid_regs or run->kvm_dirty_regs bits.
4307	
4308	If KVM_CAP_ARM_USER_IRQ is supported, the KVM_CHECK_EXTENSION ioctl returns a
4309	number larger than 0 indicating the version of this capability is implemented
4310	and thereby which bits in in run->s.regs.device_irq_level can signal values.
4311	
4312	Currently the following bits are defined for the device_irq_level bitmap:
4313	
4314	  KVM_CAP_ARM_USER_IRQ >= 1:
4315	
4316	    KVM_ARM_DEV_EL1_VTIMER -  EL1 virtual timer
4317	    KVM_ARM_DEV_EL1_PTIMER -  EL1 physical timer
4318	    KVM_ARM_DEV_PMU        -  ARM PMU overflow interrupt signal
4319	
4320	Future versions of kvm may implement additional events. These will get
4321	indicated by returning a higher number from KVM_CHECK_EXTENSION and will be
4322	listed above.
4323	
4324	8.10 KVM_CAP_PPC_SMT_POSSIBLE
4325	
4326	Architectures: ppc
4327	
4328	Querying this capability returns a bitmap indicating the possible
4329	virtual SMT modes that can be set using KVM_CAP_PPC_SMT.  If bit N
4330	(counting from the right) is set, then a virtual SMT mode of 2^N is
4331	available.
4332	
4333	8.11 KVM_CAP_HYPERV_SYNIC2
4334	
4335	Architectures: x86
4336	
4337	This capability enables a newer version of Hyper-V Synthetic interrupt
4338	controller (SynIC).  The only difference with KVM_CAP_HYPERV_SYNIC is that KVM
4339	doesn't clear SynIC message and event flags pages when they are enabled by
4340	writing to the respective MSRs.
4341	
4342	8.12 KVM_CAP_HYPERV_VP_INDEX
4343	
4344	Architectures: x86
4345	
4346	This capability indicates that userspace can load HV_X64_MSR_VP_INDEX msr.  Its
4347	value is used to denote the target vcpu for a SynIC interrupt.  For
4348	compatibilty, KVM initializes this msr to KVM's internal vcpu index.  When this
4349	capability is absent, userspace can still query this msr's value.
Hide Line Numbers
About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Information is copyright its respective author. All material is available from the Linux Kernel Source distributed under a GPL License. This page is provided as a free service by mjmwired.net.