About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / kvm / api.txt


Based on kernel version 2.6.39.1. Page generated on 2011-06-03 13:47 EST.

1	The Definitive KVM (Kernel-based Virtual Machine) API Documentation
2	===================================================================
3	
4	1. General description
5	
6	The kvm API is a set of ioctls that are issued to control various aspects
7	of a virtual machine.  The ioctls belong to three classes
8	
9	 - System ioctls: These query and set global attributes which affect the
10	   whole kvm subsystem.  In addition a system ioctl is used to create
11	   virtual machines
12	
13	 - VM ioctls: These query and set attributes that affect an entire virtual
14	   machine, for example memory layout.  In addition a VM ioctl is used to
15	   create virtual cpus (vcpus).
16	
17	   Only run VM ioctls from the same process (address space) that was used
18	   to create the VM.
19	
20	 - vcpu ioctls: These query and set attributes that control the operation
21	   of a single virtual cpu.
22	
23	   Only run vcpu ioctls from the same thread that was used to create the
24	   vcpu.
25	
26	2. File descriptors
27	
28	The kvm API is centered around file descriptors.  An initial
29	open("/dev/kvm") obtains a handle to the kvm subsystem; this handle
30	can be used to issue system ioctls.  A KVM_CREATE_VM ioctl on this
31	handle will create a VM file descriptor which can be used to issue VM
32	ioctls.  A KVM_CREATE_VCPU ioctl on a VM fd will create a virtual cpu
33	and return a file descriptor pointing to it.  Finally, ioctls on a vcpu
34	fd can be used to control the vcpu, including the important task of
35	actually running guest code.
36	
37	In general file descriptors can be migrated among processes by means
38	of fork() and the SCM_RIGHTS facility of unix domain socket.  These
39	kinds of tricks are explicitly not supported by kvm.  While they will
40	not cause harm to the host, their actual behavior is not guaranteed by
41	the API.  The only supported use is one virtual machine per process,
42	and one vcpu per thread.
43	
44	3. Extensions
45	
46	As of Linux 2.6.22, the KVM ABI has been stabilized: no backward
47	incompatible change are allowed.  However, there is an extension
48	facility that allows backward-compatible extensions to the API to be
49	queried and used.
50	
51	The extension mechanism is not based on on the Linux version number.
52	Instead, kvm defines extension identifiers and a facility to query
53	whether a particular extension identifier is available.  If it is, a
54	set of ioctls is available for application use.
55	
56	4. API description
57	
58	This section describes ioctls that can be used to control kvm guests.
59	For each ioctl, the following information is provided along with a
60	description:
61	
62	  Capability: which KVM extension provides this ioctl.  Can be 'basic',
63	      which means that is will be provided by any kernel that supports
64	      API version 12 (see section 4.1), or a KVM_CAP_xyz constant, which
65	      means availability needs to be checked with KVM_CHECK_EXTENSION
66	      (see section 4.4).
67	
68	  Architectures: which instruction set architectures provide this ioctl.
69	      x86 includes both i386 and x86_64.
70	
71	  Type: system, vm, or vcpu.
72	
73	  Parameters: what parameters are accepted by the ioctl.
74	
75	  Returns: the return value.  General error numbers (EBADF, ENOMEM, EINVAL)
76	      are not detailed, but errors with specific meanings are.
77	
78	4.1 KVM_GET_API_VERSION
79	
80	Capability: basic
81	Architectures: all
82	Type: system ioctl
83	Parameters: none
84	Returns: the constant KVM_API_VERSION (=12)
85	
86	This identifies the API version as the stable kvm API. It is not
87	expected that this number will change.  However, Linux 2.6.20 and
88	2.6.21 report earlier versions; these are not documented and not
89	supported.  Applications should refuse to run if KVM_GET_API_VERSION
90	returns a value other than 12.  If this check passes, all ioctls
91	described as 'basic' will be available.
92	
93	4.2 KVM_CREATE_VM
94	
95	Capability: basic
96	Architectures: all
97	Type: system ioctl
98	Parameters: none
99	Returns: a VM fd that can be used to control the new virtual machine.
100	
101	The new VM has no virtual cpus and no memory.  An mmap() of a VM fd
102	will access the virtual machine's physical address space; offset zero
103	corresponds to guest physical address zero.  Use of mmap() on a VM fd
104	is discouraged if userspace memory allocation (KVM_CAP_USER_MEMORY) is
105	available.
106	
107	4.3 KVM_GET_MSR_INDEX_LIST
108	
109	Capability: basic
110	Architectures: x86
111	Type: system
112	Parameters: struct kvm_msr_list (in/out)
113	Returns: 0 on success; -1 on error
114	Errors:
115	  E2BIG:     the msr index list is to be to fit in the array specified by
116	             the user.
117	
118	struct kvm_msr_list {
119		__u32 nmsrs; /* number of msrs in entries */
120		__u32 indices[0];
121	};
122	
123	This ioctl returns the guest msrs that are supported.  The list varies
124	by kvm version and host processor, but does not change otherwise.  The
125	user fills in the size of the indices array in nmsrs, and in return
126	kvm adjusts nmsrs to reflect the actual number of msrs and fills in
127	the indices array with their numbers.
128	
129	Note: if kvm indicates supports MCE (KVM_CAP_MCE), then the MCE bank MSRs are
130	not returned in the MSR list, as different vcpus can have a different number
131	of banks, as set via the KVM_X86_SETUP_MCE ioctl.
132	
133	4.4 KVM_CHECK_EXTENSION
134	
135	Capability: basic
136	Architectures: all
137	Type: system ioctl
138	Parameters: extension identifier (KVM_CAP_*)
139	Returns: 0 if unsupported; 1 (or some other positive integer) if supported
140	
141	The API allows the application to query about extensions to the core
142	kvm API.  Userspace passes an extension identifier (an integer) and
143	receives an integer that describes the extension availability.
144	Generally 0 means no and 1 means yes, but some extensions may report
145	additional information in the integer return value.
146	
147	4.5 KVM_GET_VCPU_MMAP_SIZE
148	
149	Capability: basic
150	Architectures: all
151	Type: system ioctl
152	Parameters: none
153	Returns: size of vcpu mmap area, in bytes
154	
155	The KVM_RUN ioctl (cf.) communicates with userspace via a shared
156	memory region.  This ioctl returns the size of that region.  See the
157	KVM_RUN documentation for details.
158	
159	4.6 KVM_SET_MEMORY_REGION
160	
161	Capability: basic
162	Architectures: all
163	Type: vm ioctl
164	Parameters: struct kvm_memory_region (in)
165	Returns: 0 on success, -1 on error
166	
167	This ioctl is obsolete and has been removed.
168	
169	4.7 KVM_CREATE_VCPU
170	
171	Capability: basic
172	Architectures: all
173	Type: vm ioctl
174	Parameters: vcpu id (apic id on x86)
175	Returns: vcpu fd on success, -1 on error
176	
177	This API adds a vcpu to a virtual machine.  The vcpu id is a small integer
178	in the range [0, max_vcpus).
179	
180	4.8 KVM_GET_DIRTY_LOG (vm ioctl)
181	
182	Capability: basic
183	Architectures: x86
184	Type: vm ioctl
185	Parameters: struct kvm_dirty_log (in/out)
186	Returns: 0 on success, -1 on error
187	
188	/* for KVM_GET_DIRTY_LOG */
189	struct kvm_dirty_log {
190		__u32 slot;
191		__u32 padding;
192		union {
193			void __user *dirty_bitmap; /* one bit per page */
194			__u64 padding;
195		};
196	};
197	
198	Given a memory slot, return a bitmap containing any pages dirtied
199	since the last call to this ioctl.  Bit 0 is the first page in the
200	memory slot.  Ensure the entire structure is cleared to avoid padding
201	issues.
202	
203	4.9 KVM_SET_MEMORY_ALIAS
204	
205	Capability: basic
206	Architectures: x86
207	Type: vm ioctl
208	Parameters: struct kvm_memory_alias (in)
209	Returns: 0 (success), -1 (error)
210	
211	This ioctl is obsolete and has been removed.
212	
213	4.10 KVM_RUN
214	
215	Capability: basic
216	Architectures: all
217	Type: vcpu ioctl
218	Parameters: none
219	Returns: 0 on success, -1 on error
220	Errors:
221	  EINTR:     an unmasked signal is pending
222	
223	This ioctl is used to run a guest virtual cpu.  While there are no
224	explicit parameters, there is an implicit parameter block that can be
225	obtained by mmap()ing the vcpu fd at offset 0, with the size given by
226	KVM_GET_VCPU_MMAP_SIZE.  The parameter block is formatted as a 'struct
227	kvm_run' (see below).
228	
229	4.11 KVM_GET_REGS
230	
231	Capability: basic
232	Architectures: all
233	Type: vcpu ioctl
234	Parameters: struct kvm_regs (out)
235	Returns: 0 on success, -1 on error
236	
237	Reads the general purpose registers from the vcpu.
238	
239	/* x86 */
240	struct kvm_regs {
241		/* out (KVM_GET_REGS) / in (KVM_SET_REGS) */
242		__u64 rax, rbx, rcx, rdx;
243		__u64 rsi, rdi, rsp, rbp;
244		__u64 r8,  r9,  r10, r11;
245		__u64 r12, r13, r14, r15;
246		__u64 rip, rflags;
247	};
248	
249	4.12 KVM_SET_REGS
250	
251	Capability: basic
252	Architectures: all
253	Type: vcpu ioctl
254	Parameters: struct kvm_regs (in)
255	Returns: 0 on success, -1 on error
256	
257	Writes the general purpose registers into the vcpu.
258	
259	See KVM_GET_REGS for the data structure.
260	
261	4.13 KVM_GET_SREGS
262	
263	Capability: basic
264	Architectures: x86
265	Type: vcpu ioctl
266	Parameters: struct kvm_sregs (out)
267	Returns: 0 on success, -1 on error
268	
269	Reads special registers from the vcpu.
270	
271	/* x86 */
272	struct kvm_sregs {
273		struct kvm_segment cs, ds, es, fs, gs, ss;
274		struct kvm_segment tr, ldt;
275		struct kvm_dtable gdt, idt;
276		__u64 cr0, cr2, cr3, cr4, cr8;
277		__u64 efer;
278		__u64 apic_base;
279		__u64 interrupt_bitmap[(KVM_NR_INTERRUPTS + 63) / 64];
280	};
281	
282	interrupt_bitmap is a bitmap of pending external interrupts.  At most
283	one bit may be set.  This interrupt has been acknowledged by the APIC
284	but not yet injected into the cpu core.
285	
286	4.14 KVM_SET_SREGS
287	
288	Capability: basic
289	Architectures: x86
290	Type: vcpu ioctl
291	Parameters: struct kvm_sregs (in)
292	Returns: 0 on success, -1 on error
293	
294	Writes special registers into the vcpu.  See KVM_GET_SREGS for the
295	data structures.
296	
297	4.15 KVM_TRANSLATE
298	
299	Capability: basic
300	Architectures: x86
301	Type: vcpu ioctl
302	Parameters: struct kvm_translation (in/out)
303	Returns: 0 on success, -1 on error
304	
305	Translates a virtual address according to the vcpu's current address
306	translation mode.
307	
308	struct kvm_translation {
309		/* in */
310		__u64 linear_address;
311	
312		/* out */
313		__u64 physical_address;
314		__u8  valid;
315		__u8  writeable;
316		__u8  usermode;
317		__u8  pad[5];
318	};
319	
320	4.16 KVM_INTERRUPT
321	
322	Capability: basic
323	Architectures: x86, ppc
324	Type: vcpu ioctl
325	Parameters: struct kvm_interrupt (in)
326	Returns: 0 on success, -1 on error
327	
328	Queues a hardware interrupt vector to be injected.  This is only
329	useful if in-kernel local APIC or equivalent is not used.
330	
331	/* for KVM_INTERRUPT */
332	struct kvm_interrupt {
333		/* in */
334		__u32 irq;
335	};
336	
337	X86:
338	
339	Note 'irq' is an interrupt vector, not an interrupt pin or line.
340	
341	PPC:
342	
343	Queues an external interrupt to be injected. This ioctl is overleaded
344	with 3 different irq values:
345	
346	a) KVM_INTERRUPT_SET
347	
348	  This injects an edge type external interrupt into the guest once it's ready
349	  to receive interrupts. When injected, the interrupt is done.
350	
351	b) KVM_INTERRUPT_UNSET
352	
353	  This unsets any pending interrupt.
354	
355	  Only available with KVM_CAP_PPC_UNSET_IRQ.
356	
357	c) KVM_INTERRUPT_SET_LEVEL
358	
359	  This injects a level type external interrupt into the guest context. The
360	  interrupt stays pending until a specific ioctl with KVM_INTERRUPT_UNSET
361	  is triggered.
362	
363	  Only available with KVM_CAP_PPC_IRQ_LEVEL.
364	
365	Note that any value for 'irq' other than the ones stated above is invalid
366	and incurs unexpected behavior.
367	
368	4.17 KVM_DEBUG_GUEST
369	
370	Capability: basic
371	Architectures: none
372	Type: vcpu ioctl
373	Parameters: none)
374	Returns: -1 on error
375	
376	Support for this has been removed.  Use KVM_SET_GUEST_DEBUG instead.
377	
378	4.18 KVM_GET_MSRS
379	
380	Capability: basic
381	Architectures: x86
382	Type: vcpu ioctl
383	Parameters: struct kvm_msrs (in/out)
384	Returns: 0 on success, -1 on error
385	
386	Reads model-specific registers from the vcpu.  Supported msr indices can
387	be obtained using KVM_GET_MSR_INDEX_LIST.
388	
389	struct kvm_msrs {
390		__u32 nmsrs; /* number of msrs in entries */
391		__u32 pad;
392	
393		struct kvm_msr_entry entries[0];
394	};
395	
396	struct kvm_msr_entry {
397		__u32 index;
398		__u32 reserved;
399		__u64 data;
400	};
401	
402	Application code should set the 'nmsrs' member (which indicates the
403	size of the entries array) and the 'index' member of each array entry.
404	kvm will fill in the 'data' member.
405	
406	4.19 KVM_SET_MSRS
407	
408	Capability: basic
409	Architectures: x86
410	Type: vcpu ioctl
411	Parameters: struct kvm_msrs (in)
412	Returns: 0 on success, -1 on error
413	
414	Writes model-specific registers to the vcpu.  See KVM_GET_MSRS for the
415	data structures.
416	
417	Application code should set the 'nmsrs' member (which indicates the
418	size of the entries array), and the 'index' and 'data' members of each
419	array entry.
420	
421	4.20 KVM_SET_CPUID
422	
423	Capability: basic
424	Architectures: x86
425	Type: vcpu ioctl
426	Parameters: struct kvm_cpuid (in)
427	Returns: 0 on success, -1 on error
428	
429	Defines the vcpu responses to the cpuid instruction.  Applications
430	should use the KVM_SET_CPUID2 ioctl if available.
431	
432	
433	struct kvm_cpuid_entry {
434		__u32 function;
435		__u32 eax;
436		__u32 ebx;
437		__u32 ecx;
438		__u32 edx;
439		__u32 padding;
440	};
441	
442	/* for KVM_SET_CPUID */
443	struct kvm_cpuid {
444		__u32 nent;
445		__u32 padding;
446		struct kvm_cpuid_entry entries[0];
447	};
448	
449	4.21 KVM_SET_SIGNAL_MASK
450	
451	Capability: basic
452	Architectures: x86
453	Type: vcpu ioctl
454	Parameters: struct kvm_signal_mask (in)
455	Returns: 0 on success, -1 on error
456	
457	Defines which signals are blocked during execution of KVM_RUN.  This
458	signal mask temporarily overrides the threads signal mask.  Any
459	unblocked signal received (except SIGKILL and SIGSTOP, which retain
460	their traditional behaviour) will cause KVM_RUN to return with -EINTR.
461	
462	Note the signal will only be delivered if not blocked by the original
463	signal mask.
464	
465	/* for KVM_SET_SIGNAL_MASK */
466	struct kvm_signal_mask {
467		__u32 len;
468		__u8  sigset[0];
469	};
470	
471	4.22 KVM_GET_FPU
472	
473	Capability: basic
474	Architectures: x86
475	Type: vcpu ioctl
476	Parameters: struct kvm_fpu (out)
477	Returns: 0 on success, -1 on error
478	
479	Reads the floating point state from the vcpu.
480	
481	/* for KVM_GET_FPU and KVM_SET_FPU */
482	struct kvm_fpu {
483		__u8  fpr[8][16];
484		__u16 fcw;
485		__u16 fsw;
486		__u8  ftwx;  /* in fxsave format */
487		__u8  pad1;
488		__u16 last_opcode;
489		__u64 last_ip;
490		__u64 last_dp;
491		__u8  xmm[16][16];
492		__u32 mxcsr;
493		__u32 pad2;
494	};
495	
496	4.23 KVM_SET_FPU
497	
498	Capability: basic
499	Architectures: x86
500	Type: vcpu ioctl
501	Parameters: struct kvm_fpu (in)
502	Returns: 0 on success, -1 on error
503	
504	Writes the floating point state to the vcpu.
505	
506	/* for KVM_GET_FPU and KVM_SET_FPU */
507	struct kvm_fpu {
508		__u8  fpr[8][16];
509		__u16 fcw;
510		__u16 fsw;
511		__u8  ftwx;  /* in fxsave format */
512		__u8  pad1;
513		__u16 last_opcode;
514		__u64 last_ip;
515		__u64 last_dp;
516		__u8  xmm[16][16];
517		__u32 mxcsr;
518		__u32 pad2;
519	};
520	
521	4.24 KVM_CREATE_IRQCHIP
522	
523	Capability: KVM_CAP_IRQCHIP
524	Architectures: x86, ia64
525	Type: vm ioctl
526	Parameters: none
527	Returns: 0 on success, -1 on error
528	
529	Creates an interrupt controller model in the kernel.  On x86, creates a virtual
530	ioapic, a virtual PIC (two PICs, nested), and sets up future vcpus to have a
531	local APIC.  IRQ routing for GSIs 0-15 is set to both PIC and IOAPIC; GSI 16-23
532	only go to the IOAPIC.  On ia64, a IOSAPIC is created.
533	
534	4.25 KVM_IRQ_LINE
535	
536	Capability: KVM_CAP_IRQCHIP
537	Architectures: x86, ia64
538	Type: vm ioctl
539	Parameters: struct kvm_irq_level
540	Returns: 0 on success, -1 on error
541	
542	Sets the level of a GSI input to the interrupt controller model in the kernel.
543	Requires that an interrupt controller model has been previously created with
544	KVM_CREATE_IRQCHIP.  Note that edge-triggered interrupts require the level
545	to be set to 1 and then back to 0.
546	
547	struct kvm_irq_level {
548		union {
549			__u32 irq;     /* GSI */
550			__s32 status;  /* not used for KVM_IRQ_LEVEL */
551		};
552		__u32 level;           /* 0 or 1 */
553	};
554	
555	4.26 KVM_GET_IRQCHIP
556	
557	Capability: KVM_CAP_IRQCHIP
558	Architectures: x86, ia64
559	Type: vm ioctl
560	Parameters: struct kvm_irqchip (in/out)
561	Returns: 0 on success, -1 on error
562	
563	Reads the state of a kernel interrupt controller created with
564	KVM_CREATE_IRQCHIP into a buffer provided by the caller.
565	
566	struct kvm_irqchip {
567		__u32 chip_id;  /* 0 = PIC1, 1 = PIC2, 2 = IOAPIC */
568		__u32 pad;
569	        union {
570			char dummy[512];  /* reserving space */
571			struct kvm_pic_state pic;
572			struct kvm_ioapic_state ioapic;
573		} chip;
574	};
575	
576	4.27 KVM_SET_IRQCHIP
577	
578	Capability: KVM_CAP_IRQCHIP
579	Architectures: x86, ia64
580	Type: vm ioctl
581	Parameters: struct kvm_irqchip (in)
582	Returns: 0 on success, -1 on error
583	
584	Sets the state of a kernel interrupt controller created with
585	KVM_CREATE_IRQCHIP from a buffer provided by the caller.
586	
587	struct kvm_irqchip {
588		__u32 chip_id;  /* 0 = PIC1, 1 = PIC2, 2 = IOAPIC */
589		__u32 pad;
590	        union {
591			char dummy[512];  /* reserving space */
592			struct kvm_pic_state pic;
593			struct kvm_ioapic_state ioapic;
594		} chip;
595	};
596	
597	4.28 KVM_XEN_HVM_CONFIG
598	
599	Capability: KVM_CAP_XEN_HVM
600	Architectures: x86
601	Type: vm ioctl
602	Parameters: struct kvm_xen_hvm_config (in)
603	Returns: 0 on success, -1 on error
604	
605	Sets the MSR that the Xen HVM guest uses to initialize its hypercall
606	page, and provides the starting address and size of the hypercall
607	blobs in userspace.  When the guest writes the MSR, kvm copies one
608	page of a blob (32- or 64-bit, depending on the vcpu mode) to guest
609	memory.
610	
611	struct kvm_xen_hvm_config {
612		__u32 flags;
613		__u32 msr;
614		__u64 blob_addr_32;
615		__u64 blob_addr_64;
616		__u8 blob_size_32;
617		__u8 blob_size_64;
618		__u8 pad2[30];
619	};
620	
621	4.29 KVM_GET_CLOCK
622	
623	Capability: KVM_CAP_ADJUST_CLOCK
624	Architectures: x86
625	Type: vm ioctl
626	Parameters: struct kvm_clock_data (out)
627	Returns: 0 on success, -1 on error
628	
629	Gets the current timestamp of kvmclock as seen by the current guest. In
630	conjunction with KVM_SET_CLOCK, it is used to ensure monotonicity on scenarios
631	such as migration.
632	
633	struct kvm_clock_data {
634		__u64 clock;  /* kvmclock current value */
635		__u32 flags;
636		__u32 pad[9];
637	};
638	
639	4.30 KVM_SET_CLOCK
640	
641	Capability: KVM_CAP_ADJUST_CLOCK
642	Architectures: x86
643	Type: vm ioctl
644	Parameters: struct kvm_clock_data (in)
645	Returns: 0 on success, -1 on error
646	
647	Sets the current timestamp of kvmclock to the value specified in its parameter.
648	In conjunction with KVM_GET_CLOCK, it is used to ensure monotonicity on scenarios
649	such as migration.
650	
651	struct kvm_clock_data {
652		__u64 clock;  /* kvmclock current value */
653		__u32 flags;
654		__u32 pad[9];
655	};
656	
657	4.31 KVM_GET_VCPU_EVENTS
658	
659	Capability: KVM_CAP_VCPU_EVENTS
660	Extended by: KVM_CAP_INTR_SHADOW
661	Architectures: x86
662	Type: vm ioctl
663	Parameters: struct kvm_vcpu_event (out)
664	Returns: 0 on success, -1 on error
665	
666	Gets currently pending exceptions, interrupts, and NMIs as well as related
667	states of the vcpu.
668	
669	struct kvm_vcpu_events {
670		struct {
671			__u8 injected;
672			__u8 nr;
673			__u8 has_error_code;
674			__u8 pad;
675			__u32 error_code;
676		} exception;
677		struct {
678			__u8 injected;
679			__u8 nr;
680			__u8 soft;
681			__u8 shadow;
682		} interrupt;
683		struct {
684			__u8 injected;
685			__u8 pending;
686			__u8 masked;
687			__u8 pad;
688		} nmi;
689		__u32 sipi_vector;
690		__u32 flags;
691	};
692	
693	KVM_VCPUEVENT_VALID_SHADOW may be set in the flags field to signal that
694	interrupt.shadow contains a valid state. Otherwise, this field is undefined.
695	
696	4.32 KVM_SET_VCPU_EVENTS
697	
698	Capability: KVM_CAP_VCPU_EVENTS
699	Extended by: KVM_CAP_INTR_SHADOW
700	Architectures: x86
701	Type: vm ioctl
702	Parameters: struct kvm_vcpu_event (in)
703	Returns: 0 on success, -1 on error
704	
705	Set pending exceptions, interrupts, and NMIs as well as related states of the
706	vcpu.
707	
708	See KVM_GET_VCPU_EVENTS for the data structure.
709	
710	Fields that may be modified asynchronously by running VCPUs can be excluded
711	from the update. These fields are nmi.pending and sipi_vector. Keep the
712	corresponding bits in the flags field cleared to suppress overwriting the
713	current in-kernel state. The bits are:
714	
715	KVM_VCPUEVENT_VALID_NMI_PENDING - transfer nmi.pending to the kernel
716	KVM_VCPUEVENT_VALID_SIPI_VECTOR - transfer sipi_vector
717	
718	If KVM_CAP_INTR_SHADOW is available, KVM_VCPUEVENT_VALID_SHADOW can be set in
719	the flags field to signal that interrupt.shadow contains a valid state and
720	shall be written into the VCPU.
721	
722	4.33 KVM_GET_DEBUGREGS
723	
724	Capability: KVM_CAP_DEBUGREGS
725	Architectures: x86
726	Type: vm ioctl
727	Parameters: struct kvm_debugregs (out)
728	Returns: 0 on success, -1 on error
729	
730	Reads debug registers from the vcpu.
731	
732	struct kvm_debugregs {
733		__u64 db[4];
734		__u64 dr6;
735		__u64 dr7;
736		__u64 flags;
737		__u64 reserved[9];
738	};
739	
740	4.34 KVM_SET_DEBUGREGS
741	
742	Capability: KVM_CAP_DEBUGREGS
743	Architectures: x86
744	Type: vm ioctl
745	Parameters: struct kvm_debugregs (in)
746	Returns: 0 on success, -1 on error
747	
748	Writes debug registers into the vcpu.
749	
750	See KVM_GET_DEBUGREGS for the data structure. The flags field is unused
751	yet and must be cleared on entry.
752	
753	4.35 KVM_SET_USER_MEMORY_REGION
754	
755	Capability: KVM_CAP_USER_MEM
756	Architectures: all
757	Type: vm ioctl
758	Parameters: struct kvm_userspace_memory_region (in)
759	Returns: 0 on success, -1 on error
760	
761	struct kvm_userspace_memory_region {
762		__u32 slot;
763		__u32 flags;
764		__u64 guest_phys_addr;
765		__u64 memory_size; /* bytes */
766		__u64 userspace_addr; /* start of the userspace allocated memory */
767	};
768	
769	/* for kvm_memory_region::flags */
770	#define KVM_MEM_LOG_DIRTY_PAGES  1UL
771	
772	This ioctl allows the user to create or modify a guest physical memory
773	slot.  When changing an existing slot, it may be moved in the guest
774	physical memory space, or its flags may be modified.  It may not be
775	resized.  Slots may not overlap in guest physical address space.
776	
777	Memory for the region is taken starting at the address denoted by the
778	field userspace_addr, which must point at user addressable memory for
779	the entire memory slot size.  Any object may back this memory, including
780	anonymous memory, ordinary files, and hugetlbfs.
781	
782	It is recommended that the lower 21 bits of guest_phys_addr and userspace_addr
783	be identical.  This allows large pages in the guest to be backed by large
784	pages in the host.
785	
786	The flags field supports just one flag, KVM_MEM_LOG_DIRTY_PAGES, which
787	instructs kvm to keep track of writes to memory within the slot.  See
788	the KVM_GET_DIRTY_LOG ioctl.
789	
790	When the KVM_CAP_SYNC_MMU capability, changes in the backing of the memory
791	region are automatically reflected into the guest.  For example, an mmap()
792	that affects the region will be made visible immediately.  Another example
793	is madvise(MADV_DROP).
794	
795	It is recommended to use this API instead of the KVM_SET_MEMORY_REGION ioctl.
796	The KVM_SET_MEMORY_REGION does not allow fine grained control over memory
797	allocation and is deprecated.
798	
799	4.36 KVM_SET_TSS_ADDR
800	
801	Capability: KVM_CAP_SET_TSS_ADDR
802	Architectures: x86
803	Type: vm ioctl
804	Parameters: unsigned long tss_address (in)
805	Returns: 0 on success, -1 on error
806	
807	This ioctl defines the physical address of a three-page region in the guest
808	physical address space.  The region must be within the first 4GB of the
809	guest physical address space and must not conflict with any memory slot
810	or any mmio address.  The guest may malfunction if it accesses this memory
811	region.
812	
813	This ioctl is required on Intel-based hosts.  This is needed on Intel hardware
814	because of a quirk in the virtualization implementation (see the internals
815	documentation when it pops into existence).
816	
817	4.37 KVM_ENABLE_CAP
818	
819	Capability: KVM_CAP_ENABLE_CAP
820	Architectures: ppc
821	Type: vcpu ioctl
822	Parameters: struct kvm_enable_cap (in)
823	Returns: 0 on success; -1 on error
824	
825	+Not all extensions are enabled by default. Using this ioctl the application
826	can enable an extension, making it available to the guest.
827	
828	On systems that do not support this ioctl, it always fails. On systems that
829	do support it, it only works for extensions that are supported for enablement.
830	
831	To check if a capability can be enabled, the KVM_CHECK_EXTENSION ioctl should
832	be used.
833	
834	struct kvm_enable_cap {
835	       /* in */
836	       __u32 cap;
837	
838	The capability that is supposed to get enabled.
839	
840	       __u32 flags;
841	
842	A bitfield indicating future enhancements. Has to be 0 for now.
843	
844	       __u64 args[4];
845	
846	Arguments for enabling a feature. If a feature needs initial values to
847	function properly, this is the place to put them.
848	
849	       __u8  pad[64];
850	};
851	
852	4.38 KVM_GET_MP_STATE
853	
854	Capability: KVM_CAP_MP_STATE
855	Architectures: x86, ia64
856	Type: vcpu ioctl
857	Parameters: struct kvm_mp_state (out)
858	Returns: 0 on success; -1 on error
859	
860	struct kvm_mp_state {
861		__u32 mp_state;
862	};
863	
864	Returns the vcpu's current "multiprocessing state" (though also valid on
865	uniprocessor guests).
866	
867	Possible values are:
868	
869	 - KVM_MP_STATE_RUNNABLE:        the vcpu is currently running
870	 - KVM_MP_STATE_UNINITIALIZED:   the vcpu is an application processor (AP)
871	                                 which has not yet received an INIT signal
872	 - KVM_MP_STATE_INIT_RECEIVED:   the vcpu has received an INIT signal, and is
873	                                 now ready for a SIPI
874	 - KVM_MP_STATE_HALTED:          the vcpu has executed a HLT instruction and
875	                                 is waiting for an interrupt
876	 - KVM_MP_STATE_SIPI_RECEIVED:   the vcpu has just received a SIPI (vector
877	                                 accessible via KVM_GET_VCPU_EVENTS)
878	
879	This ioctl is only useful after KVM_CREATE_IRQCHIP.  Without an in-kernel
880	irqchip, the multiprocessing state must be maintained by userspace.
881	
882	4.39 KVM_SET_MP_STATE
883	
884	Capability: KVM_CAP_MP_STATE
885	Architectures: x86, ia64
886	Type: vcpu ioctl
887	Parameters: struct kvm_mp_state (in)
888	Returns: 0 on success; -1 on error
889	
890	Sets the vcpu's current "multiprocessing state"; see KVM_GET_MP_STATE for
891	arguments.
892	
893	This ioctl is only useful after KVM_CREATE_IRQCHIP.  Without an in-kernel
894	irqchip, the multiprocessing state must be maintained by userspace.
895	
896	4.40 KVM_SET_IDENTITY_MAP_ADDR
897	
898	Capability: KVM_CAP_SET_IDENTITY_MAP_ADDR
899	Architectures: x86
900	Type: vm ioctl
901	Parameters: unsigned long identity (in)
902	Returns: 0 on success, -1 on error
903	
904	This ioctl defines the physical address of a one-page region in the guest
905	physical address space.  The region must be within the first 4GB of the
906	guest physical address space and must not conflict with any memory slot
907	or any mmio address.  The guest may malfunction if it accesses this memory
908	region.
909	
910	This ioctl is required on Intel-based hosts.  This is needed on Intel hardware
911	because of a quirk in the virtualization implementation (see the internals
912	documentation when it pops into existence).
913	
914	4.41 KVM_SET_BOOT_CPU_ID
915	
916	Capability: KVM_CAP_SET_BOOT_CPU_ID
917	Architectures: x86, ia64
918	Type: vm ioctl
919	Parameters: unsigned long vcpu_id
920	Returns: 0 on success, -1 on error
921	
922	Define which vcpu is the Bootstrap Processor (BSP).  Values are the same
923	as the vcpu id in KVM_CREATE_VCPU.  If this ioctl is not called, the default
924	is vcpu 0.
925	
926	4.42 KVM_GET_XSAVE
927	
928	Capability: KVM_CAP_XSAVE
929	Architectures: x86
930	Type: vcpu ioctl
931	Parameters: struct kvm_xsave (out)
932	Returns: 0 on success, -1 on error
933	
934	struct kvm_xsave {
935		__u32 region[1024];
936	};
937	
938	This ioctl would copy current vcpu's xsave struct to the userspace.
939	
940	4.43 KVM_SET_XSAVE
941	
942	Capability: KVM_CAP_XSAVE
943	Architectures: x86
944	Type: vcpu ioctl
945	Parameters: struct kvm_xsave (in)
946	Returns: 0 on success, -1 on error
947	
948	struct kvm_xsave {
949		__u32 region[1024];
950	};
951	
952	This ioctl would copy userspace's xsave struct to the kernel.
953	
954	4.44 KVM_GET_XCRS
955	
956	Capability: KVM_CAP_XCRS
957	Architectures: x86
958	Type: vcpu ioctl
959	Parameters: struct kvm_xcrs (out)
960	Returns: 0 on success, -1 on error
961	
962	struct kvm_xcr {
963		__u32 xcr;
964		__u32 reserved;
965		__u64 value;
966	};
967	
968	struct kvm_xcrs {
969		__u32 nr_xcrs;
970		__u32 flags;
971		struct kvm_xcr xcrs[KVM_MAX_XCRS];
972		__u64 padding[16];
973	};
974	
975	This ioctl would copy current vcpu's xcrs to the userspace.
976	
977	4.45 KVM_SET_XCRS
978	
979	Capability: KVM_CAP_XCRS
980	Architectures: x86
981	Type: vcpu ioctl
982	Parameters: struct kvm_xcrs (in)
983	Returns: 0 on success, -1 on error
984	
985	struct kvm_xcr {
986		__u32 xcr;
987		__u32 reserved;
988		__u64 value;
989	};
990	
991	struct kvm_xcrs {
992		__u32 nr_xcrs;
993		__u32 flags;
994		struct kvm_xcr xcrs[KVM_MAX_XCRS];
995		__u64 padding[16];
996	};
997	
998	This ioctl would set vcpu's xcr to the value userspace specified.
999	
1000	4.46 KVM_GET_SUPPORTED_CPUID
1001	
1002	Capability: KVM_CAP_EXT_CPUID
1003	Architectures: x86
1004	Type: system ioctl
1005	Parameters: struct kvm_cpuid2 (in/out)
1006	Returns: 0 on success, -1 on error
1007	
1008	struct kvm_cpuid2 {
1009		__u32 nent;
1010		__u32 padding;
1011		struct kvm_cpuid_entry2 entries[0];
1012	};
1013	
1014	#define KVM_CPUID_FLAG_SIGNIFCANT_INDEX 1
1015	#define KVM_CPUID_FLAG_STATEFUL_FUNC    2
1016	#define KVM_CPUID_FLAG_STATE_READ_NEXT  4
1017	
1018	struct kvm_cpuid_entry2 {
1019		__u32 function;
1020		__u32 index;
1021		__u32 flags;
1022		__u32 eax;
1023		__u32 ebx;
1024		__u32 ecx;
1025		__u32 edx;
1026		__u32 padding[3];
1027	};
1028	
1029	This ioctl returns x86 cpuid features which are supported by both the hardware
1030	and kvm.  Userspace can use the information returned by this ioctl to
1031	construct cpuid information (for KVM_SET_CPUID2) that is consistent with
1032	hardware, kernel, and userspace capabilities, and with user requirements (for
1033	example, the user may wish to constrain cpuid to emulate older hardware,
1034	or for feature consistency across a cluster).
1035	
1036	Userspace invokes KVM_GET_SUPPORTED_CPUID by passing a kvm_cpuid2 structure
1037	with the 'nent' field indicating the number of entries in the variable-size
1038	array 'entries'.  If the number of entries is too low to describe the cpu
1039	capabilities, an error (E2BIG) is returned.  If the number is too high,
1040	the 'nent' field is adjusted and an error (ENOMEM) is returned.  If the
1041	number is just right, the 'nent' field is adjusted to the number of valid
1042	entries in the 'entries' array, which is then filled.
1043	
1044	The entries returned are the host cpuid as returned by the cpuid instruction,
1045	with unknown or unsupported features masked out.  Some features (for example,
1046	x2apic), may not be present in the host cpu, but are exposed by kvm if it can
1047	emulate them efficiently. The fields in each entry are defined as follows:
1048	
1049	  function: the eax value used to obtain the entry
1050	  index: the ecx value used to obtain the entry (for entries that are
1051	         affected by ecx)
1052	  flags: an OR of zero or more of the following:
1053	        KVM_CPUID_FLAG_SIGNIFCANT_INDEX:
1054	           if the index field is valid
1055	        KVM_CPUID_FLAG_STATEFUL_FUNC:
1056	           if cpuid for this function returns different values for successive
1057	           invocations; there will be several entries with the same function,
1058	           all with this flag set
1059	        KVM_CPUID_FLAG_STATE_READ_NEXT:
1060	           for KVM_CPUID_FLAG_STATEFUL_FUNC entries, set if this entry is
1061	           the first entry to be read by a cpu
1062	   eax, ebx, ecx, edx: the values returned by the cpuid instruction for
1063	         this function/index combination
1064	
1065	4.47 KVM_PPC_GET_PVINFO
1066	
1067	Capability: KVM_CAP_PPC_GET_PVINFO
1068	Architectures: ppc
1069	Type: vm ioctl
1070	Parameters: struct kvm_ppc_pvinfo (out)
1071	Returns: 0 on success, !0 on error
1072	
1073	struct kvm_ppc_pvinfo {
1074		__u32 flags;
1075		__u32 hcall[4];
1076		__u8  pad[108];
1077	};
1078	
1079	This ioctl fetches PV specific information that need to be passed to the guest
1080	using the device tree or other means from vm context.
1081	
1082	For now the only implemented piece of information distributed here is an array
1083	of 4 instructions that make up a hypercall.
1084	
1085	If any additional field gets added to this structure later on, a bit for that
1086	additional piece of information will be set in the flags bitmap.
1087	
1088	4.48 KVM_ASSIGN_PCI_DEVICE
1089	
1090	Capability: KVM_CAP_DEVICE_ASSIGNMENT
1091	Architectures: x86 ia64
1092	Type: vm ioctl
1093	Parameters: struct kvm_assigned_pci_dev (in)
1094	Returns: 0 on success, -1 on error
1095	
1096	Assigns a host PCI device to the VM.
1097	
1098	struct kvm_assigned_pci_dev {
1099		__u32 assigned_dev_id;
1100		__u32 busnr;
1101		__u32 devfn;
1102		__u32 flags;
1103		__u32 segnr;
1104		union {
1105			__u32 reserved[11];
1106		};
1107	};
1108	
1109	The PCI device is specified by the triple segnr, busnr, and devfn.
1110	Identification in succeeding service requests is done via assigned_dev_id. The
1111	following flags are specified:
1112	
1113	/* Depends on KVM_CAP_IOMMU */
1114	#define KVM_DEV_ASSIGN_ENABLE_IOMMU	(1 << 0)
1115	
1116	4.49 KVM_DEASSIGN_PCI_DEVICE
1117	
1118	Capability: KVM_CAP_DEVICE_DEASSIGNMENT
1119	Architectures: x86 ia64
1120	Type: vm ioctl
1121	Parameters: struct kvm_assigned_pci_dev (in)
1122	Returns: 0 on success, -1 on error
1123	
1124	Ends PCI device assignment, releasing all associated resources.
1125	
1126	See KVM_CAP_DEVICE_ASSIGNMENT for the data structure. Only assigned_dev_id is
1127	used in kvm_assigned_pci_dev to identify the device.
1128	
1129	4.50 KVM_ASSIGN_DEV_IRQ
1130	
1131	Capability: KVM_CAP_ASSIGN_DEV_IRQ
1132	Architectures: x86 ia64
1133	Type: vm ioctl
1134	Parameters: struct kvm_assigned_irq (in)
1135	Returns: 0 on success, -1 on error
1136	
1137	Assigns an IRQ to a passed-through device.
1138	
1139	struct kvm_assigned_irq {
1140		__u32 assigned_dev_id;
1141		__u32 host_irq;
1142		__u32 guest_irq;
1143		__u32 flags;
1144		union {
1145			struct {
1146				__u32 addr_lo;
1147				__u32 addr_hi;
1148				__u32 data;
1149			} guest_msi;
1150			__u32 reserved[12];
1151		};
1152	};
1153	
1154	The following flags are defined:
1155	
1156	#define KVM_DEV_IRQ_HOST_INTX    (1 << 0)
1157	#define KVM_DEV_IRQ_HOST_MSI     (1 << 1)
1158	#define KVM_DEV_IRQ_HOST_MSIX    (1 << 2)
1159	
1160	#define KVM_DEV_IRQ_GUEST_INTX   (1 << 8)
1161	#define KVM_DEV_IRQ_GUEST_MSI    (1 << 9)
1162	#define KVM_DEV_IRQ_GUEST_MSIX   (1 << 10)
1163	
1164	It is not valid to specify multiple types per host or guest IRQ. However, the
1165	IRQ type of host and guest can differ or can even be null.
1166	
1167	4.51 KVM_DEASSIGN_DEV_IRQ
1168	
1169	Capability: KVM_CAP_ASSIGN_DEV_IRQ
1170	Architectures: x86 ia64
1171	Type: vm ioctl
1172	Parameters: struct kvm_assigned_irq (in)
1173	Returns: 0 on success, -1 on error
1174	
1175	Ends an IRQ assignment to a passed-through device.
1176	
1177	See KVM_ASSIGN_DEV_IRQ for the data structure. The target device is specified
1178	by assigned_dev_id, flags must correspond to the IRQ type specified on
1179	KVM_ASSIGN_DEV_IRQ. Partial deassignment of host or guest IRQ is allowed.
1180	
1181	4.52 KVM_SET_GSI_ROUTING
1182	
1183	Capability: KVM_CAP_IRQ_ROUTING
1184	Architectures: x86 ia64
1185	Type: vm ioctl
1186	Parameters: struct kvm_irq_routing (in)
1187	Returns: 0 on success, -1 on error
1188	
1189	Sets the GSI routing table entries, overwriting any previously set entries.
1190	
1191	struct kvm_irq_routing {
1192		__u32 nr;
1193		__u32 flags;
1194		struct kvm_irq_routing_entry entries[0];
1195	};
1196	
1197	No flags are specified so far, the corresponding field must be set to zero.
1198	
1199	struct kvm_irq_routing_entry {
1200		__u32 gsi;
1201		__u32 type;
1202		__u32 flags;
1203		__u32 pad;
1204		union {
1205			struct kvm_irq_routing_irqchip irqchip;
1206			struct kvm_irq_routing_msi msi;
1207			__u32 pad[8];
1208		} u;
1209	};
1210	
1211	/* gsi routing entry types */
1212	#define KVM_IRQ_ROUTING_IRQCHIP 1
1213	#define KVM_IRQ_ROUTING_MSI 2
1214	
1215	No flags are specified so far, the corresponding field must be set to zero.
1216	
1217	struct kvm_irq_routing_irqchip {
1218		__u32 irqchip;
1219		__u32 pin;
1220	};
1221	
1222	struct kvm_irq_routing_msi {
1223		__u32 address_lo;
1224		__u32 address_hi;
1225		__u32 data;
1226		__u32 pad;
1227	};
1228	
1229	4.53 KVM_ASSIGN_SET_MSIX_NR
1230	
1231	Capability: KVM_CAP_DEVICE_MSIX
1232	Architectures: x86 ia64
1233	Type: vm ioctl
1234	Parameters: struct kvm_assigned_msix_nr (in)
1235	Returns: 0 on success, -1 on error
1236	
1237	Set the number of MSI-X interrupts for an assigned device. This service can
1238	only be called once in the lifetime of an assigned device.
1239	
1240	struct kvm_assigned_msix_nr {
1241		__u32 assigned_dev_id;
1242		__u16 entry_nr;
1243		__u16 padding;
1244	};
1245	
1246	#define KVM_MAX_MSIX_PER_DEV		256
1247	
1248	4.54 KVM_ASSIGN_SET_MSIX_ENTRY
1249	
1250	Capability: KVM_CAP_DEVICE_MSIX
1251	Architectures: x86 ia64
1252	Type: vm ioctl
1253	Parameters: struct kvm_assigned_msix_entry (in)
1254	Returns: 0 on success, -1 on error
1255	
1256	Specifies the routing of an MSI-X assigned device interrupt to a GSI. Setting
1257	the GSI vector to zero means disabling the interrupt.
1258	
1259	struct kvm_assigned_msix_entry {
1260		__u32 assigned_dev_id;
1261		__u32 gsi;
1262		__u16 entry; /* The index of entry in the MSI-X table */
1263		__u16 padding[3];
1264	};
1265	
1266	5. The kvm_run structure
1267	
1268	Application code obtains a pointer to the kvm_run structure by
1269	mmap()ing a vcpu fd.  From that point, application code can control
1270	execution by changing fields in kvm_run prior to calling the KVM_RUN
1271	ioctl, and obtain information about the reason KVM_RUN returned by
1272	looking up structure members.
1273	
1274	struct kvm_run {
1275		/* in */
1276		__u8 request_interrupt_window;
1277	
1278	Request that KVM_RUN return when it becomes possible to inject external
1279	interrupts into the guest.  Useful in conjunction with KVM_INTERRUPT.
1280	
1281		__u8 padding1[7];
1282	
1283		/* out */
1284		__u32 exit_reason;
1285	
1286	When KVM_RUN has returned successfully (return value 0), this informs
1287	application code why KVM_RUN has returned.  Allowable values for this
1288	field are detailed below.
1289	
1290		__u8 ready_for_interrupt_injection;
1291	
1292	If request_interrupt_window has been specified, this field indicates
1293	an interrupt can be injected now with KVM_INTERRUPT.
1294	
1295		__u8 if_flag;
1296	
1297	The value of the current interrupt flag.  Only valid if in-kernel
1298	local APIC is not used.
1299	
1300		__u8 padding2[2];
1301	
1302		/* in (pre_kvm_run), out (post_kvm_run) */
1303		__u64 cr8;
1304	
1305	The value of the cr8 register.  Only valid if in-kernel local APIC is
1306	not used.  Both input and output.
1307	
1308		__u64 apic_base;
1309	
1310	The value of the APIC BASE msr.  Only valid if in-kernel local
1311	APIC is not used.  Both input and output.
1312	
1313		union {
1314			/* KVM_EXIT_UNKNOWN */
1315			struct {
1316				__u64 hardware_exit_reason;
1317			} hw;
1318	
1319	If exit_reason is KVM_EXIT_UNKNOWN, the vcpu has exited due to unknown
1320	reasons.  Further architecture-specific information is available in
1321	hardware_exit_reason.
1322	
1323			/* KVM_EXIT_FAIL_ENTRY */
1324			struct {
1325				__u64 hardware_entry_failure_reason;
1326			} fail_entry;
1327	
1328	If exit_reason is KVM_EXIT_FAIL_ENTRY, the vcpu could not be run due
1329	to unknown reasons.  Further architecture-specific information is
1330	available in hardware_entry_failure_reason.
1331	
1332			/* KVM_EXIT_EXCEPTION */
1333			struct {
1334				__u32 exception;
1335				__u32 error_code;
1336			} ex;
1337	
1338	Unused.
1339	
1340			/* KVM_EXIT_IO */
1341			struct {
1342	#define KVM_EXIT_IO_IN  0
1343	#define KVM_EXIT_IO_OUT 1
1344				__u8 direction;
1345				__u8 size; /* bytes */
1346				__u16 port;
1347				__u32 count;
1348				__u64 data_offset; /* relative to kvm_run start */
1349			} io;
1350	
1351	If exit_reason is KVM_EXIT_IO, then the vcpu has
1352	executed a port I/O instruction which could not be satisfied by kvm.
1353	data_offset describes where the data is located (KVM_EXIT_IO_OUT) or
1354	where kvm expects application code to place the data for the next
1355	KVM_RUN invocation (KVM_EXIT_IO_IN).  Data format is a packed array.
1356	
1357			struct {
1358				struct kvm_debug_exit_arch arch;
1359			} debug;
1360	
1361	Unused.
1362	
1363			/* KVM_EXIT_MMIO */
1364			struct {
1365				__u64 phys_addr;
1366				__u8  data[8];
1367				__u32 len;
1368				__u8  is_write;
1369			} mmio;
1370	
1371	If exit_reason is KVM_EXIT_MMIO, then the vcpu has
1372	executed a memory-mapped I/O instruction which could not be satisfied
1373	by kvm.  The 'data' member contains the written data if 'is_write' is
1374	true, and should be filled by application code otherwise.
1375	
1376	NOTE: For KVM_EXIT_IO, KVM_EXIT_MMIO and KVM_EXIT_OSI, the corresponding
1377	operations are complete (and guest state is consistent) only after userspace
1378	has re-entered the kernel with KVM_RUN.  The kernel side will first finish
1379	incomplete operations and then check for pending signals.  Userspace
1380	can re-enter the guest with an unmasked signal pending to complete
1381	pending operations.
1382	
1383			/* KVM_EXIT_HYPERCALL */
1384			struct {
1385				__u64 nr;
1386				__u64 args[6];
1387				__u64 ret;
1388				__u32 longmode;
1389				__u32 pad;
1390			} hypercall;
1391	
1392	Unused.  This was once used for 'hypercall to userspace'.  To implement
1393	such functionality, use KVM_EXIT_IO (x86) or KVM_EXIT_MMIO (all except s390).
1394	Note KVM_EXIT_IO is significantly faster than KVM_EXIT_MMIO.
1395	
1396			/* KVM_EXIT_TPR_ACCESS */
1397			struct {
1398				__u64 rip;
1399				__u32 is_write;
1400				__u32 pad;
1401			} tpr_access;
1402	
1403	To be documented (KVM_TPR_ACCESS_REPORTING).
1404	
1405			/* KVM_EXIT_S390_SIEIC */
1406			struct {
1407				__u8 icptcode;
1408				__u64 mask; /* psw upper half */
1409				__u64 addr; /* psw lower half */
1410				__u16 ipa;
1411				__u32 ipb;
1412			} s390_sieic;
1413	
1414	s390 specific.
1415	
1416			/* KVM_EXIT_S390_RESET */
1417	#define KVM_S390_RESET_POR       1
1418	#define KVM_S390_RESET_CLEAR     2
1419	#define KVM_S390_RESET_SUBSYSTEM 4
1420	#define KVM_S390_RESET_CPU_INIT  8
1421	#define KVM_S390_RESET_IPL       16
1422			__u64 s390_reset_flags;
1423	
1424	s390 specific.
1425	
1426			/* KVM_EXIT_DCR */
1427			struct {
1428				__u32 dcrn;
1429				__u32 data;
1430				__u8  is_write;
1431			} dcr;
1432	
1433	powerpc specific.
1434	
1435			/* KVM_EXIT_OSI */
1436			struct {
1437				__u64 gprs[32];
1438			} osi;
1439	
1440	MOL uses a special hypercall interface it calls 'OSI'. To enable it, we catch
1441	hypercalls and exit with this exit struct that contains all the guest gprs.
1442	
1443	If exit_reason is KVM_EXIT_OSI, then the vcpu has triggered such a hypercall.
1444	Userspace can now handle the hypercall and when it's done modify the gprs as
1445	necessary. Upon guest entry all guest GPRs will then be replaced by the values
1446	in this struct.
1447	
1448			/* Fix the size of the union. */
1449			char padding[256];
1450		};
1451	};
Hide Line Numbers


About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog