About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / virtual / kvm / api.txt




Custom Search

Based on kernel version 4.8. Page generated on 2016-10-06 23:19 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 arm arm64
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	On arm/arm64, GSI routing has the following limitation:
1444	- GSI routing does not apply to KVM_IRQ_LINE but only to KVM_IRQFD.
1445	
1446	struct kvm_irq_routing {
1447		__u32 nr;
1448		__u32 flags;
1449		struct kvm_irq_routing_entry entries[0];
1450	};
1451	
1452	No flags are specified so far, the corresponding field must be set to zero.
1453	
1454	struct kvm_irq_routing_entry {
1455		__u32 gsi;
1456		__u32 type;
1457		__u32 flags;
1458		__u32 pad;
1459		union {
1460			struct kvm_irq_routing_irqchip irqchip;
1461			struct kvm_irq_routing_msi msi;
1462			struct kvm_irq_routing_s390_adapter adapter;
1463			struct kvm_irq_routing_hv_sint hv_sint;
1464			__u32 pad[8];
1465		} u;
1466	};
1467	
1468	/* gsi routing entry types */
1469	#define KVM_IRQ_ROUTING_IRQCHIP 1
1470	#define KVM_IRQ_ROUTING_MSI 2
1471	#define KVM_IRQ_ROUTING_S390_ADAPTER 3
1472	#define KVM_IRQ_ROUTING_HV_SINT 4
1473	
1474	flags:
1475	- KVM_MSI_VALID_DEVID: used along with KVM_IRQ_ROUTING_MSI routing entry
1476	  type, specifies that the devid field contains a valid value.  The per-VM
1477	  KVM_CAP_MSI_DEVID capability advertises the requirement to provide
1478	  the device ID.  If this capability is not available, userspace should
1479	  never set the KVM_MSI_VALID_DEVID flag as the ioctl might fail.
1480	- zero otherwise
1481	
1482	struct kvm_irq_routing_irqchip {
1483		__u32 irqchip;
1484		__u32 pin;
1485	};
1486	
1487	struct kvm_irq_routing_msi {
1488		__u32 address_lo;
1489		__u32 address_hi;
1490		__u32 data;
1491		union {
1492			__u32 pad;
1493			__u32 devid;
1494		};
1495	};
1496	
1497	If KVM_MSI_VALID_DEVID is set, devid contains a unique device identifier
1498	for the device that wrote the MSI message.  For PCI, this is usually a
1499	BFD identifier in the lower 16 bits.
1500	
1501	On x86, address_hi is ignored unless the KVM_X2APIC_API_USE_32BIT_IDS
1502	feature of KVM_CAP_X2APIC_API capability is enabled.  If it is enabled,
1503	address_hi bits 31-8 provide bits 31-8 of the destination id.  Bits 7-0 of
1504	address_hi must be zero.
1505	
1506	struct kvm_irq_routing_s390_adapter {
1507		__u64 ind_addr;
1508		__u64 summary_addr;
1509		__u64 ind_offset;
1510		__u32 summary_offset;
1511		__u32 adapter_id;
1512	};
1513	
1514	struct kvm_irq_routing_hv_sint {
1515		__u32 vcpu;
1516		__u32 sint;
1517	};
1518	
1519	4.53 KVM_ASSIGN_SET_MSIX_NR (deprecated)
1520	
1521	Capability: none
1522	Architectures: x86
1523	Type: vm ioctl
1524	Parameters: struct kvm_assigned_msix_nr (in)
1525	Returns: 0 on success, -1 on error
1526	
1527	Set the number of MSI-X interrupts for an assigned device. The number is
1528	reset again by terminating the MSI-X assignment of the device via
1529	KVM_DEASSIGN_DEV_IRQ. Calling this service more than once at any earlier
1530	point will fail.
1531	
1532	struct kvm_assigned_msix_nr {
1533		__u32 assigned_dev_id;
1534		__u16 entry_nr;
1535		__u16 padding;
1536	};
1537	
1538	#define KVM_MAX_MSIX_PER_DEV		256
1539	
1540	
1541	4.54 KVM_ASSIGN_SET_MSIX_ENTRY (deprecated)
1542	
1543	Capability: none
1544	Architectures: x86
1545	Type: vm ioctl
1546	Parameters: struct kvm_assigned_msix_entry (in)
1547	Returns: 0 on success, -1 on error
1548	
1549	Specifies the routing of an MSI-X assigned device interrupt to a GSI. Setting
1550	the GSI vector to zero means disabling the interrupt.
1551	
1552	struct kvm_assigned_msix_entry {
1553		__u32 assigned_dev_id;
1554		__u32 gsi;
1555		__u16 entry; /* The index of entry in the MSI-X table */
1556		__u16 padding[3];
1557	};
1558	
1559	Errors:
1560	  ENOTTY: kernel does not support this ioctl
1561	
1562	  Other error conditions may be defined by individual device types or
1563	  have their standard meanings.
1564	
1565	
1566	4.55 KVM_SET_TSC_KHZ
1567	
1568	Capability: KVM_CAP_TSC_CONTROL
1569	Architectures: x86
1570	Type: vcpu ioctl
1571	Parameters: virtual tsc_khz
1572	Returns: 0 on success, -1 on error
1573	
1574	Specifies the tsc frequency for the virtual machine. The unit of the
1575	frequency is KHz.
1576	
1577	
1578	4.56 KVM_GET_TSC_KHZ
1579	
1580	Capability: KVM_CAP_GET_TSC_KHZ
1581	Architectures: x86
1582	Type: vcpu ioctl
1583	Parameters: none
1584	Returns: virtual tsc-khz on success, negative value on error
1585	
1586	Returns the tsc frequency of the guest. The unit of the return value is
1587	KHz. If the host has unstable tsc this ioctl returns -EIO instead as an
1588	error.
1589	
1590	
1591	4.57 KVM_GET_LAPIC
1592	
1593	Capability: KVM_CAP_IRQCHIP
1594	Architectures: x86
1595	Type: vcpu ioctl
1596	Parameters: struct kvm_lapic_state (out)
1597	Returns: 0 on success, -1 on error
1598	
1599	#define KVM_APIC_REG_SIZE 0x400
1600	struct kvm_lapic_state {
1601		char regs[KVM_APIC_REG_SIZE];
1602	};
1603	
1604	Reads the Local APIC registers and copies them into the input argument.  The
1605	data format and layout are the same as documented in the architecture manual.
1606	
1607	If KVM_X2APIC_API_USE_32BIT_IDS feature of KVM_CAP_X2APIC_API is
1608	enabled, then the format of APIC_ID register depends on the APIC mode
1609	(reported by MSR_IA32_APICBASE) of its VCPU.  x2APIC stores APIC ID in
1610	the APIC_ID register (bytes 32-35).  xAPIC only allows an 8-bit APIC ID
1611	which is stored in bits 31-24 of the APIC register, or equivalently in
1612	byte 35 of struct kvm_lapic_state's regs field.  KVM_GET_LAPIC must then
1613	be called after MSR_IA32_APICBASE has been set with KVM_SET_MSR.
1614	
1615	If KVM_X2APIC_API_USE_32BIT_IDS feature is disabled, struct kvm_lapic_state
1616	always uses xAPIC format.
1617	
1618	
1619	4.58 KVM_SET_LAPIC
1620	
1621	Capability: KVM_CAP_IRQCHIP
1622	Architectures: x86
1623	Type: vcpu ioctl
1624	Parameters: struct kvm_lapic_state (in)
1625	Returns: 0 on success, -1 on error
1626	
1627	#define KVM_APIC_REG_SIZE 0x400
1628	struct kvm_lapic_state {
1629		char regs[KVM_APIC_REG_SIZE];
1630	};
1631	
1632	Copies the input argument into the Local APIC registers.  The data format
1633	and layout are the same as documented in the architecture manual.
1634	
1635	The format of the APIC ID register (bytes 32-35 of struct kvm_lapic_state's
1636	regs field) depends on the state of the KVM_CAP_X2APIC_API capability.
1637	See the note in KVM_GET_LAPIC.
1638	
1639	
1640	4.59 KVM_IOEVENTFD
1641	
1642	Capability: KVM_CAP_IOEVENTFD
1643	Architectures: all
1644	Type: vm ioctl
1645	Parameters: struct kvm_ioeventfd (in)
1646	Returns: 0 on success, !0 on error
1647	
1648	This ioctl attaches or detaches an ioeventfd to a legal pio/mmio address
1649	within the guest.  A guest write in the registered address will signal the
1650	provided event instead of triggering an exit.
1651	
1652	struct kvm_ioeventfd {
1653		__u64 datamatch;
1654		__u64 addr;        /* legal pio/mmio address */
1655		__u32 len;         /* 0, 1, 2, 4, or 8 bytes    */
1656		__s32 fd;
1657		__u32 flags;
1658		__u8  pad[36];
1659	};
1660	
1661	For the special case of virtio-ccw devices on s390, the ioevent is matched
1662	to a subchannel/virtqueue tuple instead.
1663	
1664	The following flags are defined:
1665	
1666	#define KVM_IOEVENTFD_FLAG_DATAMATCH (1 << kvm_ioeventfd_flag_nr_datamatch)
1667	#define KVM_IOEVENTFD_FLAG_PIO       (1 << kvm_ioeventfd_flag_nr_pio)
1668	#define KVM_IOEVENTFD_FLAG_DEASSIGN  (1 << kvm_ioeventfd_flag_nr_deassign)
1669	#define KVM_IOEVENTFD_FLAG_VIRTIO_CCW_NOTIFY \
1670		(1 << kvm_ioeventfd_flag_nr_virtio_ccw_notify)
1671	
1672	If datamatch flag is set, the event will be signaled only if the written value
1673	to the registered address is equal to datamatch in struct kvm_ioeventfd.
1674	
1675	For virtio-ccw devices, addr contains the subchannel id and datamatch the
1676	virtqueue index.
1677	
1678	With KVM_CAP_IOEVENTFD_ANY_LENGTH, a zero length ioeventfd is allowed, and
1679	the kernel will ignore the length of guest write and may get a faster vmexit.
1680	The speedup may only apply to specific architectures, but the ioeventfd will
1681	work anyway.
1682	
1683	4.60 KVM_DIRTY_TLB
1684	
1685	Capability: KVM_CAP_SW_TLB
1686	Architectures: ppc
1687	Type: vcpu ioctl
1688	Parameters: struct kvm_dirty_tlb (in)
1689	Returns: 0 on success, -1 on error
1690	
1691	struct kvm_dirty_tlb {
1692		__u64 bitmap;
1693		__u32 num_dirty;
1694	};
1695	
1696	This must be called whenever userspace has changed an entry in the shared
1697	TLB, prior to calling KVM_RUN on the associated vcpu.
1698	
1699	The "bitmap" field is the userspace address of an array.  This array
1700	consists of a number of bits, equal to the total number of TLB entries as
1701	determined by the last successful call to KVM_CONFIG_TLB, rounded up to the
1702	nearest multiple of 64.
1703	
1704	Each bit corresponds to one TLB entry, ordered the same as in the shared TLB
1705	array.
1706	
1707	The array is little-endian: the bit 0 is the least significant bit of the
1708	first byte, bit 8 is the least significant bit of the second byte, etc.
1709	This avoids any complications with differing word sizes.
1710	
1711	The "num_dirty" field is a performance hint for KVM to determine whether it
1712	should skip processing the bitmap and just invalidate everything.  It must
1713	be set to the number of set bits in the bitmap.
1714	
1715	
1716	4.61 KVM_ASSIGN_SET_INTX_MASK (deprecated)
1717	
1718	Capability: KVM_CAP_PCI_2_3
1719	Architectures: x86
1720	Type: vm ioctl
1721	Parameters: struct kvm_assigned_pci_dev (in)
1722	Returns: 0 on success, -1 on error
1723	
1724	Allows userspace to mask PCI INTx interrupts from the assigned device.  The
1725	kernel will not deliver INTx interrupts to the guest between setting and
1726	clearing of KVM_ASSIGN_SET_INTX_MASK via this interface.  This enables use of
1727	and emulation of PCI 2.3 INTx disable command register behavior.
1728	
1729	This may be used for both PCI 2.3 devices supporting INTx disable natively and
1730	older devices lacking this support. Userspace is responsible for emulating the
1731	read value of the INTx disable bit in the guest visible PCI command register.
1732	When modifying the INTx disable state, userspace should precede updating the
1733	physical device command register by calling this ioctl to inform the kernel of
1734	the new intended INTx mask state.
1735	
1736	Note that the kernel uses the device INTx disable bit to internally manage the
1737	device interrupt state for PCI 2.3 devices.  Reads of this register may
1738	therefore not match the expected value.  Writes should always use the guest
1739	intended INTx disable value rather than attempting to read-copy-update the
1740	current physical device state.  Races between user and kernel updates to the
1741	INTx disable bit are handled lazily in the kernel.  It's possible the device
1742	may generate unintended interrupts, but they will not be injected into the
1743	guest.
1744	
1745	See KVM_ASSIGN_DEV_IRQ for the data structure.  The target device is specified
1746	by assigned_dev_id.  In the flags field, only KVM_DEV_ASSIGN_MASK_INTX is
1747	evaluated.
1748	
1749	
1750	4.62 KVM_CREATE_SPAPR_TCE
1751	
1752	Capability: KVM_CAP_SPAPR_TCE
1753	Architectures: powerpc
1754	Type: vm ioctl
1755	Parameters: struct kvm_create_spapr_tce (in)
1756	Returns: file descriptor for manipulating the created TCE table
1757	
1758	This creates a virtual TCE (translation control entry) table, which
1759	is an IOMMU for PAPR-style virtual I/O.  It is used to translate
1760	logical addresses used in virtual I/O into guest physical addresses,
1761	and provides a scatter/gather capability for PAPR virtual I/O.
1762	
1763	/* for KVM_CAP_SPAPR_TCE */
1764	struct kvm_create_spapr_tce {
1765		__u64 liobn;
1766		__u32 window_size;
1767	};
1768	
1769	The liobn field gives the logical IO bus number for which to create a
1770	TCE table.  The window_size field specifies the size of the DMA window
1771	which this TCE table will translate - the table will contain one 64
1772	bit TCE entry for every 4kiB of the DMA window.
1773	
1774	When the guest issues an H_PUT_TCE hcall on a liobn for which a TCE
1775	table has been created using this ioctl(), the kernel will handle it
1776	in real mode, updating the TCE table.  H_PUT_TCE calls for other
1777	liobns will cause a vm exit and must be handled by userspace.
1778	
1779	The return value is a file descriptor which can be passed to mmap(2)
1780	to map the created TCE table into userspace.  This lets userspace read
1781	the entries written by kernel-handled H_PUT_TCE calls, and also lets
1782	userspace update the TCE table directly which is useful in some
1783	circumstances.
1784	
1785	
1786	4.63 KVM_ALLOCATE_RMA
1787	
1788	Capability: KVM_CAP_PPC_RMA
1789	Architectures: powerpc
1790	Type: vm ioctl
1791	Parameters: struct kvm_allocate_rma (out)
1792	Returns: file descriptor for mapping the allocated RMA
1793	
1794	This allocates a Real Mode Area (RMA) from the pool allocated at boot
1795	time by the kernel.  An RMA is a physically-contiguous, aligned region
1796	of memory used on older POWER processors to provide the memory which
1797	will be accessed by real-mode (MMU off) accesses in a KVM guest.
1798	POWER processors support a set of sizes for the RMA that usually
1799	includes 64MB, 128MB, 256MB and some larger powers of two.
1800	
1801	/* for KVM_ALLOCATE_RMA */
1802	struct kvm_allocate_rma {
1803		__u64 rma_size;
1804	};
1805	
1806	The return value is a file descriptor which can be passed to mmap(2)
1807	to map the allocated RMA into userspace.  The mapped area can then be
1808	passed to the KVM_SET_USER_MEMORY_REGION ioctl to establish it as the
1809	RMA for a virtual machine.  The size of the RMA in bytes (which is
1810	fixed at host kernel boot time) is returned in the rma_size field of
1811	the argument structure.
1812	
1813	The KVM_CAP_PPC_RMA capability is 1 or 2 if the KVM_ALLOCATE_RMA ioctl
1814	is supported; 2 if the processor requires all virtual machines to have
1815	an RMA, or 1 if the processor can use an RMA but doesn't require it,
1816	because it supports the Virtual RMA (VRMA) facility.
1817	
1818	
1819	4.64 KVM_NMI
1820	
1821	Capability: KVM_CAP_USER_NMI
1822	Architectures: x86
1823	Type: vcpu ioctl
1824	Parameters: none
1825	Returns: 0 on success, -1 on error
1826	
1827	Queues an NMI on the thread's vcpu.  Note this is well defined only
1828	when KVM_CREATE_IRQCHIP has not been called, since this is an interface
1829	between the virtual cpu core and virtual local APIC.  After KVM_CREATE_IRQCHIP
1830	has been called, this interface is completely emulated within the kernel.
1831	
1832	To use this to emulate the LINT1 input with KVM_CREATE_IRQCHIP, use the
1833	following algorithm:
1834	
1835	  - pause the vcpu
1836	  - read the local APIC's state (KVM_GET_LAPIC)
1837	  - check whether changing LINT1 will queue an NMI (see the LVT entry for LINT1)
1838	  - if so, issue KVM_NMI
1839	  - resume the vcpu
1840	
1841	Some guests configure the LINT1 NMI input to cause a panic, aiding in
1842	debugging.
1843	
1844	
1845	4.65 KVM_S390_UCAS_MAP
1846	
1847	Capability: KVM_CAP_S390_UCONTROL
1848	Architectures: s390
1849	Type: vcpu ioctl
1850	Parameters: struct kvm_s390_ucas_mapping (in)
1851	Returns: 0 in case of success
1852	
1853	The parameter is defined like this:
1854		struct kvm_s390_ucas_mapping {
1855			__u64 user_addr;
1856			__u64 vcpu_addr;
1857			__u64 length;
1858		};
1859	
1860	This ioctl maps the memory at "user_addr" with the length "length" to
1861	the vcpu's address space starting at "vcpu_addr". All parameters need to
1862	be aligned by 1 megabyte.
1863	
1864	
1865	4.66 KVM_S390_UCAS_UNMAP
1866	
1867	Capability: KVM_CAP_S390_UCONTROL
1868	Architectures: s390
1869	Type: vcpu ioctl
1870	Parameters: struct kvm_s390_ucas_mapping (in)
1871	Returns: 0 in case of success
1872	
1873	The parameter is defined like this:
1874		struct kvm_s390_ucas_mapping {
1875			__u64 user_addr;
1876			__u64 vcpu_addr;
1877			__u64 length;
1878		};
1879	
1880	This ioctl unmaps the memory in the vcpu's address space starting at
1881	"vcpu_addr" with the length "length". The field "user_addr" is ignored.
1882	All parameters need to be aligned by 1 megabyte.
1883	
1884	
1885	4.67 KVM_S390_VCPU_FAULT
1886	
1887	Capability: KVM_CAP_S390_UCONTROL
1888	Architectures: s390
1889	Type: vcpu ioctl
1890	Parameters: vcpu absolute address (in)
1891	Returns: 0 in case of success
1892	
1893	This call creates a page table entry on the virtual cpu's address space
1894	(for user controlled virtual machines) or the virtual machine's address
1895	space (for regular virtual machines). This only works for minor faults,
1896	thus it's recommended to access subject memory page via the user page
1897	table upfront. This is useful to handle validity intercepts for user
1898	controlled virtual machines to fault in the virtual cpu's lowcore pages
1899	prior to calling the KVM_RUN ioctl.
1900	
1901	
1902	4.68 KVM_SET_ONE_REG
1903	
1904	Capability: KVM_CAP_ONE_REG
1905	Architectures: all
1906	Type: vcpu ioctl
1907	Parameters: struct kvm_one_reg (in)
1908	Returns: 0 on success, negative value on failure
1909	
1910	struct kvm_one_reg {
1911	       __u64 id;
1912	       __u64 addr;
1913	};
1914	
1915	Using this ioctl, a single vcpu register can be set to a specific value
1916	defined by user space with the passed in struct kvm_one_reg, where id
1917	refers to the register identifier as described below and addr is a pointer
1918	to a variable with the respective size. There can be architecture agnostic
1919	and architecture specific registers. Each have their own range of operation
1920	and their own constants and width. To keep track of the implemented
1921	registers, find a list below:
1922	
1923	  Arch  |           Register            | Width (bits)
1924	        |                               |
1925	  PPC   | KVM_REG_PPC_HIOR              | 64
1926	  PPC   | KVM_REG_PPC_IAC1              | 64
1927	  PPC   | KVM_REG_PPC_IAC2              | 64
1928	  PPC   | KVM_REG_PPC_IAC3              | 64
1929	  PPC   | KVM_REG_PPC_IAC4              | 64
1930	  PPC   | KVM_REG_PPC_DAC1              | 64
1931	  PPC   | KVM_REG_PPC_DAC2              | 64
1932	  PPC   | KVM_REG_PPC_DABR              | 64
1933	  PPC   | KVM_REG_PPC_DSCR              | 64
1934	  PPC   | KVM_REG_PPC_PURR              | 64
1935	  PPC   | KVM_REG_PPC_SPURR             | 64
1936	  PPC   | KVM_REG_PPC_DAR               | 64
1937	  PPC   | KVM_REG_PPC_DSISR             | 32
1938	  PPC   | KVM_REG_PPC_AMR               | 64
1939	  PPC   | KVM_REG_PPC_UAMOR             | 64
1940	  PPC   | KVM_REG_PPC_MMCR0             | 64
1941	  PPC   | KVM_REG_PPC_MMCR1             | 64
1942	  PPC   | KVM_REG_PPC_MMCRA             | 64
1943	  PPC   | KVM_REG_PPC_MMCR2             | 64
1944	  PPC   | KVM_REG_PPC_MMCRS             | 64
1945	  PPC   | KVM_REG_PPC_SIAR              | 64
1946	  PPC   | KVM_REG_PPC_SDAR              | 64
1947	  PPC   | KVM_REG_PPC_SIER              | 64
1948	  PPC   | KVM_REG_PPC_PMC1              | 32
1949	  PPC   | KVM_REG_PPC_PMC2              | 32
1950	  PPC   | KVM_REG_PPC_PMC3              | 32
1951	  PPC   | KVM_REG_PPC_PMC4              | 32
1952	  PPC   | KVM_REG_PPC_PMC5              | 32
1953	  PPC   | KVM_REG_PPC_PMC6              | 32
1954	  PPC   | KVM_REG_PPC_PMC7              | 32
1955	  PPC   | KVM_REG_PPC_PMC8              | 32
1956	  PPC   | KVM_REG_PPC_FPR0              | 64
1957	          ...
1958	  PPC   | KVM_REG_PPC_FPR31             | 64
1959	  PPC   | KVM_REG_PPC_VR0               | 128
1960	          ...
1961	  PPC   | KVM_REG_PPC_VR31              | 128
1962	  PPC   | KVM_REG_PPC_VSR0              | 128
1963	          ...
1964	  PPC   | KVM_REG_PPC_VSR31             | 128
1965	  PPC   | KVM_REG_PPC_FPSCR             | 64
1966	  PPC   | KVM_REG_PPC_VSCR              | 32
1967	  PPC   | KVM_REG_PPC_VPA_ADDR          | 64
1968	  PPC   | KVM_REG_PPC_VPA_SLB           | 128
1969	  PPC   | KVM_REG_PPC_VPA_DTL           | 128
1970	  PPC   | KVM_REG_PPC_EPCR              | 32
1971	  PPC   | KVM_REG_PPC_EPR               | 32
1972	  PPC   | KVM_REG_PPC_TCR               | 32
1973	  PPC   | KVM_REG_PPC_TSR               | 32
1974	  PPC   | KVM_REG_PPC_OR_TSR            | 32
1975	  PPC   | KVM_REG_PPC_CLEAR_TSR         | 32
1976	  PPC   | KVM_REG_PPC_MAS0              | 32
1977	  PPC   | KVM_REG_PPC_MAS1              | 32
1978	  PPC   | KVM_REG_PPC_MAS2              | 64
1979	  PPC   | KVM_REG_PPC_MAS7_3            | 64
1980	  PPC   | KVM_REG_PPC_MAS4              | 32
1981	  PPC   | KVM_REG_PPC_MAS6              | 32
1982	  PPC   | KVM_REG_PPC_MMUCFG            | 32
1983	  PPC   | KVM_REG_PPC_TLB0CFG           | 32
1984	  PPC   | KVM_REG_PPC_TLB1CFG           | 32
1985	  PPC   | KVM_REG_PPC_TLB2CFG           | 32
1986	  PPC   | KVM_REG_PPC_TLB3CFG           | 32
1987	  PPC   | KVM_REG_PPC_TLB0PS            | 32
1988	  PPC   | KVM_REG_PPC_TLB1PS            | 32
1989	  PPC   | KVM_REG_PPC_TLB2PS            | 32
1990	  PPC   | KVM_REG_PPC_TLB3PS            | 32
1991	  PPC   | KVM_REG_PPC_EPTCFG            | 32
1992	  PPC   | KVM_REG_PPC_ICP_STATE         | 64
1993	  PPC   | KVM_REG_PPC_TB_OFFSET         | 64
1994	  PPC   | KVM_REG_PPC_SPMC1             | 32
1995	  PPC   | KVM_REG_PPC_SPMC2             | 32
1996	  PPC   | KVM_REG_PPC_IAMR              | 64
1997	  PPC   | KVM_REG_PPC_TFHAR             | 64
1998	  PPC   | KVM_REG_PPC_TFIAR             | 64
1999	  PPC   | KVM_REG_PPC_TEXASR            | 64
2000	  PPC   | KVM_REG_PPC_FSCR              | 64
2001	  PPC   | KVM_REG_PPC_PSPB              | 32
2002	  PPC   | KVM_REG_PPC_EBBHR             | 64
2003	  PPC   | KVM_REG_PPC_EBBRR             | 64
2004	  PPC   | KVM_REG_PPC_BESCR             | 64
2005	  PPC   | KVM_REG_PPC_TAR               | 64
2006	  PPC   | KVM_REG_PPC_DPDES             | 64
2007	  PPC   | KVM_REG_PPC_DAWR              | 64
2008	  PPC   | KVM_REG_PPC_DAWRX             | 64
2009	  PPC   | KVM_REG_PPC_CIABR             | 64
2010	  PPC   | KVM_REG_PPC_IC                | 64
2011	  PPC   | KVM_REG_PPC_VTB               | 64
2012	  PPC   | KVM_REG_PPC_CSIGR             | 64
2013	  PPC   | KVM_REG_PPC_TACR              | 64
2014	  PPC   | KVM_REG_PPC_TCSCR             | 64
2015	  PPC   | KVM_REG_PPC_PID               | 64
2016	  PPC   | KVM_REG_PPC_ACOP              | 64
2017	  PPC   | KVM_REG_PPC_VRSAVE            | 32
2018	  PPC   | KVM_REG_PPC_LPCR              | 32
2019	  PPC   | KVM_REG_PPC_LPCR_64           | 64
2020	  PPC   | KVM_REG_PPC_PPR               | 64
2021	  PPC   | KVM_REG_PPC_ARCH_COMPAT       | 32
2022	  PPC   | KVM_REG_PPC_DABRX             | 32
2023	  PPC   | KVM_REG_PPC_WORT              | 64
2024	  PPC	| KVM_REG_PPC_SPRG9             | 64
2025	  PPC	| KVM_REG_PPC_DBSR              | 32
2026	  PPC   | KVM_REG_PPC_TM_GPR0           | 64
2027	          ...
2028	  PPC   | KVM_REG_PPC_TM_GPR31          | 64
2029	  PPC   | KVM_REG_PPC_TM_VSR0           | 128
2030	          ...
2031	  PPC   | KVM_REG_PPC_TM_VSR63          | 128
2032	  PPC   | KVM_REG_PPC_TM_CR             | 64
2033	  PPC   | KVM_REG_PPC_TM_LR             | 64
2034	  PPC   | KVM_REG_PPC_TM_CTR            | 64
2035	  PPC   | KVM_REG_PPC_TM_FPSCR          | 64
2036	  PPC   | KVM_REG_PPC_TM_AMR            | 64
2037	  PPC   | KVM_REG_PPC_TM_PPR            | 64
2038	  PPC   | KVM_REG_PPC_TM_VRSAVE         | 64
2039	  PPC   | KVM_REG_PPC_TM_VSCR           | 32
2040	  PPC   | KVM_REG_PPC_TM_DSCR           | 64
2041	  PPC   | KVM_REG_PPC_TM_TAR            | 64
2042	        |                               |
2043	  MIPS  | KVM_REG_MIPS_R0               | 64
2044	          ...
2045	  MIPS  | KVM_REG_MIPS_R31              | 64
2046	  MIPS  | KVM_REG_MIPS_HI               | 64
2047	  MIPS  | KVM_REG_MIPS_LO               | 64
2048	  MIPS  | KVM_REG_MIPS_PC               | 64
2049	  MIPS  | KVM_REG_MIPS_CP0_INDEX        | 32
2050	  MIPS  | KVM_REG_MIPS_CP0_CONTEXT      | 64
2051	  MIPS  | KVM_REG_MIPS_CP0_USERLOCAL    | 64
2052	  MIPS  | KVM_REG_MIPS_CP0_PAGEMASK     | 32
2053	  MIPS  | KVM_REG_MIPS_CP0_WIRED        | 32
2054	  MIPS  | KVM_REG_MIPS_CP0_HWRENA       | 32
2055	  MIPS  | KVM_REG_MIPS_CP0_BADVADDR     | 64
2056	  MIPS  | KVM_REG_MIPS_CP0_COUNT        | 32
2057	  MIPS  | KVM_REG_MIPS_CP0_ENTRYHI      | 64
2058	  MIPS  | KVM_REG_MIPS_CP0_COMPARE      | 32
2059	  MIPS  | KVM_REG_MIPS_CP0_STATUS       | 32
2060	  MIPS  | KVM_REG_MIPS_CP0_CAUSE        | 32
2061	  MIPS  | KVM_REG_MIPS_CP0_EPC          | 64
2062	  MIPS  | KVM_REG_MIPS_CP0_PRID         | 32
2063	  MIPS  | KVM_REG_MIPS_CP0_CONFIG       | 32
2064	  MIPS  | KVM_REG_MIPS_CP0_CONFIG1      | 32
2065	  MIPS  | KVM_REG_MIPS_CP0_CONFIG2      | 32
2066	  MIPS  | KVM_REG_MIPS_CP0_CONFIG3      | 32
2067	  MIPS  | KVM_REG_MIPS_CP0_CONFIG4      | 32
2068	  MIPS  | KVM_REG_MIPS_CP0_CONFIG5      | 32
2069	  MIPS  | KVM_REG_MIPS_CP0_CONFIG7      | 32
2070	  MIPS  | KVM_REG_MIPS_CP0_ERROREPC     | 64
2071	  MIPS  | KVM_REG_MIPS_CP0_KSCRATCH1    | 64
2072	  MIPS  | KVM_REG_MIPS_CP0_KSCRATCH2    | 64
2073	  MIPS  | KVM_REG_MIPS_CP0_KSCRATCH3    | 64
2074	  MIPS  | KVM_REG_MIPS_CP0_KSCRATCH4    | 64
2075	  MIPS  | KVM_REG_MIPS_CP0_KSCRATCH5    | 64
2076	  MIPS  | KVM_REG_MIPS_CP0_KSCRATCH6    | 64
2077	  MIPS  | KVM_REG_MIPS_COUNT_CTL        | 64
2078	  MIPS  | KVM_REG_MIPS_COUNT_RESUME     | 64
2079	  MIPS  | KVM_REG_MIPS_COUNT_HZ         | 64
2080	  MIPS  | KVM_REG_MIPS_FPR_32(0..31)    | 32
2081	  MIPS  | KVM_REG_MIPS_FPR_64(0..31)    | 64
2082	  MIPS  | KVM_REG_MIPS_VEC_128(0..31)   | 128
2083	  MIPS  | KVM_REG_MIPS_FCR_IR           | 32
2084	  MIPS  | KVM_REG_MIPS_FCR_CSR          | 32
2085	  MIPS  | KVM_REG_MIPS_MSA_IR           | 32
2086	  MIPS  | KVM_REG_MIPS_MSA_CSR          | 32
2087	
2088	ARM registers are mapped using the lower 32 bits.  The upper 16 of that
2089	is the register group type, or coprocessor number:
2090	
2091	ARM core registers have the following id bit patterns:
2092	  0x4020 0000 0010 <index into the kvm_regs struct:16>
2093	
2094	ARM 32-bit CP15 registers have the following id bit patterns:
2095	  0x4020 0000 000F <zero:1> <crn:4> <crm:4> <opc1:4> <opc2:3>
2096	
2097	ARM 64-bit CP15 registers have the following id bit patterns:
2098	  0x4030 0000 000F <zero:1> <zero:4> <crm:4> <opc1:4> <zero:3>
2099	
2100	ARM CCSIDR registers are demultiplexed by CSSELR value:
2101	  0x4020 0000 0011 00 <csselr:8>
2102	
2103	ARM 32-bit VFP control registers have the following id bit patterns:
2104	  0x4020 0000 0012 1 <regno:12>
2105	
2106	ARM 64-bit FP registers have the following id bit patterns:
2107	  0x4030 0000 0012 0 <regno:12>
2108	
2109	
2110	arm64 registers are mapped using the lower 32 bits. The upper 16 of
2111	that is the register group type, or coprocessor number:
2112	
2113	arm64 core/FP-SIMD registers have the following id bit patterns. Note
2114	that the size of the access is variable, as the kvm_regs structure
2115	contains elements ranging from 32 to 128 bits. The index is a 32bit
2116	value in the kvm_regs structure seen as a 32bit array.
2117	  0x60x0 0000 0010 <index into the kvm_regs struct:16>
2118	
2119	arm64 CCSIDR registers are demultiplexed by CSSELR value:
2120	  0x6020 0000 0011 00 <csselr:8>
2121	
2122	arm64 system registers have the following id bit patterns:
2123	  0x6030 0000 0013 <op0:2> <op1:3> <crn:4> <crm:4> <op2:3>
2124	
2125	
2126	MIPS registers are mapped using the lower 32 bits.  The upper 16 of that is
2127	the register group type:
2128	
2129	MIPS core registers (see above) have the following id bit patterns:
2130	  0x7030 0000 0000 <reg:16>
2131	
2132	MIPS CP0 registers (see KVM_REG_MIPS_CP0_* above) have the following id bit
2133	patterns depending on whether they're 32-bit or 64-bit registers:
2134	  0x7020 0000 0001 00 <reg:5> <sel:3>   (32-bit)
2135	  0x7030 0000 0001 00 <reg:5> <sel:3>   (64-bit)
2136	
2137	MIPS KVM control registers (see above) have the following id bit patterns:
2138	  0x7030 0000 0002 <reg:16>
2139	
2140	MIPS FPU registers (see KVM_REG_MIPS_FPR_{32,64}() above) have the following
2141	id bit patterns depending on the size of the register being accessed. They are
2142	always accessed according to the current guest FPU mode (Status.FR and
2143	Config5.FRE), i.e. as the guest would see them, and they become unpredictable
2144	if the guest FPU mode is changed. MIPS SIMD Architecture (MSA) vector
2145	registers (see KVM_REG_MIPS_VEC_128() above) have similar patterns as they
2146	overlap the FPU registers:
2147	  0x7020 0000 0003 00 <0:3> <reg:5> (32-bit FPU registers)
2148	  0x7030 0000 0003 00 <0:3> <reg:5> (64-bit FPU registers)
2149	  0x7040 0000 0003 00 <0:3> <reg:5> (128-bit MSA vector registers)
2150	
2151	MIPS FPU control registers (see KVM_REG_MIPS_FCR_{IR,CSR} above) have the
2152	following id bit patterns:
2153	  0x7020 0000 0003 01 <0:3> <reg:5>
2154	
2155	MIPS MSA control registers (see KVM_REG_MIPS_MSA_{IR,CSR} above) have the
2156	following id bit patterns:
2157	  0x7020 0000 0003 02 <0:3> <reg:5>
2158	
2159	
2160	4.69 KVM_GET_ONE_REG
2161	
2162	Capability: KVM_CAP_ONE_REG
2163	Architectures: all
2164	Type: vcpu ioctl
2165	Parameters: struct kvm_one_reg (in and out)
2166	Returns: 0 on success, negative value on failure
2167	
2168	This ioctl allows to receive the value of a single register implemented
2169	in a vcpu. The register to read is indicated by the "id" field of the
2170	kvm_one_reg struct passed in. On success, the register value can be found
2171	at the memory location pointed to by "addr".
2172	
2173	The list of registers accessible using this interface is identical to the
2174	list in 4.68.
2175	
2176	
2177	4.70 KVM_KVMCLOCK_CTRL
2178	
2179	Capability: KVM_CAP_KVMCLOCK_CTRL
2180	Architectures: Any that implement pvclocks (currently x86 only)
2181	Type: vcpu ioctl
2182	Parameters: None
2183	Returns: 0 on success, -1 on error
2184	
2185	This signals to the host kernel that the specified guest is being paused by
2186	userspace.  The host will set a flag in the pvclock structure that is checked
2187	from the soft lockup watchdog.  The flag is part of the pvclock structure that
2188	is shared between guest and host, specifically the second bit of the flags
2189	field of the pvclock_vcpu_time_info structure.  It will be set exclusively by
2190	the host and read/cleared exclusively by the guest.  The guest operation of
2191	checking and clearing the flag must an atomic operation so
2192	load-link/store-conditional, or equivalent must be used.  There are two cases
2193	where the guest will clear the flag: when the soft lockup watchdog timer resets
2194	itself or when a soft lockup is detected.  This ioctl can be called any time
2195	after pausing the vcpu, but before it is resumed.
2196	
2197	
2198	4.71 KVM_SIGNAL_MSI
2199	
2200	Capability: KVM_CAP_SIGNAL_MSI
2201	Architectures: x86 arm64
2202	Type: vm ioctl
2203	Parameters: struct kvm_msi (in)
2204	Returns: >0 on delivery, 0 if guest blocked the MSI, and -1 on error
2205	
2206	Directly inject a MSI message. Only valid with in-kernel irqchip that handles
2207	MSI messages.
2208	
2209	struct kvm_msi {
2210		__u32 address_lo;
2211		__u32 address_hi;
2212		__u32 data;
2213		__u32 flags;
2214		__u32 devid;
2215		__u8  pad[12];
2216	};
2217	
2218	flags: KVM_MSI_VALID_DEVID: devid contains a valid value.  The per-VM
2219	  KVM_CAP_MSI_DEVID capability advertises the requirement to provide
2220	  the device ID.  If this capability is not available, userspace
2221	  should never set the KVM_MSI_VALID_DEVID flag as the ioctl might fail.
2222	
2223	If KVM_MSI_VALID_DEVID is set, devid contains a unique device identifier
2224	for the device that wrote the MSI message.  For PCI, this is usually a
2225	BFD identifier in the lower 16 bits.
2226	
2227	On x86, address_hi is ignored unless the KVM_X2APIC_API_USE_32BIT_IDS
2228	feature of KVM_CAP_X2APIC_API capability is enabled.  If it is enabled,
2229	address_hi bits 31-8 provide bits 31-8 of the destination id.  Bits 7-0 of
2230	address_hi must be zero.
2231	
2232	
2233	4.71 KVM_CREATE_PIT2
2234	
2235	Capability: KVM_CAP_PIT2
2236	Architectures: x86
2237	Type: vm ioctl
2238	Parameters: struct kvm_pit_config (in)
2239	Returns: 0 on success, -1 on error
2240	
2241	Creates an in-kernel device model for the i8254 PIT. This call is only valid
2242	after enabling in-kernel irqchip support via KVM_CREATE_IRQCHIP. The following
2243	parameters have to be passed:
2244	
2245	struct kvm_pit_config {
2246		__u32 flags;
2247		__u32 pad[15];
2248	};
2249	
2250	Valid flags are:
2251	
2252	#define KVM_PIT_SPEAKER_DUMMY     1 /* emulate speaker port stub */
2253	
2254	PIT timer interrupts may use a per-VM kernel thread for injection. If it
2255	exists, this thread will have a name of the following pattern:
2256	
2257	kvm-pit/<owner-process-pid>
2258	
2259	When running a guest with elevated priorities, the scheduling parameters of
2260	this thread may have to be adjusted accordingly.
2261	
2262	This IOCTL replaces the obsolete KVM_CREATE_PIT.
2263	
2264	
2265	4.72 KVM_GET_PIT2
2266	
2267	Capability: KVM_CAP_PIT_STATE2
2268	Architectures: x86
2269	Type: vm ioctl
2270	Parameters: struct kvm_pit_state2 (out)
2271	Returns: 0 on success, -1 on error
2272	
2273	Retrieves the state of the in-kernel PIT model. Only valid after
2274	KVM_CREATE_PIT2. The state is returned in the following structure:
2275	
2276	struct kvm_pit_state2 {
2277		struct kvm_pit_channel_state channels[3];
2278		__u32 flags;
2279		__u32 reserved[9];
2280	};
2281	
2282	Valid flags are:
2283	
2284	/* disable PIT in HPET legacy mode */
2285	#define KVM_PIT_FLAGS_HPET_LEGACY  0x00000001
2286	
2287	This IOCTL replaces the obsolete KVM_GET_PIT.
2288	
2289	
2290	4.73 KVM_SET_PIT2
2291	
2292	Capability: KVM_CAP_PIT_STATE2
2293	Architectures: x86
2294	Type: vm ioctl
2295	Parameters: struct kvm_pit_state2 (in)
2296	Returns: 0 on success, -1 on error
2297	
2298	Sets the state of the in-kernel PIT model. Only valid after KVM_CREATE_PIT2.
2299	See KVM_GET_PIT2 for details on struct kvm_pit_state2.
2300	
2301	This IOCTL replaces the obsolete KVM_SET_PIT.
2302	
2303	
2304	4.74 KVM_PPC_GET_SMMU_INFO
2305	
2306	Capability: KVM_CAP_PPC_GET_SMMU_INFO
2307	Architectures: powerpc
2308	Type: vm ioctl
2309	Parameters: None
2310	Returns: 0 on success, -1 on error
2311	
2312	This populates and returns a structure describing the features of
2313	the "Server" class MMU emulation supported by KVM.
2314	This can in turn be used by userspace to generate the appropriate
2315	device-tree properties for the guest operating system.
2316	
2317	The structure contains some global information, followed by an
2318	array of supported segment page sizes:
2319	
2320	      struct kvm_ppc_smmu_info {
2321		     __u64 flags;
2322		     __u32 slb_size;
2323		     __u32 pad;
2324		     struct kvm_ppc_one_seg_page_size sps[KVM_PPC_PAGE_SIZES_MAX_SZ];
2325	      };
2326	
2327	The supported flags are:
2328	
2329	    - KVM_PPC_PAGE_SIZES_REAL:
2330	        When that flag is set, guest page sizes must "fit" the backing
2331	        store page sizes. When not set, any page size in the list can
2332	        be used regardless of how they are backed by userspace.
2333	
2334	    - KVM_PPC_1T_SEGMENTS
2335	        The emulated MMU supports 1T segments in addition to the
2336	        standard 256M ones.
2337	
2338	The "slb_size" field indicates how many SLB entries are supported
2339	
2340	The "sps" array contains 8 entries indicating the supported base
2341	page sizes for a segment in increasing order. Each entry is defined
2342	as follow:
2343	
2344	   struct kvm_ppc_one_seg_page_size {
2345		__u32 page_shift;	/* Base page shift of segment (or 0) */
2346		__u32 slb_enc;		/* SLB encoding for BookS */
2347		struct kvm_ppc_one_page_size enc[KVM_PPC_PAGE_SIZES_MAX_SZ];
2348	   };
2349	
2350	An entry with a "page_shift" of 0 is unused. Because the array is
2351	organized in increasing order, a lookup can stop when encoutering
2352	such an entry.
2353	
2354	The "slb_enc" field provides the encoding to use in the SLB for the
2355	page size. The bits are in positions such as the value can directly
2356	be OR'ed into the "vsid" argument of the slbmte instruction.
2357	
2358	The "enc" array is a list which for each of those segment base page
2359	size provides the list of supported actual page sizes (which can be
2360	only larger or equal to the base page size), along with the
2361	corresponding encoding in the hash PTE. Similarly, the array is
2362	8 entries sorted by increasing sizes and an entry with a "0" shift
2363	is an empty entry and a terminator:
2364	
2365	   struct kvm_ppc_one_page_size {
2366		__u32 page_shift;	/* Page shift (or 0) */
2367		__u32 pte_enc;		/* Encoding in the HPTE (>>12) */
2368	   };
2369	
2370	The "pte_enc" field provides a value that can OR'ed into the hash
2371	PTE's RPN field (ie, it needs to be shifted left by 12 to OR it
2372	into the hash PTE second double word).
2373	
2374	4.75 KVM_IRQFD
2375	
2376	Capability: KVM_CAP_IRQFD
2377	Architectures: x86 s390 arm arm64
2378	Type: vm ioctl
2379	Parameters: struct kvm_irqfd (in)
2380	Returns: 0 on success, -1 on error
2381	
2382	Allows setting an eventfd to directly trigger a guest interrupt.
2383	kvm_irqfd.fd specifies the file descriptor to use as the eventfd and
2384	kvm_irqfd.gsi specifies the irqchip pin toggled by this event.  When
2385	an event is triggered on the eventfd, an interrupt is injected into
2386	the guest using the specified gsi pin.  The irqfd is removed using
2387	the KVM_IRQFD_FLAG_DEASSIGN flag, specifying both kvm_irqfd.fd
2388	and kvm_irqfd.gsi.
2389	
2390	With KVM_CAP_IRQFD_RESAMPLE, KVM_IRQFD supports a de-assert and notify
2391	mechanism allowing emulation of level-triggered, irqfd-based
2392	interrupts.  When KVM_IRQFD_FLAG_RESAMPLE is set the user must pass an
2393	additional eventfd in the kvm_irqfd.resamplefd field.  When operating
2394	in resample mode, posting of an interrupt through kvm_irq.fd asserts
2395	the specified gsi in the irqchip.  When the irqchip is resampled, such
2396	as from an EOI, the gsi is de-asserted and the user is notified via
2397	kvm_irqfd.resamplefd.  It is the user's responsibility to re-queue
2398	the interrupt if the device making use of it still requires service.
2399	Note that closing the resamplefd is not sufficient to disable the
2400	irqfd.  The KVM_IRQFD_FLAG_RESAMPLE is only necessary on assignment
2401	and need not be specified with KVM_IRQFD_FLAG_DEASSIGN.
2402	
2403	On arm/arm64, gsi routing being supported, the following can happen:
2404	- in case no routing entry is associated to this gsi, injection fails
2405	- in case the gsi is associated to an irqchip routing entry,
2406	  irqchip.pin + 32 corresponds to the injected SPI ID.
2407	- in case the gsi is associated to an MSI routing entry, the MSI
2408	  message and device ID are translated into an LPI (support restricted
2409	  to GICv3 ITS in-kernel emulation).
2410	
2411	4.76 KVM_PPC_ALLOCATE_HTAB
2412	
2413	Capability: KVM_CAP_PPC_ALLOC_HTAB
2414	Architectures: powerpc
2415	Type: vm ioctl
2416	Parameters: Pointer to u32 containing hash table order (in/out)
2417	Returns: 0 on success, -1 on error
2418	
2419	This requests the host kernel to allocate an MMU hash table for a
2420	guest using the PAPR paravirtualization interface.  This only does
2421	anything if the kernel is configured to use the Book 3S HV style of
2422	virtualization.  Otherwise the capability doesn't exist and the ioctl
2423	returns an ENOTTY error.  The rest of this description assumes Book 3S
2424	HV.
2425	
2426	There must be no vcpus running when this ioctl is called; if there
2427	are, it will do nothing and return an EBUSY error.
2428	
2429	The parameter is a pointer to a 32-bit unsigned integer variable
2430	containing the order (log base 2) of the desired size of the hash
2431	table, which must be between 18 and 46.  On successful return from the
2432	ioctl, it will have been updated with the order of the hash table that
2433	was allocated.
2434	
2435	If no hash table has been allocated when any vcpu is asked to run
2436	(with the KVM_RUN ioctl), the host kernel will allocate a
2437	default-sized hash table (16 MB).
2438	
2439	If this ioctl is called when a hash table has already been allocated,
2440	the kernel will clear out the existing hash table (zero all HPTEs) and
2441	return the hash table order in the parameter.  (If the guest is using
2442	the virtualized real-mode area (VRMA) facility, the kernel will
2443	re-create the VMRA HPTEs on the next KVM_RUN of any vcpu.)
2444	
2445	4.77 KVM_S390_INTERRUPT
2446	
2447	Capability: basic
2448	Architectures: s390
2449	Type: vm ioctl, vcpu ioctl
2450	Parameters: struct kvm_s390_interrupt (in)
2451	Returns: 0 on success, -1 on error
2452	
2453	Allows to inject an interrupt to the guest. Interrupts can be floating
2454	(vm ioctl) or per cpu (vcpu ioctl), depending on the interrupt type.
2455	
2456	Interrupt parameters are passed via kvm_s390_interrupt:
2457	
2458	struct kvm_s390_interrupt {
2459		__u32 type;
2460		__u32 parm;
2461		__u64 parm64;
2462	};
2463	
2464	type can be one of the following:
2465	
2466	KVM_S390_SIGP_STOP (vcpu) - sigp stop; optional flags in parm
2467	KVM_S390_PROGRAM_INT (vcpu) - program check; code in parm
2468	KVM_S390_SIGP_SET_PREFIX (vcpu) - sigp set prefix; prefix address in parm
2469	KVM_S390_RESTART (vcpu) - restart
2470	KVM_S390_INT_CLOCK_COMP (vcpu) - clock comparator interrupt
2471	KVM_S390_INT_CPU_TIMER (vcpu) - CPU timer interrupt
2472	KVM_S390_INT_VIRTIO (vm) - virtio external interrupt; external interrupt
2473				   parameters in parm and parm64
2474	KVM_S390_INT_SERVICE (vm) - sclp external interrupt; sclp parameter in parm
2475	KVM_S390_INT_EMERGENCY (vcpu) - sigp emergency; source cpu in parm
2476	KVM_S390_INT_EXTERNAL_CALL (vcpu) - sigp external call; source cpu in parm
2477	KVM_S390_INT_IO(ai,cssid,ssid,schid) (vm) - compound value to indicate an
2478	    I/O interrupt (ai - adapter interrupt; cssid,ssid,schid - subchannel);
2479	    I/O interruption parameters in parm (subchannel) and parm64 (intparm,
2480	    interruption subclass)
2481	KVM_S390_MCHK (vm, vcpu) - machine check interrupt; cr 14 bits in parm,
2482	                           machine check interrupt code in parm64 (note that
2483	                           machine checks needing further payload are not
2484	                           supported by this ioctl)
2485	
2486	Note that the vcpu ioctl is asynchronous to vcpu execution.
2487	
2488	4.78 KVM_PPC_GET_HTAB_FD
2489	
2490	Capability: KVM_CAP_PPC_HTAB_FD
2491	Architectures: powerpc
2492	Type: vm ioctl
2493	Parameters: Pointer to struct kvm_get_htab_fd (in)
2494	Returns: file descriptor number (>= 0) on success, -1 on error
2495	
2496	This returns a file descriptor that can be used either to read out the
2497	entries in the guest's hashed page table (HPT), or to write entries to
2498	initialize the HPT.  The returned fd can only be written to if the
2499	KVM_GET_HTAB_WRITE bit is set in the flags field of the argument, and
2500	can only be read if that bit is clear.  The argument struct looks like
2501	this:
2502	
2503	/* For KVM_PPC_GET_HTAB_FD */
2504	struct kvm_get_htab_fd {
2505		__u64	flags;
2506		__u64	start_index;
2507		__u64	reserved[2];
2508	};
2509	
2510	/* Values for kvm_get_htab_fd.flags */
2511	#define KVM_GET_HTAB_BOLTED_ONLY	((__u64)0x1)
2512	#define KVM_GET_HTAB_WRITE		((__u64)0x2)
2513	
2514	The `start_index' field gives the index in the HPT of the entry at
2515	which to start reading.  It is ignored when writing.
2516	
2517	Reads on the fd will initially supply information about all
2518	"interesting" HPT entries.  Interesting entries are those with the
2519	bolted bit set, if the KVM_GET_HTAB_BOLTED_ONLY bit is set, otherwise
2520	all entries.  When the end of the HPT is reached, the read() will
2521	return.  If read() is called again on the fd, it will start again from
2522	the beginning of the HPT, but will only return HPT entries that have
2523	changed since they were last read.
2524	
2525	Data read or written is structured as a header (8 bytes) followed by a
2526	series of valid HPT entries (16 bytes) each.  The header indicates how
2527	many valid HPT entries there are and how many invalid entries follow
2528	the valid entries.  The invalid entries are not represented explicitly
2529	in the stream.  The header format is:
2530	
2531	struct kvm_get_htab_header {
2532		__u32	index;
2533		__u16	n_valid;
2534		__u16	n_invalid;
2535	};
2536	
2537	Writes to the fd create HPT entries starting at the index given in the
2538	header; first `n_valid' valid entries with contents from the data
2539	written, then `n_invalid' invalid entries, invalidating any previously
2540	valid entries found.
2541	
2542	4.79 KVM_CREATE_DEVICE
2543	
2544	Capability: KVM_CAP_DEVICE_CTRL
2545	Type: vm ioctl
2546	Parameters: struct kvm_create_device (in/out)
2547	Returns: 0 on success, -1 on error
2548	Errors:
2549	  ENODEV: The device type is unknown or unsupported
2550	  EEXIST: Device already created, and this type of device may not
2551	          be instantiated multiple times
2552	
2553	  Other error conditions may be defined by individual device types or
2554	  have their standard meanings.
2555	
2556	Creates an emulated device in the kernel.  The file descriptor returned
2557	in fd can be used with KVM_SET/GET/HAS_DEVICE_ATTR.
2558	
2559	If the KVM_CREATE_DEVICE_TEST flag is set, only test whether the
2560	device type is supported (not necessarily whether it can be created
2561	in the current vm).
2562	
2563	Individual devices should not define flags.  Attributes should be used
2564	for specifying any behavior that is not implied by the device type
2565	number.
2566	
2567	struct kvm_create_device {
2568		__u32	type;	/* in: KVM_DEV_TYPE_xxx */
2569		__u32	fd;	/* out: device handle */
2570		__u32	flags;	/* in: KVM_CREATE_DEVICE_xxx */
2571	};
2572	
2573	4.80 KVM_SET_DEVICE_ATTR/KVM_GET_DEVICE_ATTR
2574	
2575	Capability: KVM_CAP_DEVICE_CTRL, KVM_CAP_VM_ATTRIBUTES for vm device,
2576	  KVM_CAP_VCPU_ATTRIBUTES for vcpu device
2577	Type: device ioctl, vm ioctl, vcpu ioctl
2578	Parameters: struct kvm_device_attr
2579	Returns: 0 on success, -1 on error
2580	Errors:
2581	  ENXIO:  The group or attribute is unknown/unsupported for this device
2582	          or hardware support is missing.
2583	  EPERM:  The attribute cannot (currently) be accessed this way
2584	          (e.g. read-only attribute, or attribute that only makes
2585	          sense when the device is in a different state)
2586	
2587	  Other error conditions may be defined by individual device types.
2588	
2589	Gets/sets a specified piece of device configuration and/or state.  The
2590	semantics are device-specific.  See individual device documentation in
2591	the "devices" directory.  As with ONE_REG, the size of the data
2592	transferred is defined by the particular attribute.
2593	
2594	struct kvm_device_attr {
2595		__u32	flags;		/* no flags currently defined */
2596		__u32	group;		/* device-defined */
2597		__u64	attr;		/* group-defined */
2598		__u64	addr;		/* userspace address of attr data */
2599	};
2600	
2601	4.81 KVM_HAS_DEVICE_ATTR
2602	
2603	Capability: KVM_CAP_DEVICE_CTRL, KVM_CAP_VM_ATTRIBUTES for vm device,
2604	  KVM_CAP_VCPU_ATTRIBUTES for vcpu device
2605	Type: device ioctl, vm ioctl, vcpu ioctl
2606	Parameters: struct kvm_device_attr
2607	Returns: 0 on success, -1 on error
2608	Errors:
2609	  ENXIO:  The group or attribute is unknown/unsupported for this device
2610	          or hardware support is missing.
2611	
2612	Tests whether a device supports a particular attribute.  A successful
2613	return indicates the attribute is implemented.  It does not necessarily
2614	indicate that the attribute can be read or written in the device's
2615	current state.  "addr" is ignored.
2616	
2617	4.82 KVM_ARM_VCPU_INIT
2618	
2619	Capability: basic
2620	Architectures: arm, arm64
2621	Type: vcpu ioctl
2622	Parameters: struct kvm_vcpu_init (in)
2623	Returns: 0 on success; -1 on error
2624	Errors:
2625	  EINVAL:    the target is unknown, or the combination of features is invalid.
2626	  ENOENT:    a features bit specified is unknown.
2627	
2628	This tells KVM what type of CPU to present to the guest, and what
2629	optional features it should have.  This will cause a reset of the cpu
2630	registers to their initial values.  If this is not called, KVM_RUN will
2631	return ENOEXEC for that vcpu.
2632	
2633	Note that because some registers reflect machine topology, all vcpus
2634	should be created before this ioctl is invoked.
2635	
2636	Userspace can call this function multiple times for a given vcpu, including
2637	after the vcpu has been run. This will reset the vcpu to its initial
2638	state. All calls to this function after the initial call must use the same
2639	target and same set of feature flags, otherwise EINVAL will be returned.
2640	
2641	Possible features:
2642		- KVM_ARM_VCPU_POWER_OFF: Starts the CPU in a power-off state.
2643		  Depends on KVM_CAP_ARM_PSCI.  If not set, the CPU will be powered on
2644		  and execute guest code when KVM_RUN is called.
2645		- KVM_ARM_VCPU_EL1_32BIT: Starts the CPU in a 32bit mode.
2646		  Depends on KVM_CAP_ARM_EL1_32BIT (arm64 only).
2647		- KVM_ARM_VCPU_PSCI_0_2: Emulate PSCI v0.2 for the CPU.
2648		  Depends on KVM_CAP_ARM_PSCI_0_2.
2649		- KVM_ARM_VCPU_PMU_V3: Emulate PMUv3 for the CPU.
2650		  Depends on KVM_CAP_ARM_PMU_V3.
2651	
2652	
2653	4.83 KVM_ARM_PREFERRED_TARGET
2654	
2655	Capability: basic
2656	Architectures: arm, arm64
2657	Type: vm ioctl
2658	Parameters: struct struct kvm_vcpu_init (out)
2659	Returns: 0 on success; -1 on error
2660	Errors:
2661	  ENODEV:    no preferred target available for the host
2662	
2663	This queries KVM for preferred CPU target type which can be emulated
2664	by KVM on underlying host.
2665	
2666	The ioctl returns struct kvm_vcpu_init instance containing information
2667	about preferred CPU target type and recommended features for it.  The
2668	kvm_vcpu_init->features bitmap returned will have feature bits set if
2669	the preferred target recommends setting these features, but this is
2670	not mandatory.
2671	
2672	The information returned by this ioctl can be used to prepare an instance
2673	of struct kvm_vcpu_init for KVM_ARM_VCPU_INIT ioctl which will result in
2674	in VCPU matching underlying host.
2675	
2676	
2677	4.84 KVM_GET_REG_LIST
2678	
2679	Capability: basic
2680	Architectures: arm, arm64, mips
2681	Type: vcpu ioctl
2682	Parameters: struct kvm_reg_list (in/out)
2683	Returns: 0 on success; -1 on error
2684	Errors:
2685	  E2BIG:     the reg index list is too big to fit in the array specified by
2686	             the user (the number required will be written into n).
2687	
2688	struct kvm_reg_list {
2689		__u64 n; /* number of registers in reg[] */
2690		__u64 reg[0];
2691	};
2692	
2693	This ioctl returns the guest registers that are supported for the
2694	KVM_GET_ONE_REG/KVM_SET_ONE_REG calls.
2695	
2696	
2697	4.85 KVM_ARM_SET_DEVICE_ADDR (deprecated)
2698	
2699	Capability: KVM_CAP_ARM_SET_DEVICE_ADDR
2700	Architectures: arm, arm64
2701	Type: vm ioctl
2702	Parameters: struct kvm_arm_device_address (in)
2703	Returns: 0 on success, -1 on error
2704	Errors:
2705	  ENODEV: The device id is unknown
2706	  ENXIO:  Device not supported on current system
2707	  EEXIST: Address already set
2708	  E2BIG:  Address outside guest physical address space
2709	  EBUSY:  Address overlaps with other device range
2710	
2711	struct kvm_arm_device_addr {
2712		__u64 id;
2713		__u64 addr;
2714	};
2715	
2716	Specify a device address in the guest's physical address space where guests
2717	can access emulated or directly exposed devices, which the host kernel needs
2718	to know about. The id field is an architecture specific identifier for a
2719	specific device.
2720	
2721	ARM/arm64 divides the id field into two parts, a device id and an
2722	address type id specific to the individual device.
2723	
2724	  bits:  | 63        ...       32 | 31    ...    16 | 15    ...    0 |
2725	  field: |        0x00000000      |     device id   |  addr type id  |
2726	
2727	ARM/arm64 currently only require this when using the in-kernel GIC
2728	support for the hardware VGIC features, using KVM_ARM_DEVICE_VGIC_V2
2729	as the device id.  When setting the base address for the guest's
2730	mapping of the VGIC virtual CPU and distributor interface, the ioctl
2731	must be called after calling KVM_CREATE_IRQCHIP, but before calling
2732	KVM_RUN on any of the VCPUs.  Calling this ioctl twice for any of the
2733	base addresses will return -EEXIST.
2734	
2735	Note, this IOCTL is deprecated and the more flexible SET/GET_DEVICE_ATTR API
2736	should be used instead.
2737	
2738	
2739	4.86 KVM_PPC_RTAS_DEFINE_TOKEN
2740	
2741	Capability: KVM_CAP_PPC_RTAS
2742	Architectures: ppc
2743	Type: vm ioctl
2744	Parameters: struct kvm_rtas_token_args
2745	Returns: 0 on success, -1 on error
2746	
2747	Defines a token value for a RTAS (Run Time Abstraction Services)
2748	service in order to allow it to be handled in the kernel.  The
2749	argument struct gives the name of the service, which must be the name
2750	of a service that has a kernel-side implementation.  If the token
2751	value is non-zero, it will be associated with that service, and
2752	subsequent RTAS calls by the guest specifying that token will be
2753	handled by the kernel.  If the token value is 0, then any token
2754	associated with the service will be forgotten, and subsequent RTAS
2755	calls by the guest for that service will be passed to userspace to be
2756	handled.
2757	
2758	4.87 KVM_SET_GUEST_DEBUG
2759	
2760	Capability: KVM_CAP_SET_GUEST_DEBUG
2761	Architectures: x86, s390, ppc, arm64
2762	Type: vcpu ioctl
2763	Parameters: struct kvm_guest_debug (in)
2764	Returns: 0 on success; -1 on error
2765	
2766	struct kvm_guest_debug {
2767	       __u32 control;
2768	       __u32 pad;
2769	       struct kvm_guest_debug_arch arch;
2770	};
2771	
2772	Set up the processor specific debug registers and configure vcpu for
2773	handling guest debug events. There are two parts to the structure, the
2774	first a control bitfield indicates the type of debug events to handle
2775	when running. Common control bits are:
2776	
2777	  - KVM_GUESTDBG_ENABLE:        guest debugging is enabled
2778	  - KVM_GUESTDBG_SINGLESTEP:    the next run should single-step
2779	
2780	The top 16 bits of the control field are architecture specific control
2781	flags which can include the following:
2782	
2783	  - KVM_GUESTDBG_USE_SW_BP:     using software breakpoints [x86, arm64]
2784	  - KVM_GUESTDBG_USE_HW_BP:     using hardware breakpoints [x86, s390, arm64]
2785	  - KVM_GUESTDBG_INJECT_DB:     inject DB type exception [x86]
2786	  - KVM_GUESTDBG_INJECT_BP:     inject BP type exception [x86]
2787	  - KVM_GUESTDBG_EXIT_PENDING:  trigger an immediate guest exit [s390]
2788	
2789	For example KVM_GUESTDBG_USE_SW_BP indicates that software breakpoints
2790	are enabled in memory so we need to ensure breakpoint exceptions are
2791	correctly trapped and the KVM run loop exits at the breakpoint and not
2792	running off into the normal guest vector. For KVM_GUESTDBG_USE_HW_BP
2793	we need to ensure the guest vCPUs architecture specific registers are
2794	updated to the correct (supplied) values.
2795	
2796	The second part of the structure is architecture specific and
2797	typically contains a set of debug registers.
2798	
2799	For arm64 the number of debug registers is implementation defined and
2800	can be determined by querying the KVM_CAP_GUEST_DEBUG_HW_BPS and
2801	KVM_CAP_GUEST_DEBUG_HW_WPS capabilities which return a positive number
2802	indicating the number of supported registers.
2803	
2804	When debug events exit the main run loop with the reason
2805	KVM_EXIT_DEBUG with the kvm_debug_exit_arch part of the kvm_run
2806	structure containing architecture specific debug information.
2807	
2808	4.88 KVM_GET_EMULATED_CPUID
2809	
2810	Capability: KVM_CAP_EXT_EMUL_CPUID
2811	Architectures: x86
2812	Type: system ioctl
2813	Parameters: struct kvm_cpuid2 (in/out)
2814	Returns: 0 on success, -1 on error
2815	
2816	struct kvm_cpuid2 {
2817		__u32 nent;
2818		__u32 flags;
2819		struct kvm_cpuid_entry2 entries[0];
2820	};
2821	
2822	The member 'flags' is used for passing flags from userspace.
2823	
2824	#define KVM_CPUID_FLAG_SIGNIFCANT_INDEX		BIT(0)
2825	#define KVM_CPUID_FLAG_STATEFUL_FUNC		BIT(1)
2826	#define KVM_CPUID_FLAG_STATE_READ_NEXT		BIT(2)
2827	
2828	struct kvm_cpuid_entry2 {
2829		__u32 function;
2830		__u32 index;
2831		__u32 flags;
2832		__u32 eax;
2833		__u32 ebx;
2834		__u32 ecx;
2835		__u32 edx;
2836		__u32 padding[3];
2837	};
2838	
2839	This ioctl returns x86 cpuid features which are emulated by
2840	kvm.Userspace can use the information returned by this ioctl to query
2841	which features are emulated by kvm instead of being present natively.
2842	
2843	Userspace invokes KVM_GET_EMULATED_CPUID by passing a kvm_cpuid2
2844	structure with the 'nent' field indicating the number of entries in
2845	the variable-size array 'entries'. If the number of entries is too low
2846	to describe the cpu capabilities, an error (E2BIG) is returned. If the
2847	number is too high, the 'nent' field is adjusted and an error (ENOMEM)
2848	is returned. If the number is just right, the 'nent' field is adjusted
2849	to the number of valid entries in the 'entries' array, which is then
2850	filled.
2851	
2852	The entries returned are the set CPUID bits of the respective features
2853	which kvm emulates, as returned by the CPUID instruction, with unknown
2854	or unsupported feature bits cleared.
2855	
2856	Features like x2apic, for example, may not be present in the host cpu
2857	but are exposed by kvm in KVM_GET_SUPPORTED_CPUID because they can be
2858	emulated efficiently and thus not included here.
2859	
2860	The fields in each entry are defined as follows:
2861	
2862	  function: the eax value used to obtain the entry
2863	  index: the ecx value used to obtain the entry (for entries that are
2864	         affected by ecx)
2865	  flags: an OR of zero or more of the following:
2866	        KVM_CPUID_FLAG_SIGNIFCANT_INDEX:
2867	           if the index field is valid
2868	        KVM_CPUID_FLAG_STATEFUL_FUNC:
2869	           if cpuid for this function returns different values for successive
2870	           invocations; there will be several entries with the same function,
2871	           all with this flag set
2872	        KVM_CPUID_FLAG_STATE_READ_NEXT:
2873	           for KVM_CPUID_FLAG_STATEFUL_FUNC entries, set if this entry is
2874	           the first entry to be read by a cpu
2875	   eax, ebx, ecx, edx: the values returned by the cpuid instruction for
2876	         this function/index combination
2877	
2878	4.89 KVM_S390_MEM_OP
2879	
2880	Capability: KVM_CAP_S390_MEM_OP
2881	Architectures: s390
2882	Type: vcpu ioctl
2883	Parameters: struct kvm_s390_mem_op (in)
2884	Returns: = 0 on success,
2885	         < 0 on generic error (e.g. -EFAULT or -ENOMEM),
2886	         > 0 if an exception occurred while walking the page tables
2887	
2888	Read or write data from/to the logical (virtual) memory of a VCPU.
2889	
2890	Parameters are specified via the following structure:
2891	
2892	struct kvm_s390_mem_op {
2893		__u64 gaddr;		/* the guest address */
2894		__u64 flags;		/* flags */
2895		__u32 size;		/* amount of bytes */
2896		__u32 op;		/* type of operation */
2897		__u64 buf;		/* buffer in userspace */
2898		__u8 ar;		/* the access register number */
2899		__u8 reserved[31];	/* should be set to 0 */
2900	};
2901	
2902	The type of operation is specified in the "op" field. It is either
2903	KVM_S390_MEMOP_LOGICAL_READ for reading from logical memory space or
2904	KVM_S390_MEMOP_LOGICAL_WRITE for writing to logical memory space. The
2905	KVM_S390_MEMOP_F_CHECK_ONLY flag can be set in the "flags" field to check
2906	whether the corresponding memory access would create an access exception
2907	(without touching the data in the memory at the destination). In case an
2908	access exception occurred while walking the MMU tables of the guest, the
2909	ioctl returns a positive error number to indicate the type of exception.
2910	This exception is also raised directly at the corresponding VCPU if the
2911	flag KVM_S390_MEMOP_F_INJECT_EXCEPTION is set in the "flags" field.
2912	
2913	The start address of the memory region has to be specified in the "gaddr"
2914	field, and the length of the region in the "size" field. "buf" is the buffer
2915	supplied by the userspace application where the read data should be written
2916	to for KVM_S390_MEMOP_LOGICAL_READ, or where the data that should be written
2917	is stored for a KVM_S390_MEMOP_LOGICAL_WRITE. "buf" is unused and can be NULL
2918	when KVM_S390_MEMOP_F_CHECK_ONLY is specified. "ar" designates the access
2919	register number to be used.
2920	
2921	The "reserved" field is meant for future extensions. It is not used by
2922	KVM with the currently defined set of flags.
2923	
2924	4.90 KVM_S390_GET_SKEYS
2925	
2926	Capability: KVM_CAP_S390_SKEYS
2927	Architectures: s390
2928	Type: vm ioctl
2929	Parameters: struct kvm_s390_skeys
2930	Returns: 0 on success, KVM_S390_GET_KEYS_NONE if guest is not using storage
2931	         keys, negative value on error
2932	
2933	This ioctl is used to get guest storage key values on the s390
2934	architecture. The ioctl takes parameters via the kvm_s390_skeys struct.
2935	
2936	struct kvm_s390_skeys {
2937		__u64 start_gfn;
2938		__u64 count;
2939		__u64 skeydata_addr;
2940		__u32 flags;
2941		__u32 reserved[9];
2942	};
2943	
2944	The start_gfn field is the number of the first guest frame whose storage keys
2945	you want to get.
2946	
2947	The count field is the number of consecutive frames (starting from start_gfn)
2948	whose storage keys to get. The count field must be at least 1 and the maximum
2949	allowed value is defined as KVM_S390_SKEYS_ALLOC_MAX. Values outside this range
2950	will cause the ioctl to return -EINVAL.
2951	
2952	The skeydata_addr field is the address to a buffer large enough to hold count
2953	bytes. This buffer will be filled with storage key data by the ioctl.
2954	
2955	4.91 KVM_S390_SET_SKEYS
2956	
2957	Capability: KVM_CAP_S390_SKEYS
2958	Architectures: s390
2959	Type: vm ioctl
2960	Parameters: struct kvm_s390_skeys
2961	Returns: 0 on success, negative value on error
2962	
2963	This ioctl is used to set guest storage key values on the s390
2964	architecture. The ioctl takes parameters via the kvm_s390_skeys struct.
2965	See section on KVM_S390_GET_SKEYS for struct definition.
2966	
2967	The start_gfn field is the number of the first guest frame whose storage keys
2968	you want to set.
2969	
2970	The count field is the number of consecutive frames (starting from start_gfn)
2971	whose storage keys to get. The count field must be at least 1 and the maximum
2972	allowed value is defined as KVM_S390_SKEYS_ALLOC_MAX. Values outside this range
2973	will cause the ioctl to return -EINVAL.
2974	
2975	The skeydata_addr field is the address to a buffer containing count bytes of
2976	storage keys. Each byte in the buffer will be set as the storage key for a
2977	single frame starting at start_gfn for count frames.
2978	
2979	Note: If any architecturally invalid key value is found in the given data then
2980	the ioctl will return -EINVAL.
2981	
2982	4.92 KVM_S390_IRQ
2983	
2984	Capability: KVM_CAP_S390_INJECT_IRQ
2985	Architectures: s390
2986	Type: vcpu ioctl
2987	Parameters: struct kvm_s390_irq (in)
2988	Returns: 0 on success, -1 on error
2989	Errors:
2990	  EINVAL: interrupt type is invalid
2991	          type is KVM_S390_SIGP_STOP and flag parameter is invalid value
2992	          type is KVM_S390_INT_EXTERNAL_CALL and code is bigger
2993	            than the maximum of VCPUs
2994	  EBUSY:  type is KVM_S390_SIGP_SET_PREFIX and vcpu is not stopped
2995	          type is KVM_S390_SIGP_STOP and a stop irq is already pending
2996	          type is KVM_S390_INT_EXTERNAL_CALL and an external call interrupt
2997	            is already pending
2998	
2999	Allows to inject an interrupt to the guest.
3000	
3001	Using struct kvm_s390_irq as a parameter allows
3002	to inject additional payload which is not
3003	possible via KVM_S390_INTERRUPT.
3004	
3005	Interrupt parameters are passed via kvm_s390_irq:
3006	
3007	struct kvm_s390_irq {
3008		__u64 type;
3009		union {
3010			struct kvm_s390_io_info io;
3011			struct kvm_s390_ext_info ext;
3012			struct kvm_s390_pgm_info pgm;
3013			struct kvm_s390_emerg_info emerg;
3014			struct kvm_s390_extcall_info extcall;
3015			struct kvm_s390_prefix_info prefix;
3016			struct kvm_s390_stop_info stop;
3017			struct kvm_s390_mchk_info mchk;
3018			char reserved[64];
3019		} u;
3020	};
3021	
3022	type can be one of the following:
3023	
3024	KVM_S390_SIGP_STOP - sigp stop; parameter in .stop
3025	KVM_S390_PROGRAM_INT - program check; parameters in .pgm
3026	KVM_S390_SIGP_SET_PREFIX - sigp set prefix; parameters in .prefix
3027	KVM_S390_RESTART - restart; no parameters
3028	KVM_S390_INT_CLOCK_COMP - clock comparator interrupt; no parameters
3029	KVM_S390_INT_CPU_TIMER - CPU timer interrupt; no parameters
3030	KVM_S390_INT_EMERGENCY - sigp emergency; parameters in .emerg
3031	KVM_S390_INT_EXTERNAL_CALL - sigp external call; parameters in .extcall
3032	KVM_S390_MCHK - machine check interrupt; parameters in .mchk
3033	
3034	
3035	Note that the vcpu ioctl is asynchronous to vcpu execution.
3036	
3037	4.94 KVM_S390_GET_IRQ_STATE
3038	
3039	Capability: KVM_CAP_S390_IRQ_STATE
3040	Architectures: s390
3041	Type: vcpu ioctl
3042	Parameters: struct kvm_s390_irq_state (out)
3043	Returns: >= number of bytes copied into buffer,
3044	         -EINVAL if buffer size is 0,
3045	         -ENOBUFS if buffer size is too small to fit all pending interrupts,
3046	         -EFAULT if the buffer address was invalid
3047	
3048	This ioctl allows userspace to retrieve the complete state of all currently
3049	pending interrupts in a single buffer. Use cases include migration
3050	and introspection. The parameter structure contains the address of a
3051	userspace buffer and its length:
3052	
3053	struct kvm_s390_irq_state {
3054		__u64 buf;
3055		__u32 flags;
3056		__u32 len;
3057		__u32 reserved[4];
3058	};
3059	
3060	Userspace passes in the above struct and for each pending interrupt a
3061	struct kvm_s390_irq is copied to the provided buffer.
3062	
3063	If -ENOBUFS is returned the buffer provided was too small and userspace
3064	may retry with a bigger buffer.
3065	
3066	4.95 KVM_S390_SET_IRQ_STATE
3067	
3068	Capability: KVM_CAP_S390_IRQ_STATE
3069	Architectures: s390
3070	Type: vcpu ioctl
3071	Parameters: struct kvm_s390_irq_state (in)
3072	Returns: 0 on success,
3073	         -EFAULT if the buffer address was invalid,
3074	         -EINVAL for an invalid buffer length (see below),
3075	         -EBUSY if there were already interrupts pending,
3076	         errors occurring when actually injecting the
3077	          interrupt. See KVM_S390_IRQ.
3078	
3079	This ioctl allows userspace to set the complete state of all cpu-local
3080	interrupts currently pending for the vcpu. It is intended for restoring
3081	interrupt state after a migration. The input parameter is a userspace buffer
3082	containing a struct kvm_s390_irq_state:
3083	
3084	struct kvm_s390_irq_state {
3085		__u64 buf;
3086		__u32 len;
3087		__u32 pad;
3088	};
3089	
3090	The userspace memory referenced by buf contains a struct kvm_s390_irq
3091	for each interrupt to be injected into the guest.
3092	If one of the interrupts could not be injected for some reason the
3093	ioctl aborts.
3094	
3095	len must be a multiple of sizeof(struct kvm_s390_irq). It must be > 0
3096	and it must not exceed (max_vcpus + 32) * sizeof(struct kvm_s390_irq),
3097	which is the maximum number of possibly pending cpu-local interrupts.
3098	
3099	4.96 KVM_SMI
3100	
3101	Capability: KVM_CAP_X86_SMM
3102	Architectures: x86
3103	Type: vcpu ioctl
3104	Parameters: none
3105	Returns: 0 on success, -1 on error
3106	
3107	Queues an SMI on the thread's vcpu.
3108	
3109	4.97 KVM_CAP_PPC_MULTITCE
3110	
3111	Capability: KVM_CAP_PPC_MULTITCE
3112	Architectures: ppc
3113	Type: vm
3114	
3115	This capability means the kernel is capable of handling hypercalls
3116	H_PUT_TCE_INDIRECT and H_STUFF_TCE without passing those into the user
3117	space. This significantly accelerates DMA operations for PPC KVM guests.
3118	User space should expect that its handlers for these hypercalls
3119	are not going to be called if user space previously registered LIOBN
3120	in KVM (via KVM_CREATE_SPAPR_TCE or similar calls).
3121	
3122	In order to enable H_PUT_TCE_INDIRECT and H_STUFF_TCE use in the guest,
3123	user space might have to advertise it for the guest. For example,
3124	IBM pSeries (sPAPR) guest starts using them if "hcall-multi-tce" is
3125	present in the "ibm,hypertas-functions" device-tree property.
3126	
3127	The hypercalls mentioned above may or may not be processed successfully
3128	in the kernel based fast path. If they can not be handled by the kernel,
3129	they will get passed on to user space. So user space still has to have
3130	an implementation for these despite the in kernel acceleration.
3131	
3132	This capability is always enabled.
3133	
3134	4.98 KVM_CREATE_SPAPR_TCE_64
3135	
3136	Capability: KVM_CAP_SPAPR_TCE_64
3137	Architectures: powerpc
3138	Type: vm ioctl
3139	Parameters: struct kvm_create_spapr_tce_64 (in)
3140	Returns: file descriptor for manipulating the created TCE table
3141	
3142	This is an extension for KVM_CAP_SPAPR_TCE which only supports 32bit
3143	windows, described in 4.62 KVM_CREATE_SPAPR_TCE
3144	
3145	This capability uses extended struct in ioctl interface:
3146	
3147	/* for KVM_CAP_SPAPR_TCE_64 */
3148	struct kvm_create_spapr_tce_64 {
3149		__u64 liobn;
3150		__u32 page_shift;
3151		__u32 flags;
3152		__u64 offset;	/* in pages */
3153		__u64 size; 	/* in pages */
3154	};
3155	
3156	The aim of extension is to support an additional bigger DMA window with
3157	a variable page size.
3158	KVM_CREATE_SPAPR_TCE_64 receives a 64bit window size, an IOMMU page shift and
3159	a bus offset of the corresponding DMA window, @size and @offset are numbers
3160	of IOMMU pages.
3161	
3162	@flags are not used at the moment.
3163	
3164	The rest of functionality is identical to KVM_CREATE_SPAPR_TCE.
3165	
3166	4.98 KVM_REINJECT_CONTROL
3167	
3168	Capability: KVM_CAP_REINJECT_CONTROL
3169	Architectures: x86
3170	Type: vm ioctl
3171	Parameters: struct kvm_reinject_control (in)
3172	Returns: 0 on success,
3173	         -EFAULT if struct kvm_reinject_control cannot be read,
3174	         -ENXIO if KVM_CREATE_PIT or KVM_CREATE_PIT2 didn't succeed earlier.
3175	
3176	i8254 (PIT) has two modes, reinject and !reinject.  The default is reinject,
3177	where KVM queues elapsed i8254 ticks and monitors completion of interrupt from
3178	vector(s) that i8254 injects.  Reinject mode dequeues a tick and injects its
3179	interrupt whenever there isn't a pending interrupt from i8254.
3180	!reinject mode injects an interrupt as soon as a tick arrives.
3181	
3182	struct kvm_reinject_control {
3183		__u8 pit_reinject;
3184		__u8 reserved[31];
3185	};
3186	
3187	pit_reinject = 0 (!reinject mode) is recommended, unless running an old
3188	operating system that uses the PIT for timing (e.g. Linux 2.4.x).
3189	
3190	5. The kvm_run structure
3191	------------------------
3192	
3193	Application code obtains a pointer to the kvm_run structure by
3194	mmap()ing a vcpu fd.  From that point, application code can control
3195	execution by changing fields in kvm_run prior to calling the KVM_RUN
3196	ioctl, and obtain information about the reason KVM_RUN returned by
3197	looking up structure members.
3198	
3199	struct kvm_run {
3200		/* in */
3201		__u8 request_interrupt_window;
3202	
3203	Request that KVM_RUN return when it becomes possible to inject external
3204	interrupts into the guest.  Useful in conjunction with KVM_INTERRUPT.
3205	
3206		__u8 padding1[7];
3207	
3208		/* out */
3209		__u32 exit_reason;
3210	
3211	When KVM_RUN has returned successfully (return value 0), this informs
3212	application code why KVM_RUN has returned.  Allowable values for this
3213	field are detailed below.
3214	
3215		__u8 ready_for_interrupt_injection;
3216	
3217	If request_interrupt_window has been specified, this field indicates
3218	an interrupt can be injected now with KVM_INTERRUPT.
3219	
3220		__u8 if_flag;
3221	
3222	The value of the current interrupt flag.  Only valid if in-kernel
3223	local APIC is not used.
3224	
3225		__u16 flags;
3226	
3227	More architecture-specific flags detailing state of the VCPU that may
3228	affect the device's behavior.  The only currently defined flag is
3229	KVM_RUN_X86_SMM, which is valid on x86 machines and is set if the
3230	VCPU is in system management mode.
3231	
3232		/* in (pre_kvm_run), out (post_kvm_run) */
3233		__u64 cr8;
3234	
3235	The value of the cr8 register.  Only valid if in-kernel local APIC is
3236	not used.  Both input and output.
3237	
3238		__u64 apic_base;
3239	
3240	The value of the APIC BASE msr.  Only valid if in-kernel local
3241	APIC is not used.  Both input and output.
3242	
3243		union {
3244			/* KVM_EXIT_UNKNOWN */
3245			struct {
3246				__u64 hardware_exit_reason;
3247			} hw;
3248	
3249	If exit_reason is KVM_EXIT_UNKNOWN, the vcpu has exited due to unknown
3250	reasons.  Further architecture-specific information is available in
3251	hardware_exit_reason.
3252	
3253			/* KVM_EXIT_FAIL_ENTRY */
3254			struct {
3255				__u64 hardware_entry_failure_reason;
3256			} fail_entry;
3257	
3258	If exit_reason is KVM_EXIT_FAIL_ENTRY, the vcpu could not be run due
3259	to unknown reasons.  Further architecture-specific information is
3260	available in hardware_entry_failure_reason.
3261	
3262			/* KVM_EXIT_EXCEPTION */
3263			struct {
3264				__u32 exception;
3265				__u32 error_code;
3266			} ex;
3267	
3268	Unused.
3269	
3270			/* KVM_EXIT_IO */
3271			struct {
3272	#define KVM_EXIT_IO_IN  0
3273	#define KVM_EXIT_IO_OUT 1
3274				__u8 direction;
3275				__u8 size; /* bytes */
3276				__u16 port;
3277				__u32 count;
3278				__u64 data_offset; /* relative to kvm_run start */
3279			} io;
3280	
3281	If exit_reason is KVM_EXIT_IO, then the vcpu has
3282	executed a port I/O instruction which could not be satisfied by kvm.
3283	data_offset describes where the data is located (KVM_EXIT_IO_OUT) or
3284	where kvm expects application code to place the data for the next
3285	KVM_RUN invocation (KVM_EXIT_IO_IN).  Data format is a packed array.
3286	
3287			/* KVM_EXIT_DEBUG */
3288			struct {
3289				struct kvm_debug_exit_arch arch;
3290			} debug;
3291	
3292	If the exit_reason is KVM_EXIT_DEBUG, then a vcpu is processing a debug event
3293	for which architecture specific information is returned.
3294	
3295			/* KVM_EXIT_MMIO */
3296			struct {
3297				__u64 phys_addr;
3298				__u8  data[8];
3299				__u32 len;
3300				__u8  is_write;
3301			} mmio;
3302	
3303	If exit_reason is KVM_EXIT_MMIO, then the vcpu has
3304	executed a memory-mapped I/O instruction which could not be satisfied
3305	by kvm.  The 'data' member contains the written data if 'is_write' is
3306	true, and should be filled by application code otherwise.
3307	
3308	The 'data' member contains, in its first 'len' bytes, the value as it would
3309	appear if the VCPU performed a load or store of the appropriate width directly
3310	to the byte array.
3311	
3312	NOTE: For KVM_EXIT_IO, KVM_EXIT_MMIO, KVM_EXIT_OSI, KVM_EXIT_PAPR and
3313	      KVM_EXIT_EPR the corresponding
3314	operations are complete (and guest state is consistent) only after userspace
3315	has re-entered the kernel with KVM_RUN.  The kernel side will first finish
3316	incomplete operations and then check for pending signals.  Userspace
3317	can re-enter the guest with an unmasked signal pending to complete
3318	pending operations.
3319	
3320			/* KVM_EXIT_HYPERCALL */
3321			struct {
3322				__u64 nr;
3323				__u64 args[6];
3324				__u64 ret;
3325				__u32 longmode;
3326				__u32 pad;
3327			} hypercall;
3328	
3329	Unused.  This was once used for 'hypercall to userspace'.  To implement
3330	such functionality, use KVM_EXIT_IO (x86) or KVM_EXIT_MMIO (all except s390).
3331	Note KVM_EXIT_IO is significantly faster than KVM_EXIT_MMIO.
3332	
3333			/* KVM_EXIT_TPR_ACCESS */
3334			struct {
3335				__u64 rip;
3336				__u32 is_write;
3337				__u32 pad;
3338			} tpr_access;
3339	
3340	To be documented (KVM_TPR_ACCESS_REPORTING).
3341	
3342			/* KVM_EXIT_S390_SIEIC */
3343			struct {
3344				__u8 icptcode;
3345				__u64 mask; /* psw upper half */
3346				__u64 addr; /* psw lower half */
3347				__u16 ipa;
3348				__u32 ipb;
3349			} s390_sieic;
3350	
3351	s390 specific.
3352	
3353			/* KVM_EXIT_S390_RESET */
3354	#define KVM_S390_RESET_POR       1
3355	#define KVM_S390_RESET_CLEAR     2
3356	#define KVM_S390_RESET_SUBSYSTEM 4
3357	#define KVM_S390_RESET_CPU_INIT  8
3358	#define KVM_S390_RESET_IPL       16
3359			__u64 s390_reset_flags;
3360	
3361	s390 specific.
3362	
3363			/* KVM_EXIT_S390_UCONTROL */
3364			struct {
3365				__u64 trans_exc_code;
3366				__u32 pgm_code;
3367			} s390_ucontrol;
3368	
3369	s390 specific. A page fault has occurred for a user controlled virtual
3370	machine (KVM_VM_S390_UNCONTROL) on it's host page table that cannot be
3371	resolved by the kernel.
3372	The program code and the translation exception code that were placed
3373	in the cpu's lowcore are presented here as defined by the z Architecture
3374	Principles of Operation Book in the Chapter for Dynamic Address Translation
3375	(DAT)
3376	
3377			/* KVM_EXIT_DCR */
3378			struct {
3379				__u32 dcrn;
3380				__u32 data;
3381				__u8  is_write;
3382			} dcr;
3383	
3384	Deprecated - was used for 440 KVM.
3385	
3386			/* KVM_EXIT_OSI */
3387			struct {
3388				__u64 gprs[32];
3389			} osi;
3390	
3391	MOL uses a special hypercall interface it calls 'OSI'. To enable it, we catch
3392	hypercalls and exit with this exit struct that contains all the guest gprs.
3393	
3394	If exit_reason is KVM_EXIT_OSI, then the vcpu has triggered such a hypercall.
3395	Userspace can now handle the hypercall and when it's done modify the gprs as
3396	necessary. Upon guest entry all guest GPRs will then be replaced by the values
3397	in this struct.
3398	
3399			/* KVM_EXIT_PAPR_HCALL */
3400			struct {
3401				__u64 nr;
3402				__u64 ret;
3403				__u64 args[9];
3404			} papr_hcall;
3405	
3406	This is used on 64-bit PowerPC when emulating a pSeries partition,
3407	e.g. with the 'pseries' machine type in qemu.  It occurs when the
3408	guest does a hypercall using the 'sc 1' instruction.  The 'nr' field
3409	contains the hypercall number (from the guest R3), and 'args' contains
3410	the arguments (from the guest R4 - R12).  Userspace should put the
3411	return code in 'ret' and any extra returned values in args[].
3412	The possible hypercalls are defined in the Power Architecture Platform
3413	Requirements (PAPR) document available from www.power.org (free
3414	developer registration required to access it).
3415	
3416			/* KVM_EXIT_S390_TSCH */
3417			struct {
3418				__u16 subchannel_id;
3419				__u16 subchannel_nr;
3420				__u32 io_int_parm;
3421				__u32 io_int_word;
3422				__u32 ipb;
3423				__u8 dequeued;
3424			} s390_tsch;
3425	
3426	s390 specific. This exit occurs when KVM_CAP_S390_CSS_SUPPORT has been enabled
3427	and TEST SUBCHANNEL was intercepted. If dequeued is set, a pending I/O
3428	interrupt for the target subchannel has been dequeued and subchannel_id,
3429	subchannel_nr, io_int_parm and io_int_word contain the parameters for that
3430	interrupt. ipb is needed for instruction parameter decoding.
3431	
3432			/* KVM_EXIT_EPR */
3433			struct {
3434				__u32 epr;
3435			} epr;
3436	
3437	On FSL BookE PowerPC chips, the interrupt controller has a fast patch
3438	interrupt acknowledge path to the core. When the core successfully
3439	delivers an interrupt, it automatically populates the EPR register with
3440	the interrupt vector number and acknowledges the interrupt inside
3441	the interrupt controller.
3442	
3443	In case the interrupt controller lives in user space, we need to do
3444	the interrupt acknowledge cycle through it to fetch the next to be
3445	delivered interrupt vector using this exit.
3446	
3447	It gets triggered whenever both KVM_CAP_PPC_EPR are enabled and an
3448	external interrupt has just been delivered into the guest. User space
3449	should put the acknowledged interrupt vector into the 'epr' field.
3450	
3451			/* KVM_EXIT_SYSTEM_EVENT */
3452			struct {
3453	#define KVM_SYSTEM_EVENT_SHUTDOWN       1
3454	#define KVM_SYSTEM_EVENT_RESET          2
3455	#define KVM_SYSTEM_EVENT_CRASH          3
3456				__u32 type;
3457				__u64 flags;
3458			} system_event;
3459	
3460	If exit_reason is KVM_EXIT_SYSTEM_EVENT then the vcpu has triggered
3461	a system-level event using some architecture specific mechanism (hypercall
3462	or some special instruction). In case of ARM/ARM64, this is triggered using
3463	HVC instruction based PSCI call from the vcpu. The 'type' field describes
3464	the system-level event type. The 'flags' field describes architecture
3465	specific flags for the system-level event.
3466	
3467	Valid values for 'type' are:
3468	  KVM_SYSTEM_EVENT_SHUTDOWN -- the guest has requested a shutdown of the
3469	   VM. Userspace is not obliged to honour this, and if it does honour
3470	   this does not need to destroy the VM synchronously (ie it may call
3471	   KVM_RUN again before shutdown finally occurs).
3472	  KVM_SYSTEM_EVENT_RESET -- the guest has requested a reset of the VM.
3473	   As with SHUTDOWN, userspace can choose to ignore the request, or
3474	   to schedule the reset to occur in the future and may call KVM_RUN again.
3475	  KVM_SYSTEM_EVENT_CRASH -- the guest crash occurred and the guest
3476	   has requested a crash condition maintenance. Userspace can choose
3477	   to ignore the request, or to gather VM memory core dump and/or
3478	   reset/shutdown of the VM.
3479	
3480			/* KVM_EXIT_IOAPIC_EOI */
3481			struct {
3482				__u8 vector;
3483			} eoi;
3484	
3485	Indicates that the VCPU's in-kernel local APIC received an EOI for a
3486	level-triggered IOAPIC interrupt.  This exit only triggers when the
3487	IOAPIC is implemented in userspace (i.e. KVM_CAP_SPLIT_IRQCHIP is enabled);
3488	the userspace IOAPIC should process the EOI and retrigger the interrupt if
3489	it is still asserted.  Vector is the LAPIC interrupt vector for which the
3490	EOI was received.
3491	
3492			struct kvm_hyperv_exit {
3493	#define KVM_EXIT_HYPERV_SYNIC          1
3494	#define KVM_EXIT_HYPERV_HCALL          2
3495				__u32 type;
3496				union {
3497					struct {
3498						__u32 msr;
3499						__u64 control;
3500						__u64 evt_page;
3501						__u64 msg_page;
3502					} synic;
3503					struct {
3504						__u64 input;
3505						__u64 result;
3506						__u64 params[2];
3507					} hcall;
3508				} u;
3509			};
3510			/* KVM_EXIT_HYPERV */
3511	                struct kvm_hyperv_exit hyperv;
3512	Indicates that the VCPU exits into userspace to process some tasks
3513	related to Hyper-V emulation.
3514	Valid values for 'type' are:
3515		KVM_EXIT_HYPERV_SYNIC -- synchronously notify user-space about
3516	Hyper-V SynIC state change. Notification is used to remap SynIC
3517	event/message pages and to enable/disable SynIC messages/events processing
3518	in userspace.
3519	
3520			/* Fix the size of the union. */
3521			char padding[256];
3522		};
3523	
3524		/*
3525		 * shared registers between kvm and userspace.
3526		 * kvm_valid_regs specifies the register classes set by the host
3527		 * kvm_dirty_regs specified the register classes dirtied by userspace
3528		 * struct kvm_sync_regs is architecture specific, as well as the
3529		 * bits for kvm_valid_regs and kvm_dirty_regs
3530		 */
3531		__u64 kvm_valid_regs;
3532		__u64 kvm_dirty_regs;
3533		union {
3534			struct kvm_sync_regs regs;
3535			char padding[1024];
3536		} s;
3537	
3538	If KVM_CAP_SYNC_REGS is defined, these fields allow userspace to access
3539	certain guest registers without having to call SET/GET_*REGS. Thus we can
3540	avoid some system call overhead if userspace has to handle the exit.
3541	Userspace can query the validity of the structure by checking
3542	kvm_valid_regs for specific bits. These bits are architecture specific
3543	and usually define the validity of a groups of registers. (e.g. one bit
3544	 for general purpose registers)
3545	
3546	Please note that the kernel is allowed to use the kvm_run structure as the
3547	primary storage for certain register types. Therefore, the kernel may use the
3548	values in kvm_run even if the corresponding bit in kvm_dirty_regs is not set.
3549	
3550	};
3551	
3552	
3553	
3554	6. Capabilities that can be enabled on vCPUs
3555	--------------------------------------------
3556	
3557	There are certain capabilities that change the behavior of the virtual CPU or
3558	the virtual machine when enabled. To enable them, please see section 4.37.
3559	Below you can find a list of capabilities and what their effect on the vCPU or
3560	the virtual machine is when enabling them.
3561	
3562	The following information is provided along with the description:
3563	
3564	  Architectures: which instruction set architectures provide this ioctl.
3565	      x86 includes both i386 and x86_64.
3566	
3567	  Target: whether this is a per-vcpu or per-vm capability.
3568	
3569	  Parameters: what parameters are accepted by the capability.
3570	
3571	  Returns: the return value.  General error numbers (EBADF, ENOMEM, EINVAL)
3572	      are not detailed, but errors with specific meanings are.
3573	
3574	
3575	6.1 KVM_CAP_PPC_OSI
3576	
3577	Architectures: ppc
3578	Target: vcpu
3579	Parameters: none
3580	Returns: 0 on success; -1 on error
3581	
3582	This capability enables interception of OSI hypercalls that otherwise would
3583	be treated as normal system calls to be injected into the guest. OSI hypercalls
3584	were invented by Mac-on-Linux to have a standardized communication mechanism
3585	between the guest and the host.
3586	
3587	When this capability is enabled, KVM_EXIT_OSI can occur.
3588	
3589	
3590	6.2 KVM_CAP_PPC_PAPR
3591	
3592	Architectures: ppc
3593	Target: vcpu
3594	Parameters: none
3595	Returns: 0 on success; -1 on error
3596	
3597	This capability enables interception of PAPR hypercalls. PAPR hypercalls are
3598	done using the hypercall instruction "sc 1".
3599	
3600	It also sets the guest privilege level to "supervisor" mode. Usually the guest
3601	runs in "hypervisor" privilege mode with a few missing features.
3602	
3603	In addition to the above, it changes the semantics of SDR1. In this mode, the
3604	HTAB address part of SDR1 contains an HVA instead of a GPA, as PAPR keeps the
3605	HTAB invisible to the guest.
3606	
3607	When this capability is enabled, KVM_EXIT_PAPR_HCALL can occur.
3608	
3609	
3610	6.3 KVM_CAP_SW_TLB
3611	
3612	Architectures: ppc
3613	Target: vcpu
3614	Parameters: args[0] is the address of a struct kvm_config_tlb
3615	Returns: 0 on success; -1 on error
3616	
3617	struct kvm_config_tlb {
3618		__u64 params;
3619		__u64 array;
3620		__u32 mmu_type;
3621		__u32 array_len;
3622	};
3623	
3624	Configures the virtual CPU's TLB array, establishing a shared memory area
3625	between userspace and KVM.  The "params" and "array" fields are userspace
3626	addresses of mmu-type-specific data structures.  The "array_len" field is an
3627	safety mechanism, and should be set to the size in bytes of the memory that
3628	userspace has reserved for the array.  It must be at least the size dictated
3629	by "mmu_type" and "params".
3630	
3631	While KVM_RUN is active, the shared region is under control of KVM.  Its
3632	contents are undefined, and any modification by userspace results in
3633	boundedly undefined behavior.
3634	
3635	On return from KVM_RUN, the shared region will reflect the current state of
3636	the guest's TLB.  If userspace makes any changes, it must call KVM_DIRTY_TLB
3637	to tell KVM which entries have been changed, prior to calling KVM_RUN again
3638	on this vcpu.
3639	
3640	For mmu types KVM_MMU_FSL_BOOKE_NOHV and KVM_MMU_FSL_BOOKE_HV:
3641	 - The "params" field is of type "struct kvm_book3e_206_tlb_params".
3642	 - The "array" field points to an array of type "struct
3643	   kvm_book3e_206_tlb_entry".
3644	 - The array consists of all entries in the first TLB, followed by all
3645	   entries in the second TLB.
3646	 - Within a TLB, entries are ordered first by increasing set number.  Within a
3647	   set, entries are ordered by way (increasing ESEL).
3648	 - The hash for determining set number in TLB0 is: (MAS2 >> 12) & (num_sets - 1)
3649	   where "num_sets" is the tlb_sizes[] value divided by the tlb_ways[] value.
3650	 - The tsize field of mas1 shall be set to 4K on TLB0, even though the
3651	   hardware ignores this value for TLB0.
3652	
3653	6.4 KVM_CAP_S390_CSS_SUPPORT
3654	
3655	Architectures: s390
3656	Target: vcpu
3657	Parameters: none
3658	Returns: 0 on success; -1 on error
3659	
3660	This capability enables support for handling of channel I/O instructions.
3661	
3662	TEST PENDING INTERRUPTION and the interrupt portion of TEST SUBCHANNEL are
3663	handled in-kernel, while the other I/O instructions are passed to userspace.
3664	
3665	When this capability is enabled, KVM_EXIT_S390_TSCH will occur on TEST
3666	SUBCHANNEL intercepts.
3667	
3668	Note that even though this capability is enabled per-vcpu, the complete
3669	virtual machine is affected.
3670	
3671	6.5 KVM_CAP_PPC_EPR
3672	
3673	Architectures: ppc
3674	Target: vcpu
3675	Parameters: args[0] defines whether the proxy facility is active
3676	Returns: 0 on success; -1 on error
3677	
3678	This capability enables or disables the delivery of interrupts through the
3679	external proxy facility.
3680	
3681	When enabled (args[0] != 0), every time the guest gets an external interrupt
3682	delivered, it automatically exits into user space with a KVM_EXIT_EPR exit
3683	to receive the topmost interrupt vector.
3684	
3685	When disabled (args[0] == 0), behavior is as if this facility is unsupported.
3686	
3687	When this capability is enabled, KVM_EXIT_EPR can occur.
3688	
3689	6.6 KVM_CAP_IRQ_MPIC
3690	
3691	Architectures: ppc
3692	Parameters: args[0] is the MPIC device fd
3693	            args[1] is the MPIC CPU number for this vcpu
3694	
3695	This capability connects the vcpu to an in-kernel MPIC device.
3696	
3697	6.7 KVM_CAP_IRQ_XICS
3698	
3699	Architectures: ppc
3700	Target: vcpu
3701	Parameters: args[0] is the XICS device fd
3702	            args[1] is the XICS CPU number (server ID) for this vcpu
3703	
3704	This capability connects the vcpu to an in-kernel XICS device.
3705	
3706	6.8 KVM_CAP_S390_IRQCHIP
3707	
3708	Architectures: s390
3709	Target: vm
3710	Parameters: none
3711	
3712	This capability enables the in-kernel irqchip for s390. Please refer to
3713	"4.24 KVM_CREATE_IRQCHIP" for details.
3714	
3715	6.9 KVM_CAP_MIPS_FPU
3716	
3717	Architectures: mips
3718	Target: vcpu
3719	Parameters: args[0] is reserved for future use (should be 0).
3720	
3721	This capability allows the use of the host Floating Point Unit by the guest. It
3722	allows the Config1.FP bit to be set to enable the FPU in the guest. Once this is
3723	done the KVM_REG_MIPS_FPR_* and KVM_REG_MIPS_FCR_* registers can be accessed
3724	(depending on the current guest FPU register mode), and the Status.FR,
3725	Config5.FRE bits are accessible via the KVM API and also from the guest,
3726	depending on them being supported by the FPU.
3727	
3728	6.10 KVM_CAP_MIPS_MSA
3729	
3730	Architectures: mips
3731	Target: vcpu
3732	Parameters: args[0] is reserved for future use (should be 0).
3733	
3734	This capability allows the use of the MIPS SIMD Architecture (MSA) by the guest.
3735	It allows the Config3.MSAP bit to be set to enable the use of MSA by the guest.
3736	Once this is done the KVM_REG_MIPS_VEC_* and KVM_REG_MIPS_MSA_* registers can be
3737	accessed, and the Config5.MSAEn bit is accessible via the KVM API and also from
3738	the guest.
3739	
3740	7. Capabilities that can be enabled on VMs
3741	------------------------------------------
3742	
3743	There are certain capabilities that change the behavior of the virtual
3744	machine when enabled. To enable them, please see section 4.37. Below
3745	you can find a list of capabilities and what their effect on the VM
3746	is when enabling them.
3747	
3748	The following information is provided along with the description:
3749	
3750	  Architectures: which instruction set architectures provide this ioctl.
3751	      x86 includes both i386 and x86_64.
3752	
3753	  Parameters: what parameters are accepted by the capability.
3754	
3755	  Returns: the return value.  General error numbers (EBADF, ENOMEM, EINVAL)
3756	      are not detailed, but errors with specific meanings are.
3757	
3758	
3759	7.1 KVM_CAP_PPC_ENABLE_HCALL
3760	
3761	Architectures: ppc
3762	Parameters: args[0] is the sPAPR hcall number
3763		    args[1] is 0 to disable, 1 to enable in-kernel handling
3764	
3765	This capability controls whether individual sPAPR hypercalls (hcalls)
3766	get handled by the kernel or not.  Enabling or disabling in-kernel
3767	handling of an hcall is effective across the VM.  On creation, an
3768	initial set of hcalls are enabled for in-kernel handling, which
3769	consists of those hcalls for which in-kernel handlers were implemented
3770	before this capability was implemented.  If disabled, the kernel will
3771	not to attempt to handle the hcall, but will always exit to userspace
3772	to handle it.  Note that it may not make sense to enable some and
3773	disable others of a group of related hcalls, but KVM does not prevent
3774	userspace from doing that.
3775	
3776	If the hcall number specified is not one that has an in-kernel
3777	implementation, the KVM_ENABLE_CAP ioctl will fail with an EINVAL
3778	error.
3779	
3780	7.2 KVM_CAP_S390_USER_SIGP
3781	
3782	Architectures: s390
3783	Parameters: none
3784	
3785	This capability controls which SIGP orders will be handled completely in user
3786	space. With this capability enabled, all fast orders will be handled completely
3787	in the kernel:
3788	- SENSE
3789	- SENSE RUNNING
3790	- EXTERNAL CALL
3791	- EMERGENCY SIGNAL
3792	- CONDITIONAL EMERGENCY SIGNAL
3793	
3794	All other orders will be handled completely in user space.
3795	
3796	Only privileged operation exceptions will be checked for in the kernel (or even
3797	in the hardware prior to interception). If this capability is not enabled, the
3798	old way of handling SIGP orders is used (partially in kernel and user space).
3799	
3800	7.3 KVM_CAP_S390_VECTOR_REGISTERS
3801	
3802	Architectures: s390
3803	Parameters: none
3804	Returns: 0 on success, negative value on error
3805	
3806	Allows use of the vector registers introduced with z13 processor, and
3807	provides for the synchronization between host and user space.  Will
3808	return -EINVAL if the machine does not support vectors.
3809	
3810	7.4 KVM_CAP_S390_USER_STSI
3811	
3812	Architectures: s390
3813	Parameters: none
3814	
3815	This capability allows post-handlers for the STSI instruction. After
3816	initial handling in the kernel, KVM exits to user space with
3817	KVM_EXIT_S390_STSI to allow user space to insert further data.
3818	
3819	Before exiting to userspace, kvm handlers should fill in s390_stsi field of
3820	vcpu->run:
3821	struct {
3822		__u64 addr;
3823		__u8 ar;
3824		__u8 reserved;
3825		__u8 fc;
3826		__u8 sel1;
3827		__u16 sel2;
3828	} s390_stsi;
3829	
3830	@addr - guest address of STSI SYSIB
3831	@fc   - function code
3832	@sel1 - selector 1
3833	@sel2 - selector 2
3834	@ar   - access register number
3835	
3836	KVM handlers should exit to userspace with rc = -EREMOTE.
3837	
3838	7.5 KVM_CAP_SPLIT_IRQCHIP
3839	
3840	Architectures: x86
3841	Parameters: args[0] - number of routes reserved for userspace IOAPICs
3842	Returns: 0 on success, -1 on error
3843	
3844	Create a local apic for each processor in the kernel. This can be used
3845	instead of KVM_CREATE_IRQCHIP if the userspace VMM wishes to emulate the
3846	IOAPIC and PIC (and also the PIT, even though this has to be enabled
3847	separately).
3848	
3849	This capability also enables in kernel routing of interrupt requests;
3850	when KVM_CAP_SPLIT_IRQCHIP only routes of KVM_IRQ_ROUTING_MSI type are
3851	used in the IRQ routing table.  The first args[0] MSI routes are reserved
3852	for the IOAPIC pins.  Whenever the LAPIC receives an EOI for these routes,
3853	a KVM_EXIT_IOAPIC_EOI vmexit will be reported to userspace.
3854	
3855	Fails if VCPU has already been created, or if the irqchip is already in the
3856	kernel (i.e. KVM_CREATE_IRQCHIP has already been called).
3857	
3858	7.6 KVM_CAP_S390_RI
3859	
3860	Architectures: s390
3861	Parameters: none
3862	
3863	Allows use of runtime-instrumentation introduced with zEC12 processor.
3864	Will return -EINVAL if the machine does not support runtime-instrumentation.
3865	Will return -EBUSY if a VCPU has already been created.
3866	
3867	7.7 KVM_CAP_X2APIC_API
3868	
3869	Architectures: x86
3870	Parameters: args[0] - features that should be enabled
3871	Returns: 0 on success, -EINVAL when args[0] contains invalid features
3872	
3873	Valid feature flags in args[0] are
3874	
3875	#define KVM_X2APIC_API_USE_32BIT_IDS            (1ULL << 0)
3876	#define KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK  (1ULL << 1)
3877	
3878	Enabling KVM_X2APIC_API_USE_32BIT_IDS changes the behavior of
3879	KVM_SET_GSI_ROUTING, KVM_SIGNAL_MSI, KVM_SET_LAPIC, and KVM_GET_LAPIC,
3880	allowing the use of 32-bit APIC IDs.  See KVM_CAP_X2APIC_API in their
3881	respective sections.
3882	
3883	KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK must be enabled for x2APIC to work
3884	in logical mode or with more than 255 VCPUs.  Otherwise, KVM treats 0xff
3885	as a broadcast even in x2APIC mode in order to support physical x2APIC
3886	without interrupt remapping.  This is undesirable in logical mode,
3887	where 0xff represents CPUs 0-7 in cluster 0.
3888	
3889	7.8 KVM_CAP_S390_USER_INSTR0
3890	
3891	Architectures: s390
3892	Parameters: none
3893	
3894	With this capability enabled, all illegal instructions 0x0000 (2 bytes) will
3895	be intercepted and forwarded to user space. User space can use this
3896	mechanism e.g. to realize 2-byte software breakpoints. The kernel will
3897	not inject an operating exception for these instructions, user space has
3898	to take care of that.
3899	
3900	This capability can be enabled dynamically even if VCPUs were already
3901	created and are running.
3902	
3903	8. Other capabilities.
3904	----------------------
3905	
3906	This section lists capabilities that give information about other
3907	features of the KVM implementation.
3908	
3909	8.1 KVM_CAP_PPC_HWRNG
3910	
3911	Architectures: ppc
3912	
3913	This capability, if KVM_CHECK_EXTENSION indicates that it is
3914	available, means that that the kernel has an implementation of the
3915	H_RANDOM hypercall backed by a hardware random-number generator.
3916	If present, the kernel H_RANDOM handler can be enabled for guest use
3917	with the KVM_CAP_PPC_ENABLE_HCALL capability.
3918	
3919	8.2 KVM_CAP_HYPERV_SYNIC
3920	
3921	Architectures: x86
3922	This capability, if KVM_CHECK_EXTENSION indicates that it is
3923	available, means that that the kernel has an implementation of the
3924	Hyper-V Synthetic interrupt controller(SynIC). Hyper-V SynIC is
3925	used to support Windows Hyper-V based guest paravirt drivers(VMBus).
3926	
3927	In order to use SynIC, it has to be activated by setting this
3928	capability via KVM_ENABLE_CAP ioctl on the vcpu fd. Note that this
3929	will disable the use of APIC hardware virtualization even if supported
3930	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.