Merge branch 'gart/rename' of git://git.kernel.org/pub/scm/linux/kernel/git/joro...
[linux-2.6.git] / Documentation / kvm / api.txt
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 };