About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / virtual / kvm / api.txt




Custom Search

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