Blame view

kernel/linux-imx6_3.14.28/Documentation/virtual/kvm/api.txt 87.9 KB
6b13f685e   김민수   BSP 최초 추가
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
2692
2693
2694
2695
2696
2697
2698
2699
2700
2701
2702
2703
2704
2705
2706
2707
2708
2709
2710
2711
2712
2713
2714
2715
2716
2717
2718
2719
2720
2721
2722
2723
2724
2725
2726
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746
2747
2748
2749
2750
2751
2752
2753
2754
2755
2756
2757
2758
2759
2760
2761
2762
2763
2764
2765
2766
2767
2768
2769
2770
2771
2772
2773
2774
2775
2776
2777
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800
2801
2802
2803
2804
2805
2806
2807
2808
2809
2810
2811
2812
2813
2814
2815
2816
2817
2818
2819
2820
2821
2822
2823
2824
2825
2826
2827
2828
2829
2830
2831
2832
2833
2834
2835
2836
2837
2838
2839
2840
2841
2842
2843
2844
2845
2846
2847
2848
2849
2850
2851
2852
2853
2854
2855
2856
2857
2858
2859
2860
2861
2862
2863
2864
2865
2866
2867
2868
2869
2870
2871
2872
2873
2874
2875
2876
2877
2878
2879
2880
2881
2882
2883
2884
2885
2886
2887
2888
2889
2890
2891
2892
2893
2894
2895
2896
2897
2898
2899
2900
2901
2902
2903
2904
2905
2906
2907
2908
2909
2910
2911
2912
2913
2914
2915
2916
2917
2918
2919
2920
2921
2922
2923
2924
2925
2926
2927
2928
2929
2930
2931
2932
2933
2934
2935
2936
2937
2938
2939
2940
2941
2942
2943
2944
2945
2946
  The Definitive KVM (Kernel-based Virtual Machine) API Documentation
  ===================================================================
  
  1. General description
  ----------------------
  
  The kvm API is a set of ioctls that are issued to control various aspects
  of a virtual machine.  The ioctls belong to three classes
  
   - System ioctls: These query and set global attributes which affect the
     whole kvm subsystem.  In addition a system ioctl is used to create
     virtual machines
  
   - VM ioctls: These query and set attributes that affect an entire virtual
     machine, for example memory layout.  In addition a VM ioctl is used to
     create virtual cpus (vcpus).
  
     Only run VM ioctls from the same process (address space) that was used
     to create the VM.
  
   - vcpu ioctls: These query and set attributes that control the operation
     of a single virtual cpu.
  
     Only run vcpu ioctls from the same thread that was used to create the
     vcpu.
  
  
  2. File descriptors
  -------------------
  
  The kvm API is centered around file descriptors.  An initial
  open("/dev/kvm") obtains a handle to the kvm subsystem; this handle
  can be used to issue system ioctls.  A KVM_CREATE_VM ioctl on this
  handle will create a VM file descriptor which can be used to issue VM
  ioctls.  A KVM_CREATE_VCPU ioctl on a VM fd will create a virtual cpu
  and return a file descriptor pointing to it.  Finally, ioctls on a vcpu
  fd can be used to control the vcpu, including the important task of
  actually running guest code.
  
  In general file descriptors can be migrated among processes by means
  of fork() and the SCM_RIGHTS facility of unix domain socket.  These
  kinds of tricks are explicitly not supported by kvm.  While they will
  not cause harm to the host, their actual behavior is not guaranteed by
  the API.  The only supported use is one virtual machine per process,
  and one vcpu per thread.
  
  
  3. Extensions
  -------------
  
  As of Linux 2.6.22, the KVM ABI has been stabilized: no backward
  incompatible change are allowed.  However, there is an extension
  facility that allows backward-compatible extensions to the API to be
  queried and used.
  
  The extension mechanism is not based on the Linux version number.
  Instead, kvm defines extension identifiers and a facility to query
  whether a particular extension identifier is available.  If it is, a
  set of ioctls is available for application use.
  
  
  4. API description
  ------------------
  
  This section describes ioctls that can be used to control kvm guests.
  For each ioctl, the following information is provided along with a
  description:
  
    Capability: which KVM extension provides this ioctl.  Can be 'basic',
        which means that is will be provided by any kernel that supports
        API version 12 (see section 4.1), or a KVM_CAP_xyz constant, which
        means availability needs to be checked with KVM_CHECK_EXTENSION
        (see section 4.4).
  
    Architectures: which instruction set architectures provide this ioctl.
        x86 includes both i386 and x86_64.
  
    Type: system, vm, or vcpu.
  
    Parameters: what parameters are accepted by the ioctl.
  
    Returns: the return value.  General error numbers (EBADF, ENOMEM, EINVAL)
        are not detailed, but errors with specific meanings are.
  
  
  4.1 KVM_GET_API_VERSION
  
  Capability: basic
  Architectures: all
  Type: system ioctl
  Parameters: none
  Returns: the constant KVM_API_VERSION (=12)
  
  This identifies the API version as the stable kvm API. It is not
  expected that this number will change.  However, Linux 2.6.20 and
  2.6.21 report earlier versions; these are not documented and not
  supported.  Applications should refuse to run if KVM_GET_API_VERSION
  returns a value other than 12.  If this check passes, all ioctls
  described as 'basic' will be available.
  
  
  4.2 KVM_CREATE_VM
  
  Capability: basic
  Architectures: all
  Type: system ioctl
  Parameters: machine type identifier (KVM_VM_*)
  Returns: a VM fd that can be used to control the new virtual machine.
  
  The new VM has no virtual cpus and no memory.  An mmap() of a VM fd
  will access the virtual machine's physical address space; offset zero
  corresponds to guest physical address zero.  Use of mmap() on a VM fd
  is discouraged if userspace memory allocation (KVM_CAP_USER_MEMORY) is
  available.
  You most certainly want to use 0 as machine type.
  
  In order to create user controlled virtual machines on S390, check
  KVM_CAP_S390_UCONTROL and use the flag KVM_VM_S390_UCONTROL as
  privileged user (CAP_SYS_ADMIN).
  
  
  4.3 KVM_GET_MSR_INDEX_LIST
  
  Capability: basic
  Architectures: x86
  Type: system
  Parameters: struct kvm_msr_list (in/out)
  Returns: 0 on success; -1 on error
  Errors:
    E2BIG:     the msr index list is to be to fit in the array specified by
               the user.
  
  struct kvm_msr_list {
  	__u32 nmsrs; /* number of msrs in entries */
  	__u32 indices[0];
  };
  
  This ioctl returns the guest msrs that are supported.  The list varies
  by kvm version and host processor, but does not change otherwise.  The
  user fills in the size of the indices array in nmsrs, and in return
  kvm adjusts nmsrs to reflect the actual number of msrs and fills in
  the indices array with their numbers.
  
  Note: if kvm indicates supports MCE (KVM_CAP_MCE), then the MCE bank MSRs are
  not returned in the MSR list, as different vcpus can have a different number
  of banks, as set via the KVM_X86_SETUP_MCE ioctl.
  
  
  4.4 KVM_CHECK_EXTENSION
  
  Capability: basic
  Architectures: all
  Type: system ioctl
  Parameters: extension identifier (KVM_CAP_*)
  Returns: 0 if unsupported; 1 (or some other positive integer) if supported
  
  The API allows the application to query about extensions to the core
  kvm API.  Userspace passes an extension identifier (an integer) and
  receives an integer that describes the extension availability.
  Generally 0 means no and 1 means yes, but some extensions may report
  additional information in the integer return value.
  
  
  4.5 KVM_GET_VCPU_MMAP_SIZE
  
  Capability: basic
  Architectures: all
  Type: system ioctl
  Parameters: none
  Returns: size of vcpu mmap area, in bytes
  
  The KVM_RUN ioctl (cf.) communicates with userspace via a shared
  memory region.  This ioctl returns the size of that region.  See the
  KVM_RUN documentation for details.
  
  
  4.6 KVM_SET_MEMORY_REGION
  
  Capability: basic
  Architectures: all
  Type: vm ioctl
  Parameters: struct kvm_memory_region (in)
  Returns: 0 on success, -1 on error
  
  This ioctl is obsolete and has been removed.
  
  
  4.7 KVM_CREATE_VCPU
  
  Capability: basic
  Architectures: all
  Type: vm ioctl
  Parameters: vcpu id (apic id on x86)
  Returns: vcpu fd on success, -1 on error
  
  This API adds a vcpu to a virtual machine.  The vcpu id is a small integer
  in the range [0, max_vcpus).
  
  The recommended max_vcpus value can be retrieved using the KVM_CAP_NR_VCPUS of
  the KVM_CHECK_EXTENSION ioctl() at run-time.
  The maximum possible value for max_vcpus can be retrieved using the
  KVM_CAP_MAX_VCPUS of the KVM_CHECK_EXTENSION ioctl() at run-time.
  
  If the KVM_CAP_NR_VCPUS does not exist, you should assume that max_vcpus is 4
  cpus max.
  If the KVM_CAP_MAX_VCPUS does not exist, you should assume that max_vcpus is
  same as the value returned from KVM_CAP_NR_VCPUS.
  
  On powerpc using book3s_hv mode, the vcpus are mapped onto virtual
  threads in one or more virtual CPU cores.  (This is because the
  hardware requires all the hardware threads in a CPU core to be in the
  same partition.)  The KVM_CAP_PPC_SMT capability indicates the number
  of vcpus per virtual core (vcore).  The vcore id is obtained by
  dividing the vcpu id by the number of vcpus per vcore.  The vcpus in a
  given vcore will always be in the same physical core as each other
  (though that might be a different physical core from time to time).
  Userspace can control the threading (SMT) mode of the guest by its
  allocation of vcpu ids.  For example, if userspace wants
  single-threaded guest vcpus, it should make all vcpu ids be a multiple
  of the number of vcpus per vcore.
  
  For virtual cpus that have been created with S390 user controlled virtual
  machines, the resulting vcpu fd can be memory mapped at page offset
  KVM_S390_SIE_PAGE_OFFSET in order to obtain a memory map of the virtual
  cpu's hardware control block.
  
  
  4.8 KVM_GET_DIRTY_LOG (vm ioctl)
  
  Capability: basic
  Architectures: x86
  Type: vm ioctl
  Parameters: struct kvm_dirty_log (in/out)
  Returns: 0 on success, -1 on error
  
  /* for KVM_GET_DIRTY_LOG */
  struct kvm_dirty_log {
  	__u32 slot;
  	__u32 padding;
  	union {
  		void __user *dirty_bitmap; /* one bit per page */
  		__u64 padding;
  	};
  };
  
  Given a memory slot, return a bitmap containing any pages dirtied
  since the last call to this ioctl.  Bit 0 is the first page in the
  memory slot.  Ensure the entire structure is cleared to avoid padding
  issues.
  
  
  4.9 KVM_SET_MEMORY_ALIAS
  
  Capability: basic
  Architectures: x86
  Type: vm ioctl
  Parameters: struct kvm_memory_alias (in)
  Returns: 0 (success), -1 (error)
  
  This ioctl is obsolete and has been removed.
  
  
  4.10 KVM_RUN
  
  Capability: basic
  Architectures: all
  Type: vcpu ioctl
  Parameters: none
  Returns: 0 on success, -1 on error
  Errors:
    EINTR:     an unmasked signal is pending
  
  This ioctl is used to run a guest virtual cpu.  While there are no
  explicit parameters, there is an implicit parameter block that can be
  obtained by mmap()ing the vcpu fd at offset 0, with the size given by
  KVM_GET_VCPU_MMAP_SIZE.  The parameter block is formatted as a 'struct
  kvm_run' (see below).
  
  
  4.11 KVM_GET_REGS
  
  Capability: basic
  Architectures: all except ARM, arm64
  Type: vcpu ioctl
  Parameters: struct kvm_regs (out)
  Returns: 0 on success, -1 on error
  
  Reads the general purpose registers from the vcpu.
  
  /* x86 */
  struct kvm_regs {
  	/* out (KVM_GET_REGS) / in (KVM_SET_REGS) */
  	__u64 rax, rbx, rcx, rdx;
  	__u64 rsi, rdi, rsp, rbp;
  	__u64 r8,  r9,  r10, r11;
  	__u64 r12, r13, r14, r15;
  	__u64 rip, rflags;
  };
  
  
  4.12 KVM_SET_REGS
  
  Capability: basic
  Architectures: all except ARM, arm64
  Type: vcpu ioctl
  Parameters: struct kvm_regs (in)
  Returns: 0 on success, -1 on error
  
  Writes the general purpose registers into the vcpu.
  
  See KVM_GET_REGS for the data structure.
  
  
  4.13 KVM_GET_SREGS
  
  Capability: basic
  Architectures: x86, ppc
  Type: vcpu ioctl
  Parameters: struct kvm_sregs (out)
  Returns: 0 on success, -1 on error
  
  Reads special registers from the vcpu.
  
  /* x86 */
  struct kvm_sregs {
  	struct kvm_segment cs, ds, es, fs, gs, ss;
  	struct kvm_segment tr, ldt;
  	struct kvm_dtable gdt, idt;
  	__u64 cr0, cr2, cr3, cr4, cr8;
  	__u64 efer;
  	__u64 apic_base;
  	__u64 interrupt_bitmap[(KVM_NR_INTERRUPTS + 63) / 64];
  };
  
  /* ppc -- see arch/powerpc/include/uapi/asm/kvm.h */
  
  interrupt_bitmap is a bitmap of pending external interrupts.  At most
  one bit may be set.  This interrupt has been acknowledged by the APIC
  but not yet injected into the cpu core.
  
  
  4.14 KVM_SET_SREGS
  
  Capability: basic
  Architectures: x86, ppc
  Type: vcpu ioctl
  Parameters: struct kvm_sregs (in)
  Returns: 0 on success, -1 on error
  
  Writes special registers into the vcpu.  See KVM_GET_SREGS for the
  data structures.
  
  
  4.15 KVM_TRANSLATE
  
  Capability: basic
  Architectures: x86
  Type: vcpu ioctl
  Parameters: struct kvm_translation (in/out)
  Returns: 0 on success, -1 on error
  
  Translates a virtual address according to the vcpu's current address
  translation mode.
  
  struct kvm_translation {
  	/* in */
  	__u64 linear_address;
  
  	/* out */
  	__u64 physical_address;
  	__u8  valid;
  	__u8  writeable;
  	__u8  usermode;
  	__u8  pad[5];
  };
  
  
  4.16 KVM_INTERRUPT
  
  Capability: basic
  Architectures: x86, ppc
  Type: vcpu ioctl
  Parameters: struct kvm_interrupt (in)
  Returns: 0 on success, -1 on error
  
  Queues a hardware interrupt vector to be injected.  This is only
  useful if in-kernel local APIC or equivalent is not used.
  
  /* for KVM_INTERRUPT */
  struct kvm_interrupt {
  	/* in */
  	__u32 irq;
  };
  
  X86:
  
  Note 'irq' is an interrupt vector, not an interrupt pin or line.
  
  PPC:
  
  Queues an external interrupt to be injected. This ioctl is overleaded
  with 3 different irq values:
  
  a) KVM_INTERRUPT_SET
  
    This injects an edge type external interrupt into the guest once it's ready
    to receive interrupts. When injected, the interrupt is done.
  
  b) KVM_INTERRUPT_UNSET
  
    This unsets any pending interrupt.
  
    Only available with KVM_CAP_PPC_UNSET_IRQ.
  
  c) KVM_INTERRUPT_SET_LEVEL
  
    This injects a level type external interrupt into the guest context. The
    interrupt stays pending until a specific ioctl with KVM_INTERRUPT_UNSET
    is triggered.
  
    Only available with KVM_CAP_PPC_IRQ_LEVEL.
  
  Note that any value for 'irq' other than the ones stated above is invalid
  and incurs unexpected behavior.
  
  
  4.17 KVM_DEBUG_GUEST
  
  Capability: basic
  Architectures: none
  Type: vcpu ioctl
  Parameters: none)
  Returns: -1 on error
  
  Support for this has been removed.  Use KVM_SET_GUEST_DEBUG instead.
  
  
  4.18 KVM_GET_MSRS
  
  Capability: basic
  Architectures: x86
  Type: vcpu ioctl
  Parameters: struct kvm_msrs (in/out)
  Returns: 0 on success, -1 on error
  
  Reads model-specific registers from the vcpu.  Supported msr indices can
  be obtained using KVM_GET_MSR_INDEX_LIST.
  
  struct kvm_msrs {
  	__u32 nmsrs; /* number of msrs in entries */
  	__u32 pad;
  
  	struct kvm_msr_entry entries[0];
  };
  
  struct kvm_msr_entry {
  	__u32 index;
  	__u32 reserved;
  	__u64 data;
  };
  
  Application code should set the 'nmsrs' member (which indicates the
  size of the entries array) and the 'index' member of each array entry.
  kvm will fill in the 'data' member.
  
  
  4.19 KVM_SET_MSRS
  
  Capability: basic
  Architectures: x86
  Type: vcpu ioctl
  Parameters: struct kvm_msrs (in)
  Returns: 0 on success, -1 on error
  
  Writes model-specific registers to the vcpu.  See KVM_GET_MSRS for the
  data structures.
  
  Application code should set the 'nmsrs' member (which indicates the
  size of the entries array), and the 'index' and 'data' members of each
  array entry.
  
  
  4.20 KVM_SET_CPUID
  
  Capability: basic
  Architectures: x86
  Type: vcpu ioctl
  Parameters: struct kvm_cpuid (in)
  Returns: 0 on success, -1 on error
  
  Defines the vcpu responses to the cpuid instruction.  Applications
  should use the KVM_SET_CPUID2 ioctl if available.
  
  
  struct kvm_cpuid_entry {
  	__u32 function;
  	__u32 eax;
  	__u32 ebx;
  	__u32 ecx;
  	__u32 edx;
  	__u32 padding;
  };
  
  /* for KVM_SET_CPUID */
  struct kvm_cpuid {
  	__u32 nent;
  	__u32 padding;
  	struct kvm_cpuid_entry entries[0];
  };
  
  
  4.21 KVM_SET_SIGNAL_MASK
  
  Capability: basic
  Architectures: x86
  Type: vcpu ioctl
  Parameters: struct kvm_signal_mask (in)
  Returns: 0 on success, -1 on error
  
  Defines which signals are blocked during execution of KVM_RUN.  This
  signal mask temporarily overrides the threads signal mask.  Any
  unblocked signal received (except SIGKILL and SIGSTOP, which retain
  their traditional behaviour) will cause KVM_RUN to return with -EINTR.
  
  Note the signal will only be delivered if not blocked by the original
  signal mask.
  
  /* for KVM_SET_SIGNAL_MASK */
  struct kvm_signal_mask {
  	__u32 len;
  	__u8  sigset[0];
  };
  
  
  4.22 KVM_GET_FPU
  
  Capability: basic
  Architectures: x86
  Type: vcpu ioctl
  Parameters: struct kvm_fpu (out)
  Returns: 0 on success, -1 on error
  
  Reads the floating point state from the vcpu.
  
  /* for KVM_GET_FPU and KVM_SET_FPU */
  struct kvm_fpu {
  	__u8  fpr[8][16];
  	__u16 fcw;
  	__u16 fsw;
  	__u8  ftwx;  /* in fxsave format */
  	__u8  pad1;
  	__u16 last_opcode;
  	__u64 last_ip;
  	__u64 last_dp;
  	__u8  xmm[16][16];
  	__u32 mxcsr;
  	__u32 pad2;
  };
  
  
  4.23 KVM_SET_FPU
  
  Capability: basic
  Architectures: x86
  Type: vcpu ioctl
  Parameters: struct kvm_fpu (in)
  Returns: 0 on success, -1 on error
  
  Writes the floating point state to the vcpu.
  
  /* for KVM_GET_FPU and KVM_SET_FPU */
  struct kvm_fpu {
  	__u8  fpr[8][16];
  	__u16 fcw;
  	__u16 fsw;
  	__u8  ftwx;  /* in fxsave format */
  	__u8  pad1;
  	__u16 last_opcode;
  	__u64 last_ip;
  	__u64 last_dp;
  	__u8  xmm[16][16];
  	__u32 mxcsr;
  	__u32 pad2;
  };
  
  
  4.24 KVM_CREATE_IRQCHIP
  
  Capability: KVM_CAP_IRQCHIP
  Architectures: x86, ia64, ARM, arm64
  Type: vm ioctl
  Parameters: none
  Returns: 0 on success, -1 on error
  
  Creates an interrupt controller model in the kernel.  On x86, creates a virtual
  ioapic, a virtual PIC (two PICs, nested), and sets up future vcpus to have a
  local APIC.  IRQ routing for GSIs 0-15 is set to both PIC and IOAPIC; GSI 16-23
  only go to the IOAPIC.  On ia64, a IOSAPIC is created. On ARM/arm64, a GIC is
  created.
  
  
  4.25 KVM_IRQ_LINE
  
  Capability: KVM_CAP_IRQCHIP
  Architectures: x86, ia64, arm, arm64
  Type: vm ioctl
  Parameters: struct kvm_irq_level
  Returns: 0 on success, -1 on error
  
  Sets the level of a GSI input to the interrupt controller model in the kernel.
  On some architectures it is required that an interrupt controller model has
  been previously created with KVM_CREATE_IRQCHIP.  Note that edge-triggered
  interrupts require the level to be set to 1 and then back to 0.
  
  ARM/arm64 can signal an interrupt either at the CPU level, or at the
  in-kernel irqchip (GIC), and for in-kernel irqchip can tell the GIC to
  use PPIs designated for specific cpus.  The irq field is interpreted
  like this:
  
    bits:  | 31 ... 24 | 23  ... 16 | 15    ...    0 |
    field: | irq_type  | vcpu_index |     irq_id     |
  
  The irq_type field has the following values:
  - irq_type[0]: out-of-kernel GIC: irq_id 0 is IRQ, irq_id 1 is FIQ
  - irq_type[1]: in-kernel GIC: SPI, irq_id between 32 and 1019 (incl.)
                 (the vcpu_index field is ignored)
  - irq_type[2]: in-kernel GIC: PPI, irq_id between 16 and 31 (incl.)
  
  (The irq_id field thus corresponds nicely to the IRQ ID in the ARM GIC specs)
  
  In both cases, level is used to raise/lower the line.
  
  struct kvm_irq_level {
  	union {
  		__u32 irq;     /* GSI */
  		__s32 status;  /* not used for KVM_IRQ_LEVEL */
  	};
  	__u32 level;           /* 0 or 1 */
  };
  
  
  4.26 KVM_GET_IRQCHIP
  
  Capability: KVM_CAP_IRQCHIP
  Architectures: x86, ia64
  Type: vm ioctl
  Parameters: struct kvm_irqchip (in/out)
  Returns: 0 on success, -1 on error
  
  Reads the state of a kernel interrupt controller created with
  KVM_CREATE_IRQCHIP into a buffer provided by the caller.
  
  struct kvm_irqchip {
  	__u32 chip_id;  /* 0 = PIC1, 1 = PIC2, 2 = IOAPIC */
  	__u32 pad;
          union {
  		char dummy[512];  /* reserving space */
  		struct kvm_pic_state pic;
  		struct kvm_ioapic_state ioapic;
  	} chip;
  };
  
  
  4.27 KVM_SET_IRQCHIP
  
  Capability: KVM_CAP_IRQCHIP
  Architectures: x86, ia64
  Type: vm ioctl
  Parameters: struct kvm_irqchip (in)
  Returns: 0 on success, -1 on error
  
  Sets the state of a kernel interrupt controller created with
  KVM_CREATE_IRQCHIP from a buffer provided by the caller.
  
  struct kvm_irqchip {
  	__u32 chip_id;  /* 0 = PIC1, 1 = PIC2, 2 = IOAPIC */
  	__u32 pad;
          union {
  		char dummy[512];  /* reserving space */
  		struct kvm_pic_state pic;
  		struct kvm_ioapic_state ioapic;
  	} chip;
  };
  
  
  4.28 KVM_XEN_HVM_CONFIG
  
  Capability: KVM_CAP_XEN_HVM
  Architectures: x86
  Type: vm ioctl
  Parameters: struct kvm_xen_hvm_config (in)
  Returns: 0 on success, -1 on error
  
  Sets the MSR that the Xen HVM guest uses to initialize its hypercall
  page, and provides the starting address and size of the hypercall
  blobs in userspace.  When the guest writes the MSR, kvm copies one
  page of a blob (32- or 64-bit, depending on the vcpu mode) to guest
  memory.
  
  struct kvm_xen_hvm_config {
  	__u32 flags;
  	__u32 msr;
  	__u64 blob_addr_32;
  	__u64 blob_addr_64;
  	__u8 blob_size_32;
  	__u8 blob_size_64;
  	__u8 pad2[30];
  };
  
  
  4.29 KVM_GET_CLOCK
  
  Capability: KVM_CAP_ADJUST_CLOCK
  Architectures: x86
  Type: vm ioctl
  Parameters: struct kvm_clock_data (out)
  Returns: 0 on success, -1 on error
  
  Gets the current timestamp of kvmclock as seen by the current guest. In
  conjunction with KVM_SET_CLOCK, it is used to ensure monotonicity on scenarios
  such as migration.
  
  struct kvm_clock_data {
  	__u64 clock;  /* kvmclock current value */
  	__u32 flags;
  	__u32 pad[9];
  };
  
  
  4.30 KVM_SET_CLOCK
  
  Capability: KVM_CAP_ADJUST_CLOCK
  Architectures: x86
  Type: vm ioctl
  Parameters: struct kvm_clock_data (in)
  Returns: 0 on success, -1 on error
  
  Sets the current timestamp of kvmclock to the value specified in its parameter.
  In conjunction with KVM_GET_CLOCK, it is used to ensure monotonicity on scenarios
  such as migration.
  
  struct kvm_clock_data {
  	__u64 clock;  /* kvmclock current value */
  	__u32 flags;
  	__u32 pad[9];
  };
  
  
  4.31 KVM_GET_VCPU_EVENTS
  
  Capability: KVM_CAP_VCPU_EVENTS
  Extended by: KVM_CAP_INTR_SHADOW
  Architectures: x86
  Type: vm ioctl
  Parameters: struct kvm_vcpu_event (out)
  Returns: 0 on success, -1 on error
  
  Gets currently pending exceptions, interrupts, and NMIs as well as related
  states of the vcpu.
  
  struct kvm_vcpu_events {
  	struct {
  		__u8 injected;
  		__u8 nr;
  		__u8 has_error_code;
  		__u8 pad;
  		__u32 error_code;
  	} exception;
  	struct {
  		__u8 injected;
  		__u8 nr;
  		__u8 soft;
  		__u8 shadow;
  	} interrupt;
  	struct {
  		__u8 injected;
  		__u8 pending;
  		__u8 masked;
  		__u8 pad;
  	} nmi;
  	__u32 sipi_vector;
  	__u32 flags;
  };
  
  KVM_VCPUEVENT_VALID_SHADOW may be set in the flags field to signal that
  interrupt.shadow contains a valid state. Otherwise, this field is undefined.
  
  
  4.32 KVM_SET_VCPU_EVENTS
  
  Capability: KVM_CAP_VCPU_EVENTS
  Extended by: KVM_CAP_INTR_SHADOW
  Architectures: x86
  Type: vm ioctl
  Parameters: struct kvm_vcpu_event (in)
  Returns: 0 on success, -1 on error
  
  Set pending exceptions, interrupts, and NMIs as well as related states of the
  vcpu.
  
  See KVM_GET_VCPU_EVENTS for the data structure.
  
  Fields that may be modified asynchronously by running VCPUs can be excluded
  from the update. These fields are nmi.pending and sipi_vector. Keep the
  corresponding bits in the flags field cleared to suppress overwriting the
  current in-kernel state. The bits are:
  
  KVM_VCPUEVENT_VALID_NMI_PENDING - transfer nmi.pending to the kernel
  KVM_VCPUEVENT_VALID_SIPI_VECTOR - transfer sipi_vector
  
  If KVM_CAP_INTR_SHADOW is available, KVM_VCPUEVENT_VALID_SHADOW can be set in
  the flags field to signal that interrupt.shadow contains a valid state and
  shall be written into the VCPU.
  
  
  4.33 KVM_GET_DEBUGREGS
  
  Capability: KVM_CAP_DEBUGREGS
  Architectures: x86
  Type: vm ioctl
  Parameters: struct kvm_debugregs (out)
  Returns: 0 on success, -1 on error
  
  Reads debug registers from the vcpu.
  
  struct kvm_debugregs {
  	__u64 db[4];
  	__u64 dr6;
  	__u64 dr7;
  	__u64 flags;
  	__u64 reserved[9];
  };
  
  
  4.34 KVM_SET_DEBUGREGS
  
  Capability: KVM_CAP_DEBUGREGS
  Architectures: x86
  Type: vm ioctl
  Parameters: struct kvm_debugregs (in)
  Returns: 0 on success, -1 on error
  
  Writes debug registers into the vcpu.
  
  See KVM_GET_DEBUGREGS for the data structure. The flags field is unused
  yet and must be cleared on entry.
  
  
  4.35 KVM_SET_USER_MEMORY_REGION
  
  Capability: KVM_CAP_USER_MEM
  Architectures: all
  Type: vm ioctl
  Parameters: struct kvm_userspace_memory_region (in)
  Returns: 0 on success, -1 on error
  
  struct kvm_userspace_memory_region {
  	__u32 slot;
  	__u32 flags;
  	__u64 guest_phys_addr;
  	__u64 memory_size; /* bytes */
  	__u64 userspace_addr; /* start of the userspace allocated memory */
  };
  
  /* for kvm_memory_region::flags */
  #define KVM_MEM_LOG_DIRTY_PAGES	(1UL << 0)
  #define KVM_MEM_READONLY	(1UL << 1)
  
  This ioctl allows the user to create or modify a guest physical memory
  slot.  When changing an existing slot, it may be moved in the guest
  physical memory space, or its flags may be modified.  It may not be
  resized.  Slots may not overlap in guest physical address space.
  
  Memory for the region is taken starting at the address denoted by the
  field userspace_addr, which must point at user addressable memory for
  the entire memory slot size.  Any object may back this memory, including
  anonymous memory, ordinary files, and hugetlbfs.
  
  It is recommended that the lower 21 bits of guest_phys_addr and userspace_addr
  be identical.  This allows large pages in the guest to be backed by large
  pages in the host.
  
  The flags field supports two flags: KVM_MEM_LOG_DIRTY_PAGES and
  KVM_MEM_READONLY.  The former can be set to instruct KVM to keep track of
  writes to memory within the slot.  See KVM_GET_DIRTY_LOG ioctl to know how to
  use it.  The latter can be set, if KVM_CAP_READONLY_MEM capability allows it,
  to make a new slot read-only.  In this case, writes to this memory will be
  posted to userspace as KVM_EXIT_MMIO exits.
  
  When the KVM_CAP_SYNC_MMU capability is available, changes in the backing of
  the memory region are automatically reflected into the guest.  For example, an
  mmap() that affects the region will be made visible immediately.  Another
  example is madvise(MADV_DROP).
  
  It is recommended to use this API instead of the KVM_SET_MEMORY_REGION ioctl.
  The KVM_SET_MEMORY_REGION does not allow fine grained control over memory
  allocation and is deprecated.
  
  
  4.36 KVM_SET_TSS_ADDR
  
  Capability: KVM_CAP_SET_TSS_ADDR
  Architectures: x86
  Type: vm ioctl
  Parameters: unsigned long tss_address (in)
  Returns: 0 on success, -1 on error
  
  This ioctl defines the physical address of a three-page region in the guest
  physical address space.  The region must be within the first 4GB of the
  guest physical address space and must not conflict with any memory slot
  or any mmio address.  The guest may malfunction if it accesses this memory
  region.
  
  This ioctl is required on Intel-based hosts.  This is needed on Intel hardware
  because of a quirk in the virtualization implementation (see the internals
  documentation when it pops into existence).
  
  
  4.37 KVM_ENABLE_CAP
  
  Capability: KVM_CAP_ENABLE_CAP
  Architectures: ppc, s390
  Type: vcpu ioctl
  Parameters: struct kvm_enable_cap (in)
  Returns: 0 on success; -1 on error
  
  +Not all extensions are enabled by default. Using this ioctl the application
  can enable an extension, making it available to the guest.
  
  On systems that do not support this ioctl, it always fails. On systems that
  do support it, it only works for extensions that are supported for enablement.
  
  To check if a capability can be enabled, the KVM_CHECK_EXTENSION ioctl should
  be used.
  
  struct kvm_enable_cap {
         /* in */
         __u32 cap;
  
  The capability that is supposed to get enabled.
  
         __u32 flags;
  
  A bitfield indicating future enhancements. Has to be 0 for now.
  
         __u64 args[4];
  
  Arguments for enabling a feature. If a feature needs initial values to
  function properly, this is the place to put them.
  
         __u8  pad[64];
  };
  
  
  4.38 KVM_GET_MP_STATE
  
  Capability: KVM_CAP_MP_STATE
  Architectures: x86, ia64
  Type: vcpu ioctl
  Parameters: struct kvm_mp_state (out)
  Returns: 0 on success; -1 on error
  
  struct kvm_mp_state {
  	__u32 mp_state;
  };
  
  Returns the vcpu's current "multiprocessing state" (though also valid on
  uniprocessor guests).
  
  Possible values are:
  
   - KVM_MP_STATE_RUNNABLE:        the vcpu is currently running
   - KVM_MP_STATE_UNINITIALIZED:   the vcpu is an application processor (AP)
                                   which has not yet received an INIT signal
   - KVM_MP_STATE_INIT_RECEIVED:   the vcpu has received an INIT signal, and is
                                   now ready for a SIPI
   - KVM_MP_STATE_HALTED:          the vcpu has executed a HLT instruction and
                                   is waiting for an interrupt
   - KVM_MP_STATE_SIPI_RECEIVED:   the vcpu has just received a SIPI (vector
                                   accessible via KVM_GET_VCPU_EVENTS)
  
  This ioctl is only useful after KVM_CREATE_IRQCHIP.  Without an in-kernel
  irqchip, the multiprocessing state must be maintained by userspace.
  
  
  4.39 KVM_SET_MP_STATE
  
  Capability: KVM_CAP_MP_STATE
  Architectures: x86, ia64
  Type: vcpu ioctl
  Parameters: struct kvm_mp_state (in)
  Returns: 0 on success; -1 on error
  
  Sets the vcpu's current "multiprocessing state"; see KVM_GET_MP_STATE for
  arguments.
  
  This ioctl is only useful after KVM_CREATE_IRQCHIP.  Without an in-kernel
  irqchip, the multiprocessing state must be maintained by userspace.
  
  
  4.40 KVM_SET_IDENTITY_MAP_ADDR
  
  Capability: KVM_CAP_SET_IDENTITY_MAP_ADDR
  Architectures: x86
  Type: vm ioctl
  Parameters: unsigned long identity (in)
  Returns: 0 on success, -1 on error
  
  This ioctl defines the physical address of a one-page region in the guest
  physical address space.  The region must be within the first 4GB of the
  guest physical address space and must not conflict with any memory slot
  or any mmio address.  The guest may malfunction if it accesses this memory
  region.
  
  This ioctl is required on Intel-based hosts.  This is needed on Intel hardware
  because of a quirk in the virtualization implementation (see the internals
  documentation when it pops into existence).
  
  
  4.41 KVM_SET_BOOT_CPU_ID
  
  Capability: KVM_CAP_SET_BOOT_CPU_ID
  Architectures: x86, ia64
  Type: vm ioctl
  Parameters: unsigned long vcpu_id
  Returns: 0 on success, -1 on error
  
  Define which vcpu is the Bootstrap Processor (BSP).  Values are the same
  as the vcpu id in KVM_CREATE_VCPU.  If this ioctl is not called, the default
  is vcpu 0.
  
  
  4.42 KVM_GET_XSAVE
  
  Capability: KVM_CAP_XSAVE
  Architectures: x86
  Type: vcpu ioctl
  Parameters: struct kvm_xsave (out)
  Returns: 0 on success, -1 on error
  
  struct kvm_xsave {
  	__u32 region[1024];
  };
  
  This ioctl would copy current vcpu's xsave struct to the userspace.
  
  
  4.43 KVM_SET_XSAVE
  
  Capability: KVM_CAP_XSAVE
  Architectures: x86
  Type: vcpu ioctl
  Parameters: struct kvm_xsave (in)
  Returns: 0 on success, -1 on error
  
  struct kvm_xsave {
  	__u32 region[1024];
  };
  
  This ioctl would copy userspace's xsave struct to the kernel.
  
  
  4.44 KVM_GET_XCRS
  
  Capability: KVM_CAP_XCRS
  Architectures: x86
  Type: vcpu ioctl
  Parameters: struct kvm_xcrs (out)
  Returns: 0 on success, -1 on error
  
  struct kvm_xcr {
  	__u32 xcr;
  	__u32 reserved;
  	__u64 value;
  };
  
  struct kvm_xcrs {
  	__u32 nr_xcrs;
  	__u32 flags;
  	struct kvm_xcr xcrs[KVM_MAX_XCRS];
  	__u64 padding[16];
  };
  
  This ioctl would copy current vcpu's xcrs to the userspace.
  
  
  4.45 KVM_SET_XCRS
  
  Capability: KVM_CAP_XCRS
  Architectures: x86
  Type: vcpu ioctl
  Parameters: struct kvm_xcrs (in)
  Returns: 0 on success, -1 on error
  
  struct kvm_xcr {
  	__u32 xcr;
  	__u32 reserved;
  	__u64 value;
  };
  
  struct kvm_xcrs {
  	__u32 nr_xcrs;
  	__u32 flags;
  	struct kvm_xcr xcrs[KVM_MAX_XCRS];
  	__u64 padding[16];
  };
  
  This ioctl would set vcpu's xcr to the value userspace specified.
  
  
  4.46 KVM_GET_SUPPORTED_CPUID
  
  Capability: KVM_CAP_EXT_CPUID
  Architectures: x86
  Type: system ioctl
  Parameters: struct kvm_cpuid2 (in/out)
  Returns: 0 on success, -1 on error
  
  struct kvm_cpuid2 {
  	__u32 nent;
  	__u32 padding;
  	struct kvm_cpuid_entry2 entries[0];
  };
  
  #define KVM_CPUID_FLAG_SIGNIFCANT_INDEX		BIT(0)
  #define KVM_CPUID_FLAG_STATEFUL_FUNC		BIT(1)
  #define KVM_CPUID_FLAG_STATE_READ_NEXT		BIT(2)
  
  struct kvm_cpuid_entry2 {
  	__u32 function;
  	__u32 index;
  	__u32 flags;
  	__u32 eax;
  	__u32 ebx;
  	__u32 ecx;
  	__u32 edx;
  	__u32 padding[3];
  };
  
  This ioctl returns x86 cpuid features which are supported by both the hardware
  and kvm.  Userspace can use the information returned by this ioctl to
  construct cpuid information (for KVM_SET_CPUID2) that is consistent with
  hardware, kernel, and userspace capabilities, and with user requirements (for
  example, the user may wish to constrain cpuid to emulate older hardware,
  or for feature consistency across a cluster).
  
  Userspace invokes KVM_GET_SUPPORTED_CPUID by passing a kvm_cpuid2 structure
  with the 'nent' field indicating the number of entries in the variable-size
  array 'entries'.  If the number of entries is too low to describe the cpu
  capabilities, an error (E2BIG) is returned.  If the number is too high,
  the 'nent' field is adjusted and an error (ENOMEM) is returned.  If the
  number is just right, the 'nent' field is adjusted to the number of valid
  entries in the 'entries' array, which is then filled.
  
  The entries returned are the host cpuid as returned by the cpuid instruction,
  with unknown or unsupported features masked out.  Some features (for example,
  x2apic), may not be present in the host cpu, but are exposed by kvm if it can
  emulate them efficiently. The fields in each entry are defined as follows:
  
    function: the eax value used to obtain the entry
    index: the ecx value used to obtain the entry (for entries that are
           affected by ecx)
    flags: an OR of zero or more of the following:
          KVM_CPUID_FLAG_SIGNIFCANT_INDEX:
             if the index field is valid
          KVM_CPUID_FLAG_STATEFUL_FUNC:
             if cpuid for this function returns different values for successive
             invocations; there will be several entries with the same function,
             all with this flag set
          KVM_CPUID_FLAG_STATE_READ_NEXT:
             for KVM_CPUID_FLAG_STATEFUL_FUNC entries, set if this entry is
             the first entry to be read by a cpu
     eax, ebx, ecx, edx: the values returned by the cpuid instruction for
           this function/index combination
  
  The TSC deadline timer feature (CPUID leaf 1, ecx[24]) is always returned
  as false, since the feature depends on KVM_CREATE_IRQCHIP for local APIC
  support.  Instead it is reported via
  
    ioctl(KVM_CHECK_EXTENSION, KVM_CAP_TSC_DEADLINE_TIMER)
  
  if that returns true and you use KVM_CREATE_IRQCHIP, or if you emulate the
  feature in userspace, then you can enable the feature for KVM_SET_CPUID2.
  
  
  4.47 KVM_PPC_GET_PVINFO
  
  Capability: KVM_CAP_PPC_GET_PVINFO
  Architectures: ppc
  Type: vm ioctl
  Parameters: struct kvm_ppc_pvinfo (out)
  Returns: 0 on success, !0 on error
  
  struct kvm_ppc_pvinfo {
  	__u32 flags;
  	__u32 hcall[4];
  	__u8  pad[108];
  };
  
  This ioctl fetches PV specific information that need to be passed to the guest
  using the device tree or other means from vm context.
  
  The hcall array defines 4 instructions that make up a hypercall.
  
  If any additional field gets added to this structure later on, a bit for that
  additional piece of information will be set in the flags bitmap.
  
  The flags bitmap is defined as:
  
     /* the host supports the ePAPR idle hcall
     #define KVM_PPC_PVINFO_FLAGS_EV_IDLE   (1<<0)
  
  4.48 KVM_ASSIGN_PCI_DEVICE
  
  Capability: KVM_CAP_DEVICE_ASSIGNMENT
  Architectures: x86 ia64
  Type: vm ioctl
  Parameters: struct kvm_assigned_pci_dev (in)
  Returns: 0 on success, -1 on error
  
  Assigns a host PCI device to the VM.
  
  struct kvm_assigned_pci_dev {
  	__u32 assigned_dev_id;
  	__u32 busnr;
  	__u32 devfn;
  	__u32 flags;
  	__u32 segnr;
  	union {
  		__u32 reserved[11];
  	};
  };
  
  The PCI device is specified by the triple segnr, busnr, and devfn.
  Identification in succeeding service requests is done via assigned_dev_id. The
  following flags are specified:
  
  /* Depends on KVM_CAP_IOMMU */
  #define KVM_DEV_ASSIGN_ENABLE_IOMMU	(1 << 0)
  /* The following two depend on KVM_CAP_PCI_2_3 */
  #define KVM_DEV_ASSIGN_PCI_2_3		(1 << 1)
  #define KVM_DEV_ASSIGN_MASK_INTX	(1 << 2)
  
  If KVM_DEV_ASSIGN_PCI_2_3 is set, the kernel will manage legacy INTx interrupts
  via the PCI-2.3-compliant device-level mask, thus enable IRQ sharing with other
  assigned devices or host devices. KVM_DEV_ASSIGN_MASK_INTX specifies the
  guest's view on the INTx mask, see KVM_ASSIGN_SET_INTX_MASK for details.
  
  The KVM_DEV_ASSIGN_ENABLE_IOMMU flag is a mandatory option to ensure
  isolation of the device.  Usages not specifying this flag are deprecated.
  
  Only PCI header type 0 devices with PCI BAR resources are supported by
  device assignment.  The user requesting this ioctl must have read/write
  access to the PCI sysfs resource files associated with the device.
  
  
  4.49 KVM_DEASSIGN_PCI_DEVICE
  
  Capability: KVM_CAP_DEVICE_DEASSIGNMENT
  Architectures: x86 ia64
  Type: vm ioctl
  Parameters: struct kvm_assigned_pci_dev (in)
  Returns: 0 on success, -1 on error
  
  Ends PCI device assignment, releasing all associated resources.
  
  See KVM_CAP_DEVICE_ASSIGNMENT for the data structure. Only assigned_dev_id is
  used in kvm_assigned_pci_dev to identify the device.
  
  
  4.50 KVM_ASSIGN_DEV_IRQ
  
  Capability: KVM_CAP_ASSIGN_DEV_IRQ
  Architectures: x86 ia64
  Type: vm ioctl
  Parameters: struct kvm_assigned_irq (in)
  Returns: 0 on success, -1 on error
  
  Assigns an IRQ to a passed-through device.
  
  struct kvm_assigned_irq {
  	__u32 assigned_dev_id;
  	__u32 host_irq; /* ignored (legacy field) */
  	__u32 guest_irq;
  	__u32 flags;
  	union {
  		__u32 reserved[12];
  	};
  };
  
  The following flags are defined:
  
  #define KVM_DEV_IRQ_HOST_INTX    (1 << 0)
  #define KVM_DEV_IRQ_HOST_MSI     (1 << 1)
  #define KVM_DEV_IRQ_HOST_MSIX    (1 << 2)
  
  #define KVM_DEV_IRQ_GUEST_INTX   (1 << 8)
  #define KVM_DEV_IRQ_GUEST_MSI    (1 << 9)
  #define KVM_DEV_IRQ_GUEST_MSIX   (1 << 10)
  
  It is not valid to specify multiple types per host or guest IRQ. However, the
  IRQ type of host and guest can differ or can even be null.
  
  
  4.51 KVM_DEASSIGN_DEV_IRQ
  
  Capability: KVM_CAP_ASSIGN_DEV_IRQ
  Architectures: x86 ia64
  Type: vm ioctl
  Parameters: struct kvm_assigned_irq (in)
  Returns: 0 on success, -1 on error
  
  Ends an IRQ assignment to a passed-through device.
  
  See KVM_ASSIGN_DEV_IRQ for the data structure. The target device is specified
  by assigned_dev_id, flags must correspond to the IRQ type specified on
  KVM_ASSIGN_DEV_IRQ. Partial deassignment of host or guest IRQ is allowed.
  
  
  4.52 KVM_SET_GSI_ROUTING
  
  Capability: KVM_CAP_IRQ_ROUTING
  Architectures: x86 ia64
  Type: vm ioctl
  Parameters: struct kvm_irq_routing (in)
  Returns: 0 on success, -1 on error
  
  Sets the GSI routing table entries, overwriting any previously set entries.
  
  struct kvm_irq_routing {
  	__u32 nr;
  	__u32 flags;
  	struct kvm_irq_routing_entry entries[0];
  };
  
  No flags are specified so far, the corresponding field must be set to zero.
  
  struct kvm_irq_routing_entry {
  	__u32 gsi;
  	__u32 type;
  	__u32 flags;
  	__u32 pad;
  	union {
  		struct kvm_irq_routing_irqchip irqchip;
  		struct kvm_irq_routing_msi msi;
  		__u32 pad[8];
  	} u;
  };
  
  /* gsi routing entry types */
  #define KVM_IRQ_ROUTING_IRQCHIP 1
  #define KVM_IRQ_ROUTING_MSI 2
  
  No flags are specified so far, the corresponding field must be set to zero.
  
  struct kvm_irq_routing_irqchip {
  	__u32 irqchip;
  	__u32 pin;
  };
  
  struct kvm_irq_routing_msi {
  	__u32 address_lo;
  	__u32 address_hi;
  	__u32 data;
  	__u32 pad;
  };
  
  
  4.53 KVM_ASSIGN_SET_MSIX_NR
  
  Capability: KVM_CAP_DEVICE_MSIX
  Architectures: x86 ia64
  Type: vm ioctl
  Parameters: struct kvm_assigned_msix_nr (in)
  Returns: 0 on success, -1 on error
  
  Set the number of MSI-X interrupts for an assigned device. The number is
  reset again by terminating the MSI-X assignment of the device via
  KVM_DEASSIGN_DEV_IRQ. Calling this service more than once at any earlier
  point will fail.
  
  struct kvm_assigned_msix_nr {
  	__u32 assigned_dev_id;
  	__u16 entry_nr;
  	__u16 padding;
  };
  
  #define KVM_MAX_MSIX_PER_DEV		256
  
  
  4.54 KVM_ASSIGN_SET_MSIX_ENTRY
  
  Capability: KVM_CAP_DEVICE_MSIX
  Architectures: x86 ia64
  Type: vm ioctl
  Parameters: struct kvm_assigned_msix_entry (in)
  Returns: 0 on success, -1 on error
  
  Specifies the routing of an MSI-X assigned device interrupt to a GSI. Setting
  the GSI vector to zero means disabling the interrupt.
  
  struct kvm_assigned_msix_entry {
  	__u32 assigned_dev_id;
  	__u32 gsi;
  	__u16 entry; /* The index of entry in the MSI-X table */
  	__u16 padding[3];
  };
  
  
  4.55 KVM_SET_TSC_KHZ
  
  Capability: KVM_CAP_TSC_CONTROL
  Architectures: x86
  Type: vcpu ioctl
  Parameters: virtual tsc_khz
  Returns: 0 on success, -1 on error
  
  Specifies the tsc frequency for the virtual machine. The unit of the
  frequency is KHz.
  
  
  4.56 KVM_GET_TSC_KHZ
  
  Capability: KVM_CAP_GET_TSC_KHZ
  Architectures: x86
  Type: vcpu ioctl
  Parameters: none
  Returns: virtual tsc-khz on success, negative value on error
  
  Returns the tsc frequency of the guest. The unit of the return value is
  KHz. If the host has unstable tsc this ioctl returns -EIO instead as an
  error.
  
  
  4.57 KVM_GET_LAPIC
  
  Capability: KVM_CAP_IRQCHIP
  Architectures: x86
  Type: vcpu ioctl
  Parameters: struct kvm_lapic_state (out)
  Returns: 0 on success, -1 on error
  
  #define KVM_APIC_REG_SIZE 0x400
  struct kvm_lapic_state {
  	char regs[KVM_APIC_REG_SIZE];
  };
  
  Reads the Local APIC registers and copies them into the input argument.  The
  data format and layout are the same as documented in the architecture manual.
  
  
  4.58 KVM_SET_LAPIC
  
  Capability: KVM_CAP_IRQCHIP
  Architectures: x86
  Type: vcpu ioctl
  Parameters: struct kvm_lapic_state (in)
  Returns: 0 on success, -1 on error
  
  #define KVM_APIC_REG_SIZE 0x400
  struct kvm_lapic_state {
  	char regs[KVM_APIC_REG_SIZE];
  };
  
  Copies the input argument into the the Local APIC registers.  The data format
  and layout are the same as documented in the architecture manual.
  
  
  4.59 KVM_IOEVENTFD
  
  Capability: KVM_CAP_IOEVENTFD
  Architectures: all
  Type: vm ioctl
  Parameters: struct kvm_ioeventfd (in)
  Returns: 0 on success, !0 on error
  
  This ioctl attaches or detaches an ioeventfd to a legal pio/mmio address
  within the guest.  A guest write in the registered address will signal the
  provided event instead of triggering an exit.
  
  struct kvm_ioeventfd {
  	__u64 datamatch;
  	__u64 addr;        /* legal pio/mmio address */
  	__u32 len;         /* 1, 2, 4, or 8 bytes    */
  	__s32 fd;
  	__u32 flags;
  	__u8  pad[36];
  };
  
  For the special case of virtio-ccw devices on s390, the ioevent is matched
  to a subchannel/virtqueue tuple instead.
  
  The following flags are defined:
  
  #define KVM_IOEVENTFD_FLAG_DATAMATCH (1 << kvm_ioeventfd_flag_nr_datamatch)
  #define KVM_IOEVENTFD_FLAG_PIO       (1 << kvm_ioeventfd_flag_nr_pio)
  #define KVM_IOEVENTFD_FLAG_DEASSIGN  (1 << kvm_ioeventfd_flag_nr_deassign)
  #define KVM_IOEVENTFD_FLAG_VIRTIO_CCW_NOTIFY \
  	(1 << kvm_ioeventfd_flag_nr_virtio_ccw_notify)
  
  If datamatch flag is set, the event will be signaled only if the written value
  to the registered address is equal to datamatch in struct kvm_ioeventfd.
  
  For virtio-ccw devices, addr contains the subchannel id and datamatch the
  virtqueue index.
  
  
  4.60 KVM_DIRTY_TLB
  
  Capability: KVM_CAP_SW_TLB
  Architectures: ppc
  Type: vcpu ioctl
  Parameters: struct kvm_dirty_tlb (in)
  Returns: 0 on success, -1 on error
  
  struct kvm_dirty_tlb {
  	__u64 bitmap;
  	__u32 num_dirty;
  };
  
  This must be called whenever userspace has changed an entry in the shared
  TLB, prior to calling KVM_RUN on the associated vcpu.
  
  The "bitmap" field is the userspace address of an array.  This array
  consists of a number of bits, equal to the total number of TLB entries as
  determined by the last successful call to KVM_CONFIG_TLB, rounded up to the
  nearest multiple of 64.
  
  Each bit corresponds to one TLB entry, ordered the same as in the shared TLB
  array.
  
  The array is little-endian: the bit 0 is the least significant bit of the
  first byte, bit 8 is the least significant bit of the second byte, etc.
  This avoids any complications with differing word sizes.
  
  The "num_dirty" field is a performance hint for KVM to determine whether it
  should skip processing the bitmap and just invalidate everything.  It must
  be set to the number of set bits in the bitmap.
  
  
  4.61 KVM_ASSIGN_SET_INTX_MASK
  
  Capability: KVM_CAP_PCI_2_3
  Architectures: x86
  Type: vm ioctl
  Parameters: struct kvm_assigned_pci_dev (in)
  Returns: 0 on success, -1 on error
  
  Allows userspace to mask PCI INTx interrupts from the assigned device.  The
  kernel will not deliver INTx interrupts to the guest between setting and
  clearing of KVM_ASSIGN_SET_INTX_MASK via this interface.  This enables use of
  and emulation of PCI 2.3 INTx disable command register behavior.
  
  This may be used for both PCI 2.3 devices supporting INTx disable natively and
  older devices lacking this support. Userspace is responsible for emulating the
  read value of the INTx disable bit in the guest visible PCI command register.
  When modifying the INTx disable state, userspace should precede updating the
  physical device command register by calling this ioctl to inform the kernel of
  the new intended INTx mask state.
  
  Note that the kernel uses the device INTx disable bit to internally manage the
  device interrupt state for PCI 2.3 devices.  Reads of this register may
  therefore not match the expected value.  Writes should always use the guest
  intended INTx disable value rather than attempting to read-copy-update the
  current physical device state.  Races between user and kernel updates to the
  INTx disable bit are handled lazily in the kernel.  It's possible the device
  may generate unintended interrupts, but they will not be injected into the
  guest.
  
  See KVM_ASSIGN_DEV_IRQ for the data structure.  The target device is specified
  by assigned_dev_id.  In the flags field, only KVM_DEV_ASSIGN_MASK_INTX is
  evaluated.
  
  
  4.62 KVM_CREATE_SPAPR_TCE
  
  Capability: KVM_CAP_SPAPR_TCE
  Architectures: powerpc
  Type: vm ioctl
  Parameters: struct kvm_create_spapr_tce (in)
  Returns: file descriptor for manipulating the created TCE table
  
  This creates a virtual TCE (translation control entry) table, which
  is an IOMMU for PAPR-style virtual I/O.  It is used to translate
  logical addresses used in virtual I/O into guest physical addresses,
  and provides a scatter/gather capability for PAPR virtual I/O.
  
  /* for KVM_CAP_SPAPR_TCE */
  struct kvm_create_spapr_tce {
  	__u64 liobn;
  	__u32 window_size;
  };
  
  The liobn field gives the logical IO bus number for which to create a
  TCE table.  The window_size field specifies the size of the DMA window
  which this TCE table will translate - the table will contain one 64
  bit TCE entry for every 4kiB of the DMA window.
  
  When the guest issues an H_PUT_TCE hcall on a liobn for which a TCE
  table has been created using this ioctl(), the kernel will handle it
  in real mode, updating the TCE table.  H_PUT_TCE calls for other
  liobns will cause a vm exit and must be handled by userspace.
  
  The return value is a file descriptor which can be passed to mmap(2)
  to map the created TCE table into userspace.  This lets userspace read
  the entries written by kernel-handled H_PUT_TCE calls, and also lets
  userspace update the TCE table directly which is useful in some
  circumstances.
  
  
  4.63 KVM_ALLOCATE_RMA
  
  Capability: KVM_CAP_PPC_RMA
  Architectures: powerpc
  Type: vm ioctl
  Parameters: struct kvm_allocate_rma (out)
  Returns: file descriptor for mapping the allocated RMA
  
  This allocates a Real Mode Area (RMA) from the pool allocated at boot
  time by the kernel.  An RMA is a physically-contiguous, aligned region
  of memory used on older POWER processors to provide the memory which
  will be accessed by real-mode (MMU off) accesses in a KVM guest.
  POWER processors support a set of sizes for the RMA that usually
  includes 64MB, 128MB, 256MB and some larger powers of two.
  
  /* for KVM_ALLOCATE_RMA */
  struct kvm_allocate_rma {
  	__u64 rma_size;
  };
  
  The return value is a file descriptor which can be passed to mmap(2)
  to map the allocated RMA into userspace.  The mapped area can then be
  passed to the KVM_SET_USER_MEMORY_REGION ioctl to establish it as the
  RMA for a virtual machine.  The size of the RMA in bytes (which is
  fixed at host kernel boot time) is returned in the rma_size field of
  the argument structure.
  
  The KVM_CAP_PPC_RMA capability is 1 or 2 if the KVM_ALLOCATE_RMA ioctl
  is supported; 2 if the processor requires all virtual machines to have
  an RMA, or 1 if the processor can use an RMA but doesn't require it,
  because it supports the Virtual RMA (VRMA) facility.
  
  
  4.64 KVM_NMI
  
  Capability: KVM_CAP_USER_NMI
  Architectures: x86
  Type: vcpu ioctl
  Parameters: none
  Returns: 0 on success, -1 on error
  
  Queues an NMI on the thread's vcpu.  Note this is well defined only
  when KVM_CREATE_IRQCHIP has not been called, since this is an interface
  between the virtual cpu core and virtual local APIC.  After KVM_CREATE_IRQCHIP
  has been called, this interface is completely emulated within the kernel.
  
  To use this to emulate the LINT1 input with KVM_CREATE_IRQCHIP, use the
  following algorithm:
  
    - pause the vpcu
    - read the local APIC's state (KVM_GET_LAPIC)
    - check whether changing LINT1 will queue an NMI (see the LVT entry for LINT1)
    - if so, issue KVM_NMI
    - resume the vcpu
  
  Some guests configure the LINT1 NMI input to cause a panic, aiding in
  debugging.
  
  
  4.65 KVM_S390_UCAS_MAP
  
  Capability: KVM_CAP_S390_UCONTROL
  Architectures: s390
  Type: vcpu ioctl
  Parameters: struct kvm_s390_ucas_mapping (in)
  Returns: 0 in case of success
  
  The parameter is defined like this:
  	struct kvm_s390_ucas_mapping {
  		__u64 user_addr;
  		__u64 vcpu_addr;
  		__u64 length;
  	};
  
  This ioctl maps the memory at "user_addr" with the length "length" to
  the vcpu's address space starting at "vcpu_addr". All parameters need to
  be aligned by 1 megabyte.
  
  
  4.66 KVM_S390_UCAS_UNMAP
  
  Capability: KVM_CAP_S390_UCONTROL
  Architectures: s390
  Type: vcpu ioctl
  Parameters: struct kvm_s390_ucas_mapping (in)
  Returns: 0 in case of success
  
  The parameter is defined like this:
  	struct kvm_s390_ucas_mapping {
  		__u64 user_addr;
  		__u64 vcpu_addr;
  		__u64 length;
  	};
  
  This ioctl unmaps the memory in the vcpu's address space starting at
  "vcpu_addr" with the length "length". The field "user_addr" is ignored.
  All parameters need to be aligned by 1 megabyte.
  
  
  4.67 KVM_S390_VCPU_FAULT
  
  Capability: KVM_CAP_S390_UCONTROL
  Architectures: s390
  Type: vcpu ioctl
  Parameters: vcpu absolute address (in)
  Returns: 0 in case of success
  
  This call creates a page table entry on the virtual cpu's address space
  (for user controlled virtual machines) or the virtual machine's address
  space (for regular virtual machines). This only works for minor faults,
  thus it's recommended to access subject memory page via the user page
  table upfront. This is useful to handle validity intercepts for user
  controlled virtual machines to fault in the virtual cpu's lowcore pages
  prior to calling the KVM_RUN ioctl.
  
  
  4.68 KVM_SET_ONE_REG
  
  Capability: KVM_CAP_ONE_REG
  Architectures: all
  Type: vcpu ioctl
  Parameters: struct kvm_one_reg (in)
  Returns: 0 on success, negative value on failure
  
  struct kvm_one_reg {
         __u64 id;
         __u64 addr;
  };
  
  Using this ioctl, a single vcpu register can be set to a specific value
  defined by user space with the passed in struct kvm_one_reg, where id
  refers to the register identifier as described below and addr is a pointer
  to a variable with the respective size. There can be architecture agnostic
  and architecture specific registers. Each have their own range of operation
  and their own constants and width. To keep track of the implemented
  registers, find a list below:
  
    Arch  |       Register        | Width (bits)
          |                       |
    PPC   | KVM_REG_PPC_HIOR      | 64
    PPC   | KVM_REG_PPC_IAC1      | 64
    PPC   | KVM_REG_PPC_IAC2      | 64
    PPC   | KVM_REG_PPC_IAC3      | 64
    PPC   | KVM_REG_PPC_IAC4      | 64
    PPC   | KVM_REG_PPC_DAC1      | 64
    PPC   | KVM_REG_PPC_DAC2      | 64
    PPC   | KVM_REG_PPC_DABR      | 64
    PPC   | KVM_REG_PPC_DSCR      | 64
    PPC   | KVM_REG_PPC_PURR      | 64
    PPC   | KVM_REG_PPC_SPURR     | 64
    PPC   | KVM_REG_PPC_DAR       | 64
    PPC   | KVM_REG_PPC_DSISR     | 32
    PPC   | KVM_REG_PPC_AMR       | 64
    PPC   | KVM_REG_PPC_UAMOR     | 64
    PPC   | KVM_REG_PPC_MMCR0     | 64
    PPC   | KVM_REG_PPC_MMCR1     | 64
    PPC   | KVM_REG_PPC_MMCRA     | 64
    PPC   | KVM_REG_PPC_PMC1      | 32
    PPC   | KVM_REG_PPC_PMC2      | 32
    PPC   | KVM_REG_PPC_PMC3      | 32
    PPC   | KVM_REG_PPC_PMC4      | 32
    PPC   | KVM_REG_PPC_PMC5      | 32
    PPC   | KVM_REG_PPC_PMC6      | 32
    PPC   | KVM_REG_PPC_PMC7      | 32
    PPC   | KVM_REG_PPC_PMC8      | 32
    PPC   | KVM_REG_PPC_FPR0      | 64
            ...
    PPC   | KVM_REG_PPC_FPR31     | 64
    PPC   | KVM_REG_PPC_VR0       | 128
            ...
    PPC   | KVM_REG_PPC_VR31      | 128
    PPC   | KVM_REG_PPC_VSR0      | 128
            ...
    PPC   | KVM_REG_PPC_VSR31     | 128
    PPC   | KVM_REG_PPC_FPSCR     | 64
    PPC   | KVM_REG_PPC_VSCR      | 32
    PPC   | KVM_REG_PPC_VPA_ADDR  | 64
    PPC   | KVM_REG_PPC_VPA_SLB   | 128
    PPC   | KVM_REG_PPC_VPA_DTL   | 128
    PPC   | KVM_REG_PPC_EPCR	| 32
    PPC   | KVM_REG_PPC_EPR	| 32
    PPC   | KVM_REG_PPC_TCR	| 32
    PPC   | KVM_REG_PPC_TSR	| 32
    PPC   | KVM_REG_PPC_OR_TSR	| 32
    PPC   | KVM_REG_PPC_CLEAR_TSR	| 32
    PPC   | KVM_REG_PPC_MAS0	| 32
    PPC   | KVM_REG_PPC_MAS1	| 32
    PPC   | KVM_REG_PPC_MAS2	| 64
    PPC   | KVM_REG_PPC_MAS7_3	| 64
    PPC   | KVM_REG_PPC_MAS4	| 32
    PPC   | KVM_REG_PPC_MAS6	| 32
    PPC   | KVM_REG_PPC_MMUCFG	| 32
    PPC   | KVM_REG_PPC_TLB0CFG	| 32
    PPC   | KVM_REG_PPC_TLB1CFG	| 32
    PPC   | KVM_REG_PPC_TLB2CFG	| 32
    PPC   | KVM_REG_PPC_TLB3CFG	| 32
    PPC   | KVM_REG_PPC_TLB0PS	| 32
    PPC   | KVM_REG_PPC_TLB1PS	| 32
    PPC   | KVM_REG_PPC_TLB2PS	| 32
    PPC   | KVM_REG_PPC_TLB3PS	| 32
    PPC   | KVM_REG_PPC_EPTCFG	| 32
    PPC   | KVM_REG_PPC_ICP_STATE | 64
    PPC   | KVM_REG_PPC_TB_OFFSET	| 64
    PPC   | KVM_REG_PPC_SPMC1	| 32
    PPC   | KVM_REG_PPC_SPMC2	| 32
    PPC   | KVM_REG_PPC_IAMR	| 64
    PPC   | KVM_REG_PPC_TFHAR	| 64
    PPC   | KVM_REG_PPC_TFIAR	| 64
    PPC   | KVM_REG_PPC_TEXASR	| 64
    PPC   | KVM_REG_PPC_FSCR	| 64
    PPC   | KVM_REG_PPC_PSPB	| 32
    PPC   | KVM_REG_PPC_EBBHR	| 64
    PPC   | KVM_REG_PPC_EBBRR	| 64
    PPC   | KVM_REG_PPC_BESCR	| 64
    PPC   | KVM_REG_PPC_TAR	| 64
    PPC   | KVM_REG_PPC_DPDES	| 64
    PPC   | KVM_REG_PPC_DAWR	| 64
    PPC   | KVM_REG_PPC_DAWRX	| 64
    PPC   | KVM_REG_PPC_CIABR	| 64
    PPC   | KVM_REG_PPC_IC	| 64
    PPC   | KVM_REG_PPC_VTB	| 64
    PPC   | KVM_REG_PPC_CSIGR	| 64
    PPC   | KVM_REG_PPC_TACR	| 64
    PPC   | KVM_REG_PPC_TCSCR	| 64
    PPC   | KVM_REG_PPC_PID	| 64
    PPC   | KVM_REG_PPC_ACOP	| 64
    PPC   | KVM_REG_PPC_VRSAVE	| 32
    PPC   | KVM_REG_PPC_LPCR	| 64
    PPC   | KVM_REG_PPC_PPR	| 64
    PPC   | KVM_REG_PPC_ARCH_COMPAT 32
    PPC   | KVM_REG_PPC_DABRX     | 32
    PPC   | KVM_REG_PPC_TM_GPR0	| 64
            ...
    PPC   | KVM_REG_PPC_TM_GPR31	| 64
    PPC   | KVM_REG_PPC_TM_VSR0	| 128
            ...
    PPC   | KVM_REG_PPC_TM_VSR63	| 128
    PPC   | KVM_REG_PPC_TM_CR	| 64
    PPC   | KVM_REG_PPC_TM_LR	| 64
    PPC   | KVM_REG_PPC_TM_CTR	| 64
    PPC   | KVM_REG_PPC_TM_FPSCR	| 64
    PPC   | KVM_REG_PPC_TM_AMR	| 64
    PPC   | KVM_REG_PPC_TM_PPR	| 64
    PPC   | KVM_REG_PPC_TM_VRSAVE	| 64
    PPC   | KVM_REG_PPC_TM_VSCR	| 32
    PPC   | KVM_REG_PPC_TM_DSCR	| 64
    PPC   | KVM_REG_PPC_TM_TAR	| 64
  
  ARM registers are mapped using the lower 32 bits.  The upper 16 of that
  is the register group type, or coprocessor number:
  
  ARM core registers have the following id bit patterns:
    0x4020 0000 0010 <index into the kvm_regs struct:16>
  
  ARM 32-bit CP15 registers have the following id bit patterns:
    0x4020 0000 000F <zero:1> <crn:4> <crm:4> <opc1:4> <opc2:3>
  
  ARM 64-bit CP15 registers have the following id bit patterns:
    0x4030 0000 000F <zero:1> <zero:4> <crm:4> <opc1:4> <zero:3>
  
  ARM CCSIDR registers are demultiplexed by CSSELR value:
    0x4020 0000 0011 00 <csselr:8>
  
  ARM 32-bit VFP control registers have the following id bit patterns:
    0x4020 0000 0012 1 <regno:12>
  
  ARM 64-bit FP registers have the following id bit patterns:
    0x4030 0000 0012 0 <regno:12>
  
  
  arm64 registers are mapped using the lower 32 bits. The upper 16 of
  that is the register group type, or coprocessor number:
  
  arm64 core/FP-SIMD registers have the following id bit patterns. Note
  that the size of the access is variable, as the kvm_regs structure
  contains elements ranging from 32 to 128 bits. The index is a 32bit
  value in the kvm_regs structure seen as a 32bit array.
    0x60x0 0000 0010 <index into the kvm_regs struct:16>
  
  arm64 CCSIDR registers are demultiplexed by CSSELR value:
    0x6020 0000 0011 00 <csselr:8>
  
  arm64 system registers have the following id bit patterns:
    0x6030 0000 0013 <op0:2> <op1:3> <crn:4> <crm:4> <op2:3>
  
  4.69 KVM_GET_ONE_REG
  
  Capability: KVM_CAP_ONE_REG
  Architectures: all
  Type: vcpu ioctl
  Parameters: struct kvm_one_reg (in and out)
  Returns: 0 on success, negative value on failure
  
  This ioctl allows to receive the value of a single register implemented
  in a vcpu. The register to read is indicated by the "id" field of the
  kvm_one_reg struct passed in. On success, the register value can be found
  at the memory location pointed to by "addr".
  
  The list of registers accessible using this interface is identical to the
  list in 4.68.
  
  
  4.70 KVM_KVMCLOCK_CTRL
  
  Capability: KVM_CAP_KVMCLOCK_CTRL
  Architectures: Any that implement pvclocks (currently x86 only)
  Type: vcpu ioctl
  Parameters: None
  Returns: 0 on success, -1 on error
  
  This signals to the host kernel that the specified guest is being paused by
  userspace.  The host will set a flag in the pvclock structure that is checked
  from the soft lockup watchdog.  The flag is part of the pvclock structure that
  is shared between guest and host, specifically the second bit of the flags
  field of the pvclock_vcpu_time_info structure.  It will be set exclusively by
  the host and read/cleared exclusively by the guest.  The guest operation of
  checking and clearing the flag must an atomic operation so
  load-link/store-conditional, or equivalent must be used.  There are two cases
  where the guest will clear the flag: when the soft lockup watchdog timer resets
  itself or when a soft lockup is detected.  This ioctl can be called any time
  after pausing the vcpu, but before it is resumed.
  
  
  4.71 KVM_SIGNAL_MSI
  
  Capability: KVM_CAP_SIGNAL_MSI
  Architectures: x86
  Type: vm ioctl
  Parameters: struct kvm_msi (in)
  Returns: >0 on delivery, 0 if guest blocked the MSI, and -1 on error
  
  Directly inject a MSI message. Only valid with in-kernel irqchip that handles
  MSI messages.
  
  struct kvm_msi {
  	__u32 address_lo;
  	__u32 address_hi;
  	__u32 data;
  	__u32 flags;
  	__u8  pad[16];
  };
  
  No flags are defined so far. The corresponding field must be 0.
  
  
  4.71 KVM_CREATE_PIT2
  
  Capability: KVM_CAP_PIT2
  Architectures: x86
  Type: vm ioctl
  Parameters: struct kvm_pit_config (in)
  Returns: 0 on success, -1 on error
  
  Creates an in-kernel device model for the i8254 PIT. This call is only valid
  after enabling in-kernel irqchip support via KVM_CREATE_IRQCHIP. The following
  parameters have to be passed:
  
  struct kvm_pit_config {
  	__u32 flags;
  	__u32 pad[15];
  };
  
  Valid flags are:
  
  #define KVM_PIT_SPEAKER_DUMMY     1 /* emulate speaker port stub */
  
  PIT timer interrupts may use a per-VM kernel thread for injection. If it
  exists, this thread will have a name of the following pattern:
  
  kvm-pit/<owner-process-pid>
  
  When running a guest with elevated priorities, the scheduling parameters of
  this thread may have to be adjusted accordingly.
  
  This IOCTL replaces the obsolete KVM_CREATE_PIT.
  
  
  4.72 KVM_GET_PIT2
  
  Capability: KVM_CAP_PIT_STATE2
  Architectures: x86
  Type: vm ioctl
  Parameters: struct kvm_pit_state2 (out)
  Returns: 0 on success, -1 on error
  
  Retrieves the state of the in-kernel PIT model. Only valid after
  KVM_CREATE_PIT2. The state is returned in the following structure:
  
  struct kvm_pit_state2 {
  	struct kvm_pit_channel_state channels[3];
  	__u32 flags;
  	__u32 reserved[9];
  };
  
  Valid flags are:
  
  /* disable PIT in HPET legacy mode */
  #define KVM_PIT_FLAGS_HPET_LEGACY  0x00000001
  
  This IOCTL replaces the obsolete KVM_GET_PIT.
  
  
  4.73 KVM_SET_PIT2
  
  Capability: KVM_CAP_PIT_STATE2
  Architectures: x86
  Type: vm ioctl
  Parameters: struct kvm_pit_state2 (in)
  Returns: 0 on success, -1 on error
  
  Sets the state of the in-kernel PIT model. Only valid after KVM_CREATE_PIT2.
  See KVM_GET_PIT2 for details on struct kvm_pit_state2.
  
  This IOCTL replaces the obsolete KVM_SET_PIT.
  
  
  4.74 KVM_PPC_GET_SMMU_INFO
  
  Capability: KVM_CAP_PPC_GET_SMMU_INFO
  Architectures: powerpc
  Type: vm ioctl
  Parameters: None
  Returns: 0 on success, -1 on error
  
  This populates and returns a structure describing the features of
  the "Server" class MMU emulation supported by KVM.
  This can in turn be used by userspace to generate the appropriate
  device-tree properties for the guest operating system.
  
  The structure contains some global informations, followed by an
  array of supported segment page sizes:
  
        struct kvm_ppc_smmu_info {
  	     __u64 flags;
  	     __u32 slb_size;
  	     __u32 pad;
  	     struct kvm_ppc_one_seg_page_size sps[KVM_PPC_PAGE_SIZES_MAX_SZ];
        };
  
  The supported flags are:
  
      - KVM_PPC_PAGE_SIZES_REAL:
          When that flag is set, guest page sizes must "fit" the backing
          store page sizes. When not set, any page size in the list can
          be used regardless of how they are backed by userspace.
  
      - KVM_PPC_1T_SEGMENTS
          The emulated MMU supports 1T segments in addition to the
          standard 256M ones.
  
  The "slb_size" field indicates how many SLB entries are supported
  
  The "sps" array contains 8 entries indicating the supported base
  page sizes for a segment in increasing order. Each entry is defined
  as follow:
  
     struct kvm_ppc_one_seg_page_size {
  	__u32 page_shift;	/* Base page shift of segment (or 0) */
  	__u32 slb_enc;		/* SLB encoding for BookS */
  	struct kvm_ppc_one_page_size enc[KVM_PPC_PAGE_SIZES_MAX_SZ];
     };
  
  An entry with a "page_shift" of 0 is unused. Because the array is
  organized in increasing order, a lookup can stop when encoutering
  such an entry.
  
  The "slb_enc" field provides the encoding to use in the SLB for the
  page size. The bits are in positions such as the value can directly
  be OR'ed into the "vsid" argument of the slbmte instruction.
  
  The "enc" array is a list which for each of those segment base page
  size provides the list of supported actual page sizes (which can be
  only larger or equal to the base page size), along with the
  corresponding encoding in the hash PTE. Similarly, the array is
  8 entries sorted by increasing sizes and an entry with a "0" shift
  is an empty entry and a terminator:
  
     struct kvm_ppc_one_page_size {
  	__u32 page_shift;	/* Page shift (or 0) */
  	__u32 pte_enc;		/* Encoding in the HPTE (>>12) */
     };
  
  The "pte_enc" field provides a value that can OR'ed into the hash
  PTE's RPN field (ie, it needs to be shifted left by 12 to OR it
  into the hash PTE second double word).
  
  4.75 KVM_IRQFD
  
  Capability: KVM_CAP_IRQFD
  Architectures: x86
  Type: vm ioctl
  Parameters: struct kvm_irqfd (in)
  Returns: 0 on success, -1 on error
  
  Allows setting an eventfd to directly trigger a guest interrupt.
  kvm_irqfd.fd specifies the file descriptor to use as the eventfd and
  kvm_irqfd.gsi specifies the irqchip pin toggled by this event.  When
  an event is triggered on the eventfd, an interrupt is injected into
  the guest using the specified gsi pin.  The irqfd is removed using
  the KVM_IRQFD_FLAG_DEASSIGN flag, specifying both kvm_irqfd.fd
  and kvm_irqfd.gsi.
  
  With KVM_CAP_IRQFD_RESAMPLE, KVM_IRQFD supports a de-assert and notify
  mechanism allowing emulation of level-triggered, irqfd-based
  interrupts.  When KVM_IRQFD_FLAG_RESAMPLE is set the user must pass an
  additional eventfd in the kvm_irqfd.resamplefd field.  When operating
  in resample mode, posting of an interrupt through kvm_irq.fd asserts
  the specified gsi in the irqchip.  When the irqchip is resampled, such
  as from an EOI, the gsi is de-asserted and the user is notified via
  kvm_irqfd.resamplefd.  It is the user's responsibility to re-queue
  the interrupt if the device making use of it still requires service.
  Note that closing the resamplefd is not sufficient to disable the
  irqfd.  The KVM_IRQFD_FLAG_RESAMPLE is only necessary on assignment
  and need not be specified with KVM_IRQFD_FLAG_DEASSIGN.
  
  4.76 KVM_PPC_ALLOCATE_HTAB
  
  Capability: KVM_CAP_PPC_ALLOC_HTAB
  Architectures: powerpc
  Type: vm ioctl
  Parameters: Pointer to u32 containing hash table order (in/out)
  Returns: 0 on success, -1 on error
  
  This requests the host kernel to allocate an MMU hash table for a
  guest using the PAPR paravirtualization interface.  This only does
  anything if the kernel is configured to use the Book 3S HV style of
  virtualization.  Otherwise the capability doesn't exist and the ioctl
  returns an ENOTTY error.  The rest of this description assumes Book 3S
  HV.
  
  There must be no vcpus running when this ioctl is called; if there
  are, it will do nothing and return an EBUSY error.
  
  The parameter is a pointer to a 32-bit unsigned integer variable
  containing the order (log base 2) of the desired size of the hash
  table, which must be between 18 and 46.  On successful return from the
  ioctl, it will have been updated with the order of the hash table that
  was allocated.
  
  If no hash table has been allocated when any vcpu is asked to run
  (with the KVM_RUN ioctl), the host kernel will allocate a
  default-sized hash table (16 MB).
  
  If this ioctl is called when a hash table has already been allocated,
  the kernel will clear out the existing hash table (zero all HPTEs) and
  return the hash table order in the parameter.  (If the guest is using
  the virtualized real-mode area (VRMA) facility, the kernel will
  re-create the VMRA HPTEs on the next KVM_RUN of any vcpu.)
  
  4.77 KVM_S390_INTERRUPT
  
  Capability: basic
  Architectures: s390
  Type: vm ioctl, vcpu ioctl
  Parameters: struct kvm_s390_interrupt (in)
  Returns: 0 on success, -1 on error
  
  Allows to inject an interrupt to the guest. Interrupts can be floating
  (vm ioctl) or per cpu (vcpu ioctl), depending on the interrupt type.
  
  Interrupt parameters are passed via kvm_s390_interrupt:
  
  struct kvm_s390_interrupt {
  	__u32 type;
  	__u32 parm;
  	__u64 parm64;
  };
  
  type can be one of the following:
  
  KVM_S390_SIGP_STOP (vcpu) - sigp restart
  KVM_S390_PROGRAM_INT (vcpu) - program check; code in parm
  KVM_S390_SIGP_SET_PREFIX (vcpu) - sigp set prefix; prefix address in parm
  KVM_S390_RESTART (vcpu) - restart
  KVM_S390_INT_VIRTIO (vm) - virtio external interrupt; external interrupt
  			   parameters in parm and parm64
  KVM_S390_INT_SERVICE (vm) - sclp external interrupt; sclp parameter in parm
  KVM_S390_INT_EMERGENCY (vcpu) - sigp emergency; source cpu in parm
  KVM_S390_INT_EXTERNAL_CALL (vcpu) - sigp external call; source cpu in parm
  KVM_S390_INT_IO(ai,cssid,ssid,schid) (vm) - compound value to indicate an
      I/O interrupt (ai - adapter interrupt; cssid,ssid,schid - subchannel);
      I/O interruption parameters in parm (subchannel) and parm64 (intparm,
      interruption subclass)
  KVM_S390_MCHK (vm, vcpu) - machine check interrupt; cr 14 bits in parm,
                             machine check interrupt code in parm64 (note that
                             machine checks needing further payload are not
                             supported by this ioctl)
  
  Note that the vcpu ioctl is asynchronous to vcpu execution.
  
  4.78 KVM_PPC_GET_HTAB_FD
  
  Capability: KVM_CAP_PPC_HTAB_FD
  Architectures: powerpc
  Type: vm ioctl
  Parameters: Pointer to struct kvm_get_htab_fd (in)
  Returns: file descriptor number (>= 0) on success, -1 on error
  
  This returns a file descriptor that can be used either to read out the
  entries in the guest's hashed page table (HPT), or to write entries to
  initialize the HPT.  The returned fd can only be written to if the
  KVM_GET_HTAB_WRITE bit is set in the flags field of the argument, and
  can only be read if that bit is clear.  The argument struct looks like
  this:
  
  /* For KVM_PPC_GET_HTAB_FD */
  struct kvm_get_htab_fd {
  	__u64	flags;
  	__u64	start_index;
  	__u64	reserved[2];
  };
  
  /* Values for kvm_get_htab_fd.flags */
  #define KVM_GET_HTAB_BOLTED_ONLY	((__u64)0x1)
  #define KVM_GET_HTAB_WRITE		((__u64)0x2)
  
  The `start_index' field gives the index in the HPT of the entry at
  which to start reading.  It is ignored when writing.
  
  Reads on the fd will initially supply information about all
  "interesting" HPT entries.  Interesting entries are those with the
  bolted bit set, if the KVM_GET_HTAB_BOLTED_ONLY bit is set, otherwise
  all entries.  When the end of the HPT is reached, the read() will
  return.  If read() is called again on the fd, it will start again from
  the beginning of the HPT, but will only return HPT entries that have
  changed since they were last read.
  
  Data read or written is structured as a header (8 bytes) followed by a
  series of valid HPT entries (16 bytes) each.  The header indicates how
  many valid HPT entries there are and how many invalid entries follow
  the valid entries.  The invalid entries are not represented explicitly
  in the stream.  The header format is:
  
  struct kvm_get_htab_header {
  	__u32	index;
  	__u16	n_valid;
  	__u16	n_invalid;
  };
  
  Writes to the fd create HPT entries starting at the index given in the
  header; first `n_valid' valid entries with contents from the data
  written, then `n_invalid' invalid entries, invalidating any previously
  valid entries found.
  
  4.79 KVM_CREATE_DEVICE
  
  Capability: KVM_CAP_DEVICE_CTRL
  Type: vm ioctl
  Parameters: struct kvm_create_device (in/out)
  Returns: 0 on success, -1 on error
  Errors:
    ENODEV: The device type is unknown or unsupported
    EEXIST: Device already created, and this type of device may not
            be instantiated multiple times
  
    Other error conditions may be defined by individual device types or
    have their standard meanings.
  
  Creates an emulated device in the kernel.  The file descriptor returned
  in fd can be used with KVM_SET/GET/HAS_DEVICE_ATTR.
  
  If the KVM_CREATE_DEVICE_TEST flag is set, only test whether the
  device type is supported (not necessarily whether it can be created
  in the current vm).
  
  Individual devices should not define flags.  Attributes should be used
  for specifying any behavior that is not implied by the device type
  number.
  
  struct kvm_create_device {
  	__u32	type;	/* in: KVM_DEV_TYPE_xxx */
  	__u32	fd;	/* out: device handle */
  	__u32	flags;	/* in: KVM_CREATE_DEVICE_xxx */
  };
  
  4.80 KVM_SET_DEVICE_ATTR/KVM_GET_DEVICE_ATTR
  
  Capability: KVM_CAP_DEVICE_CTRL
  Type: device ioctl
  Parameters: struct kvm_device_attr
  Returns: 0 on success, -1 on error
  Errors:
    ENXIO:  The group or attribute is unknown/unsupported for this device
    EPERM:  The attribute cannot (currently) be accessed this way
            (e.g. read-only attribute, or attribute that only makes
            sense when the device is in a different state)
  
    Other error conditions may be defined by individual device types.
  
  Gets/sets a specified piece of device configuration and/or state.  The
  semantics are device-specific.  See individual device documentation in
  the "devices" directory.  As with ONE_REG, the size of the data
  transferred is defined by the particular attribute.
  
  struct kvm_device_attr {
  	__u32	flags;		/* no flags currently defined */
  	__u32	group;		/* device-defined */
  	__u64	attr;		/* group-defined */
  	__u64	addr;		/* userspace address of attr data */
  };
  
  4.81 KVM_HAS_DEVICE_ATTR
  
  Capability: KVM_CAP_DEVICE_CTRL
  Type: device ioctl
  Parameters: struct kvm_device_attr
  Returns: 0 on success, -1 on error
  Errors:
    ENXIO:  The group or attribute is unknown/unsupported for this device
  
  Tests whether a device supports a particular attribute.  A successful
  return indicates the attribute is implemented.  It does not necessarily
  indicate that the attribute can be read or written in the device's
  current state.  "addr" is ignored.
  
  4.82 KVM_ARM_VCPU_INIT
  
  Capability: basic
  Architectures: arm, arm64
  Type: vcpu ioctl
  Parameters: struct kvm_vcpu_init (in)
  Returns: 0 on success; -1 on error
  Errors:
    EINVAL:    the target is unknown, or the combination of features is invalid.
    ENOENT:    a features bit specified is unknown.
  
  This tells KVM what type of CPU to present to the guest, and what
  optional features it should have.  This will cause a reset of the cpu
  registers to their initial values.  If this is not called, KVM_RUN will
  return ENOEXEC for that vcpu.
  
  Note that because some registers reflect machine topology, all vcpus
  should be created before this ioctl is invoked.
  
  Possible features:
  	- KVM_ARM_VCPU_POWER_OFF: Starts the CPU in a power-off state.
  	  Depends on KVM_CAP_ARM_PSCI.
  	- KVM_ARM_VCPU_EL1_32BIT: Starts the CPU in a 32bit mode.
  	  Depends on KVM_CAP_ARM_EL1_32BIT (arm64 only).
  
  
  4.83 KVM_ARM_PREFERRED_TARGET
  
  Capability: basic
  Architectures: arm, arm64
  Type: vm ioctl
  Parameters: struct struct kvm_vcpu_init (out)
  Returns: 0 on success; -1 on error
  Errors:
    ENODEV:    no preferred target available for the host
  
  This queries KVM for preferred CPU target type which can be emulated
  by KVM on underlying host.
  
  The ioctl returns struct kvm_vcpu_init instance containing information
  about preferred CPU target type and recommended features for it.  The
  kvm_vcpu_init->features bitmap returned will have feature bits set if
  the preferred target recommends setting these features, but this is
  not mandatory.
  
  The information returned by this ioctl can be used to prepare an instance
  of struct kvm_vcpu_init for KVM_ARM_VCPU_INIT ioctl which will result in
  in VCPU matching underlying host.
  
  
  4.84 KVM_GET_REG_LIST
  
  Capability: basic
  Architectures: arm, arm64
  Type: vcpu ioctl
  Parameters: struct kvm_reg_list (in/out)
  Returns: 0 on success; -1 on error
  Errors:
    E2BIG:     the reg index list is too big to fit in the array specified by
               the user (the number required will be written into n).
  
  struct kvm_reg_list {
  	__u64 n; /* number of registers in reg[] */
  	__u64 reg[0];
  };
  
  This ioctl returns the guest registers that are supported for the
  KVM_GET_ONE_REG/KVM_SET_ONE_REG calls.
  
  
  4.85 KVM_ARM_SET_DEVICE_ADDR (deprecated)
  
  Capability: KVM_CAP_ARM_SET_DEVICE_ADDR
  Architectures: arm, arm64
  Type: vm ioctl
  Parameters: struct kvm_arm_device_address (in)
  Returns: 0 on success, -1 on error
  Errors:
    ENODEV: The device id is unknown
    ENXIO:  Device not supported on current system
    EEXIST: Address already set
    E2BIG:  Address outside guest physical address space
    EBUSY:  Address overlaps with other device range
  
  struct kvm_arm_device_addr {
  	__u64 id;
  	__u64 addr;
  };
  
  Specify a device address in the guest's physical address space where guests
  can access emulated or directly exposed devices, which the host kernel needs
  to know about. The id field is an architecture specific identifier for a
  specific device.
  
  ARM/arm64 divides the id field into two parts, a device id and an
  address type id specific to the individual device.
  
    bits:  | 63        ...       32 | 31    ...    16 | 15    ...    0 |
    field: |        0x00000000      |     device id   |  addr type id  |
  
  ARM/arm64 currently only require this when using the in-kernel GIC
  support for the hardware VGIC features, using KVM_ARM_DEVICE_VGIC_V2
  as the device id.  When setting the base address for the guest's
  mapping of the VGIC virtual CPU and distributor interface, the ioctl
  must be called after calling KVM_CREATE_IRQCHIP, but before calling
  KVM_RUN on any of the VCPUs.  Calling this ioctl twice for any of the
  base addresses will return -EEXIST.
  
  Note, this IOCTL is deprecated and the more flexible SET/GET_DEVICE_ATTR API
  should be used instead.
  
  
  4.86 KVM_PPC_RTAS_DEFINE_TOKEN
  
  Capability: KVM_CAP_PPC_RTAS
  Architectures: ppc
  Type: vm ioctl
  Parameters: struct kvm_rtas_token_args
  Returns: 0 on success, -1 on error
  
  Defines a token value for a RTAS (Run Time Abstraction Services)
  service in order to allow it to be handled in the kernel.  The
  argument struct gives the name of the service, which must be the name
  of a service that has a kernel-side implementation.  If the token
  value is non-zero, it will be associated with that service, and
  subsequent RTAS calls by the guest specifying that token will be
  handled by the kernel.  If the token value is 0, then any token
  associated with the service will be forgotten, and subsequent RTAS
  calls by the guest for that service will be passed to userspace to be
  handled.
  
  
  5. The kvm_run structure
  ------------------------
  
  Application code obtains a pointer to the kvm_run structure by
  mmap()ing a vcpu fd.  From that point, application code can control
  execution by changing fields in kvm_run prior to calling the KVM_RUN
  ioctl, and obtain information about the reason KVM_RUN returned by
  looking up structure members.
  
  struct kvm_run {
  	/* in */
  	__u8 request_interrupt_window;
  
  Request that KVM_RUN return when it becomes possible to inject external
  interrupts into the guest.  Useful in conjunction with KVM_INTERRUPT.
  
  	__u8 padding1[7];
  
  	/* out */
  	__u32 exit_reason;
  
  When KVM_RUN has returned successfully (return value 0), this informs
  application code why KVM_RUN has returned.  Allowable values for this
  field are detailed below.
  
  	__u8 ready_for_interrupt_injection;
  
  If request_interrupt_window has been specified, this field indicates
  an interrupt can be injected now with KVM_INTERRUPT.
  
  	__u8 if_flag;
  
  The value of the current interrupt flag.  Only valid if in-kernel
  local APIC is not used.
  
  	__u8 padding2[2];
  
  	/* in (pre_kvm_run), out (post_kvm_run) */
  	__u64 cr8;
  
  The value of the cr8 register.  Only valid if in-kernel local APIC is
  not used.  Both input and output.
  
  	__u64 apic_base;
  
  The value of the APIC BASE msr.  Only valid if in-kernel local
  APIC is not used.  Both input and output.
  
  	union {
  		/* KVM_EXIT_UNKNOWN */
  		struct {
  			__u64 hardware_exit_reason;
  		} hw;
  
  If exit_reason is KVM_EXIT_UNKNOWN, the vcpu has exited due to unknown
  reasons.  Further architecture-specific information is available in
  hardware_exit_reason.
  
  		/* KVM_EXIT_FAIL_ENTRY */
  		struct {
  			__u64 hardware_entry_failure_reason;
  		} fail_entry;
  
  If exit_reason is KVM_EXIT_FAIL_ENTRY, the vcpu could not be run due
  to unknown reasons.  Further architecture-specific information is
  available in hardware_entry_failure_reason.
  
  		/* KVM_EXIT_EXCEPTION */
  		struct {
  			__u32 exception;
  			__u32 error_code;
  		} ex;
  
  Unused.
  
  		/* KVM_EXIT_IO */
  		struct {
  #define KVM_EXIT_IO_IN  0
  #define KVM_EXIT_IO_OUT 1
  			__u8 direction;
  			__u8 size; /* bytes */
  			__u16 port;
  			__u32 count;
  			__u64 data_offset; /* relative to kvm_run start */
  		} io;
  
  If exit_reason is KVM_EXIT_IO, then the vcpu has
  executed a port I/O instruction which could not be satisfied by kvm.
  data_offset describes where the data is located (KVM_EXIT_IO_OUT) or
  where kvm expects application code to place the data for the next
  KVM_RUN invocation (KVM_EXIT_IO_IN).  Data format is a packed array.
  
  		struct {
  			struct kvm_debug_exit_arch arch;
  		} debug;
  
  Unused.
  
  		/* KVM_EXIT_MMIO */
  		struct {
  			__u64 phys_addr;
  			__u8  data[8];
  			__u32 len;
  			__u8  is_write;
  		} mmio;
  
  If exit_reason is KVM_EXIT_MMIO, then the vcpu has
  executed a memory-mapped I/O instruction which could not be satisfied
  by kvm.  The 'data' member contains the written data if 'is_write' is
  true, and should be filled by application code otherwise.
  
  NOTE: For KVM_EXIT_IO, KVM_EXIT_MMIO, KVM_EXIT_OSI, KVM_EXIT_DCR,
        KVM_EXIT_PAPR and KVM_EXIT_EPR the corresponding
  operations are complete (and guest state is consistent) only after userspace
  has re-entered the kernel with KVM_RUN.  The kernel side will first finish
  incomplete operations and then check for pending signals.  Userspace
  can re-enter the guest with an unmasked signal pending to complete
  pending operations.
  
  		/* KVM_EXIT_HYPERCALL */
  		struct {
  			__u64 nr;
  			__u64 args[6];
  			__u64 ret;
  			__u32 longmode;
  			__u32 pad;
  		} hypercall;
  
  Unused.  This was once used for 'hypercall to userspace'.  To implement
  such functionality, use KVM_EXIT_IO (x86) or KVM_EXIT_MMIO (all except s390).
  Note KVM_EXIT_IO is significantly faster than KVM_EXIT_MMIO.
  
  		/* KVM_EXIT_TPR_ACCESS */
  		struct {
  			__u64 rip;
  			__u32 is_write;
  			__u32 pad;
  		} tpr_access;
  
  To be documented (KVM_TPR_ACCESS_REPORTING).
  
  		/* KVM_EXIT_S390_SIEIC */
  		struct {
  			__u8 icptcode;
  			__u64 mask; /* psw upper half */
  			__u64 addr; /* psw lower half */
  			__u16 ipa;
  			__u32 ipb;
  		} s390_sieic;
  
  s390 specific.
  
  		/* KVM_EXIT_S390_RESET */
  #define KVM_S390_RESET_POR       1
  #define KVM_S390_RESET_CLEAR     2
  #define KVM_S390_RESET_SUBSYSTEM 4
  #define KVM_S390_RESET_CPU_INIT  8
  #define KVM_S390_RESET_IPL       16
  		__u64 s390_reset_flags;
  
  s390 specific.
  
  		/* KVM_EXIT_S390_UCONTROL */
  		struct {
  			__u64 trans_exc_code;
  			__u32 pgm_code;
  		} s390_ucontrol;
  
  s390 specific. A page fault has occurred for a user controlled virtual
  machine (KVM_VM_S390_UNCONTROL) on it's host page table that cannot be
  resolved by the kernel.
  The program code and the translation exception code that were placed
  in the cpu's lowcore are presented here as defined by the z Architecture
  Principles of Operation Book in the Chapter for Dynamic Address Translation
  (DAT)
  
  		/* KVM_EXIT_DCR */
  		struct {
  			__u32 dcrn;
  			__u32 data;
  			__u8  is_write;
  		} dcr;
  
  powerpc specific.
  
  		/* KVM_EXIT_OSI */
  		struct {
  			__u64 gprs[32];
  		} osi;
  
  MOL uses a special hypercall interface it calls 'OSI'. To enable it, we catch
  hypercalls and exit with this exit struct that contains all the guest gprs.
  
  If exit_reason is KVM_EXIT_OSI, then the vcpu has triggered such a hypercall.
  Userspace can now handle the hypercall and when it's done modify the gprs as
  necessary. Upon guest entry all guest GPRs will then be replaced by the values
  in this struct.
  
  		/* KVM_EXIT_PAPR_HCALL */
  		struct {
  			__u64 nr;
  			__u64 ret;
  			__u64 args[9];
  		} papr_hcall;
  
  This is used on 64-bit PowerPC when emulating a pSeries partition,
  e.g. with the 'pseries' machine type in qemu.  It occurs when the
  guest does a hypercall using the 'sc 1' instruction.  The 'nr' field
  contains the hypercall number (from the guest R3), and 'args' contains
  the arguments (from the guest R4 - R12).  Userspace should put the
  return code in 'ret' and any extra returned values in args[].
  The possible hypercalls are defined in the Power Architecture Platform
  Requirements (PAPR) document available from www.power.org (free
  developer registration required to access it).
  
  		/* KVM_EXIT_S390_TSCH */
  		struct {
  			__u16 subchannel_id;
  			__u16 subchannel_nr;
  			__u32 io_int_parm;
  			__u32 io_int_word;
  			__u32 ipb;
  			__u8 dequeued;
  		} s390_tsch;
  
  s390 specific. This exit occurs when KVM_CAP_S390_CSS_SUPPORT has been enabled
  and TEST SUBCHANNEL was intercepted. If dequeued is set, a pending I/O
  interrupt for the target subchannel has been dequeued and subchannel_id,
  subchannel_nr, io_int_parm and io_int_word contain the parameters for that
  interrupt. ipb is needed for instruction parameter decoding.
  
  		/* KVM_EXIT_EPR */
  		struct {
  			__u32 epr;
  		} epr;
  
  On FSL BookE PowerPC chips, the interrupt controller has a fast patch
  interrupt acknowledge path to the core. When the core successfully
  delivers an interrupt, it automatically populates the EPR register with
  the interrupt vector number and acknowledges the interrupt inside
  the interrupt controller.
  
  In case the interrupt controller lives in user space, we need to do
  the interrupt acknowledge cycle through it to fetch the next to be
  delivered interrupt vector using this exit.
  
  It gets triggered whenever both KVM_CAP_PPC_EPR are enabled and an
  external interrupt has just been delivered into the guest. User space
  should put the acknowledged interrupt vector into the 'epr' field.
  
  		/* Fix the size of the union. */
  		char padding[256];
  	};
  
  	/*
  	 * shared registers between kvm and userspace.
  	 * kvm_valid_regs specifies the register classes set by the host
  	 * kvm_dirty_regs specified the register classes dirtied by userspace
  	 * struct kvm_sync_regs is architecture specific, as well as the
  	 * bits for kvm_valid_regs and kvm_dirty_regs
  	 */
  	__u64 kvm_valid_regs;
  	__u64 kvm_dirty_regs;
  	union {
  		struct kvm_sync_regs regs;
  		char padding[1024];
  	} s;
  
  If KVM_CAP_SYNC_REGS is defined, these fields allow userspace to access
  certain guest registers without having to call SET/GET_*REGS. Thus we can
  avoid some system call overhead if userspace has to handle the exit.
  Userspace can query the validity of the structure by checking
  kvm_valid_regs for specific bits. These bits are architecture specific
  and usually define the validity of a groups of registers. (e.g. one bit
   for general purpose registers)
  
  };
  
  
  4.81 KVM_GET_EMULATED_CPUID
  
  Capability: KVM_CAP_EXT_EMUL_CPUID
  Architectures: x86
  Type: system ioctl
  Parameters: struct kvm_cpuid2 (in/out)
  Returns: 0 on success, -1 on error
  
  struct kvm_cpuid2 {
  	__u32 nent;
  	__u32 flags;
  	struct kvm_cpuid_entry2 entries[0];
  };
  
  The member 'flags' is used for passing flags from userspace.
  
  #define KVM_CPUID_FLAG_SIGNIFCANT_INDEX		BIT(0)
  #define KVM_CPUID_FLAG_STATEFUL_FUNC		BIT(1)
  #define KVM_CPUID_FLAG_STATE_READ_NEXT		BIT(2)
  
  struct kvm_cpuid_entry2 {
  	__u32 function;
  	__u32 index;
  	__u32 flags;
  	__u32 eax;
  	__u32 ebx;
  	__u32 ecx;
  	__u32 edx;
  	__u32 padding[3];
  };
  
  This ioctl returns x86 cpuid features which are emulated by
  kvm.Userspace can use the information returned by this ioctl to query
  which features are emulated by kvm instead of being present natively.
  
  Userspace invokes KVM_GET_EMULATED_CPUID by passing a kvm_cpuid2
  structure with the 'nent' field indicating the number of entries in
  the variable-size array 'entries'. If the number of entries is too low
  to describe the cpu capabilities, an error (E2BIG) is returned. If the
  number is too high, the 'nent' field is adjusted and an error (ENOMEM)
  is returned. If the number is just right, the 'nent' field is adjusted
  to the number of valid entries in the 'entries' array, which is then
  filled.
  
  The entries returned are the set CPUID bits of the respective features
  which kvm emulates, as returned by the CPUID instruction, with unknown
  or unsupported feature bits cleared.
  
  Features like x2apic, for example, may not be present in the host cpu
  but are exposed by kvm in KVM_GET_SUPPORTED_CPUID because they can be
  emulated efficiently and thus not included here.
  
  The fields in each entry are defined as follows:
  
    function: the eax value used to obtain the entry
    index: the ecx value used to obtain the entry (for entries that are
           affected by ecx)
    flags: an OR of zero or more of the following:
          KVM_CPUID_FLAG_SIGNIFCANT_INDEX:
             if the index field is valid
          KVM_CPUID_FLAG_STATEFUL_FUNC:
             if cpuid for this function returns different values for successive
             invocations; there will be several entries with the same function,
             all with this flag set
          KVM_CPUID_FLAG_STATE_READ_NEXT:
             for KVM_CPUID_FLAG_STATEFUL_FUNC entries, set if this entry is
             the first entry to be read by a cpu
     eax, ebx, ecx, edx: the values returned by the cpuid instruction for
           this function/index combination
  
  
  6. Capabilities that can be enabled
  -----------------------------------
  
  There are certain capabilities that change the behavior of the virtual CPU when
  enabled. To enable them, please see section 4.37. Below you can find a list of
  capabilities and what their effect on the vCPU is when enabling them.
  
  The following information is provided along with the description:
  
    Architectures: which instruction set architectures provide this ioctl.
        x86 includes both i386 and x86_64.
  
    Parameters: what parameters are accepted by the capability.
  
    Returns: the return value.  General error numbers (EBADF, ENOMEM, EINVAL)
        are not detailed, but errors with specific meanings are.
  
  
  6.1 KVM_CAP_PPC_OSI
  
  Architectures: ppc
  Parameters: none
  Returns: 0 on success; -1 on error
  
  This capability enables interception of OSI hypercalls that otherwise would
  be treated as normal system calls to be injected into the guest. OSI hypercalls
  were invented by Mac-on-Linux to have a standardized communication mechanism
  between the guest and the host.
  
  When this capability is enabled, KVM_EXIT_OSI can occur.
  
  
  6.2 KVM_CAP_PPC_PAPR
  
  Architectures: ppc
  Parameters: none
  Returns: 0 on success; -1 on error
  
  This capability enables interception of PAPR hypercalls. PAPR hypercalls are
  done using the hypercall instruction "sc 1".
  
  It also sets the guest privilege level to "supervisor" mode. Usually the guest
  runs in "hypervisor" privilege mode with a few missing features.
  
  In addition to the above, it changes the semantics of SDR1. In this mode, the
  HTAB address part of SDR1 contains an HVA instead of a GPA, as PAPR keeps the
  HTAB invisible to the guest.
  
  When this capability is enabled, KVM_EXIT_PAPR_HCALL can occur.
  
  
  6.3 KVM_CAP_SW_TLB
  
  Architectures: ppc
  Parameters: args[0] is the address of a struct kvm_config_tlb
  Returns: 0 on success; -1 on error
  
  struct kvm_config_tlb {
  	__u64 params;
  	__u64 array;
  	__u32 mmu_type;
  	__u32 array_len;
  };
  
  Configures the virtual CPU's TLB array, establishing a shared memory area
  between userspace and KVM.  The "params" and "array" fields are userspace
  addresses of mmu-type-specific data structures.  The "array_len" field is an
  safety mechanism, and should be set to the size in bytes of the memory that
  userspace has reserved for the array.  It must be at least the size dictated
  by "mmu_type" and "params".
  
  While KVM_RUN is active, the shared region is under control of KVM.  Its
  contents are undefined, and any modification by userspace results in
  boundedly undefined behavior.
  
  On return from KVM_RUN, the shared region will reflect the current state of
  the guest's TLB.  If userspace makes any changes, it must call KVM_DIRTY_TLB
  to tell KVM which entries have been changed, prior to calling KVM_RUN again
  on this vcpu.
  
  For mmu types KVM_MMU_FSL_BOOKE_NOHV and KVM_MMU_FSL_BOOKE_HV:
   - The "params" field is of type "struct kvm_book3e_206_tlb_params".
   - The "array" field points to an array of type "struct
     kvm_book3e_206_tlb_entry".
   - The array consists of all entries in the first TLB, followed by all
     entries in the second TLB.
   - Within a TLB, entries are ordered first by increasing set number.  Within a
     set, entries are ordered by way (increasing ESEL).
   - The hash for determining set number in TLB0 is: (MAS2 >> 12) & (num_sets - 1)
     where "num_sets" is the tlb_sizes[] value divided by the tlb_ways[] value.
   - The tsize field of mas1 shall be set to 4K on TLB0, even though the
     hardware ignores this value for TLB0.
  
  6.4 KVM_CAP_S390_CSS_SUPPORT
  
  Architectures: s390
  Parameters: none
  Returns: 0 on success; -1 on error
  
  This capability enables support for handling of channel I/O instructions.
  
  TEST PENDING INTERRUPTION and the interrupt portion of TEST SUBCHANNEL are
  handled in-kernel, while the other I/O instructions are passed to userspace.
  
  When this capability is enabled, KVM_EXIT_S390_TSCH will occur on TEST
  SUBCHANNEL intercepts.
  
  6.5 KVM_CAP_PPC_EPR
  
  Architectures: ppc
  Parameters: args[0] defines whether the proxy facility is active
  Returns: 0 on success; -1 on error
  
  This capability enables or disables the delivery of interrupts through the
  external proxy facility.
  
  When enabled (args[0] != 0), every time the guest gets an external interrupt
  delivered, it automatically exits into user space with a KVM_EXIT_EPR exit
  to receive the topmost interrupt vector.
  
  When disabled (args[0] == 0), behavior is as if this facility is unsupported.
  
  When this capability is enabled, KVM_EXIT_EPR can occur.
  
  6.6 KVM_CAP_IRQ_MPIC
  
  Architectures: ppc
  Parameters: args[0] is the MPIC device fd
              args[1] is the MPIC CPU number for this vcpu
  
  This capability connects the vcpu to an in-kernel MPIC device.
  
  6.7 KVM_CAP_IRQ_XICS
  
  Architectures: ppc
  Parameters: args[0] is the XICS device fd
              args[1] is the XICS CPU number (server ID) for this vcpu
  
  This capability connects the vcpu to an in-kernel XICS device.