About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / virtual / kvm / api.txt




Custom Search

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