]> Git Repo - qemu.git/blob - qapi-schema.json
qapi-schema: Collect net device stuff in qapi/net.json
[qemu.git] / qapi-schema.json
1 # -*- Mode: Python -*-
2 ##
3 # = Introduction
4 #
5 # This document describes all commands currently supported by QMP.
6 #
7 # Most of the time their usage is exactly the same as in the user Monitor, this
8 # means that any other document which also describe commands (the manpage,
9 # QEMU's manual, etc) can and should be consulted.
10 #
11 # QMP has two types of commands: regular and query commands. Regular commands
12 # usually change the Virtual Machine's state someway, while query commands just
13 # return information. The sections below are divided accordingly.
14 #
15 # It's important to observe that all communication examples are formatted in
16 # a reader-friendly way, so that they're easier to understand. However, in real
17 # protocol usage, they're emitted as a single line.
18 #
19 # Also, the following notation is used to denote data flow:
20 #
21 # Example:
22 #
23 # | -> data issued by the Client
24 # | <- Server data response
25 #
26 # Please, refer to the QMP specification (docs/interop/qmp-spec.txt) for
27 # detailed information on the Server command and response formats.
28 #
29 # = Stability Considerations
30 #
31 # The current QMP command set (described in this file) may be useful for a
32 # number of use cases, however it's limited and several commands have bad
33 # defined semantics, specially with regard to command completion.
34 #
35 # These problems are going to be solved incrementally in the next QEMU releases
36 # and we're going to establish a deprecation policy for badly defined commands.
37 #
38 # If you're planning to adopt QMP, please observe the following:
39 #
40 #     1. The deprecation policy will take effect and be documented soon, please
41 #        check the documentation of each used command as soon as a new release of
42 #        QEMU is available
43 #
44 #     2. DO NOT rely on anything which is not explicit documented
45 #
46 #     3. Errors, in special, are not documented. Applications should NOT check
47 #        for specific errors classes or data (it's strongly recommended to only
48 #        check for the "error" key)
49 #
50 ##
51
52 { 'pragma': { 'doc-required': true } }
53
54 # Whitelists to permit QAPI rule violations; think twice before you
55 # add to them!
56 { 'pragma': {
57     # Commands allowed to return a non-dictionary:
58     'returns-whitelist': [
59         'human-monitor-command',
60         'qom-get',
61         'query-migrate-cache-size',
62         'query-tpm-models',
63         'query-tpm-types',
64         'ringbuf-read' ],
65     'name-case-whitelist': [
66         'ACPISlotType',         # DIMM, visible through query-acpi-ospm-status
67         'CpuInfoMIPS',          # PC, visible through query-cpu
68         'CpuInfoTricore',       # PC, visible through query-cpu
69         'QapiErrorClass',       # all members, visible through errors
70         'UuidInfo',             # UUID, visible through query-uuid
71         'X86CPURegister32',     # all members, visible indirectly through qom-get
72         'q_obj_CpuInfo-base'    # CPU, visible through query-cpu
73     ] } }
74
75 # Documentation generated with qapi2texi.py is in source order, with
76 # included sub-schemas inserted at the first include directive
77 # (subsequent include directives have no effect).  To get a sane and
78 # stable order, it's best to include each sub-schema just once, or
79 # include it first in qapi-schema.json.
80
81 { 'include': 'qapi/common.json' }
82 { 'include': 'qapi/sockets.json' }
83 { 'include': 'qapi/run-state.json' }
84 { 'include': 'qapi/crypto.json' }
85 { 'include': 'qapi/block.json' }
86 { 'include': 'qapi/char.json' }
87 { 'include': 'qapi/net.json' }
88 { 'include': 'qapi/rocker.json' }
89 { 'include': 'qapi/event.json' }
90 { 'include': 'qapi/trace.json' }
91 { 'include': 'qapi/introspect.json' }
92
93 ##
94 # = QMP commands
95 ##
96
97 ##
98 # @qmp_capabilities:
99 #
100 # Enable QMP capabilities.
101 #
102 # Arguments: None.
103 #
104 # Example:
105 #
106 # -> { "execute": "qmp_capabilities" }
107 # <- { "return": {} }
108 #
109 # Notes: This command is valid exactly when first connecting: it must be
110 # issued before any other command will be accepted, and will fail once the
111 # monitor is accepting other commands. (see qemu docs/interop/qmp-spec.txt)
112 #
113 # Since: 0.13
114 #
115 ##
116 { 'command': 'qmp_capabilities' }
117
118 ##
119 # @StrOrNull:
120 #
121 # This is a string value or the explicit lack of a string (null
122 # pointer in C).  Intended for cases when 'optional absent' already
123 # has a different meaning.
124 #
125 # @s: the string value
126 # @n: no string value
127 #
128 # Since: 2.10
129 ##
130 { 'alternate': 'StrOrNull',
131   'data': { 's': 'str',
132             'n': 'null' } }
133
134 ##
135 # @LostTickPolicy:
136 #
137 # Policy for handling lost ticks in timer devices.
138 #
139 # @discard: throw away the missed tick(s) and continue with future injection
140 #           normally.  Guest time may be delayed, unless the OS has explicit
141 #           handling of lost ticks
142 #
143 # @delay: continue to deliver ticks at the normal rate.  Guest time will be
144 #         delayed due to the late tick
145 #
146 # @merge: merge the missed tick(s) into one tick and inject.  Guest time
147 #         may be delayed, depending on how the OS reacts to the merging
148 #         of ticks
149 #
150 # @slew: deliver ticks at a higher rate to catch up with the missed tick. The
151 #        guest time should not be delayed once catchup is complete.
152 #
153 # Since: 2.0
154 ##
155 { 'enum': 'LostTickPolicy',
156   'data': ['discard', 'delay', 'merge', 'slew' ] }
157
158 ##
159 # @add_client:
160 #
161 # Allow client connections for VNC, Spice and socket based
162 # character devices to be passed in to QEMU via SCM_RIGHTS.
163 #
164 # @protocol: protocol name. Valid names are "vnc", "spice" or the
165 #            name of a character device (eg. from -chardev id=XXXX)
166 #
167 # @fdname: file descriptor name previously passed via 'getfd' command
168 #
169 # @skipauth: whether to skip authentication. Only applies
170 #            to "vnc" and "spice" protocols
171 #
172 # @tls: whether to perform TLS. Only applies to the "spice"
173 #       protocol
174 #
175 # Returns: nothing on success.
176 #
177 # Since: 0.14.0
178 #
179 # Example:
180 #
181 # -> { "execute": "add_client", "arguments": { "protocol": "vnc",
182 #                                              "fdname": "myclient" } }
183 # <- { "return": {} }
184 #
185 ##
186 { 'command': 'add_client',
187   'data': { 'protocol': 'str', 'fdname': 'str', '*skipauth': 'bool',
188             '*tls': 'bool' } }
189
190 ##
191 # @NameInfo:
192 #
193 # Guest name information.
194 #
195 # @name: The name of the guest
196 #
197 # Since: 0.14.0
198 ##
199 { 'struct': 'NameInfo', 'data': {'*name': 'str'} }
200
201 ##
202 # @query-name:
203 #
204 # Return the name information of a guest.
205 #
206 # Returns: @NameInfo of the guest
207 #
208 # Since: 0.14.0
209 #
210 # Example:
211 #
212 # -> { "execute": "query-name" }
213 # <- { "return": { "name": "qemu-name" } }
214 #
215 ##
216 { 'command': 'query-name', 'returns': 'NameInfo' }
217
218 ##
219 # @KvmInfo:
220 #
221 # Information about support for KVM acceleration
222 #
223 # @enabled: true if KVM acceleration is active
224 #
225 # @present: true if KVM acceleration is built into this executable
226 #
227 # Since: 0.14.0
228 ##
229 { 'struct': 'KvmInfo', 'data': {'enabled': 'bool', 'present': 'bool'} }
230
231 ##
232 # @query-kvm:
233 #
234 # Returns information about KVM acceleration
235 #
236 # Returns: @KvmInfo
237 #
238 # Since: 0.14.0
239 #
240 # Example:
241 #
242 # -> { "execute": "query-kvm" }
243 # <- { "return": { "enabled": true, "present": true } }
244 #
245 ##
246 { 'command': 'query-kvm', 'returns': 'KvmInfo' }
247
248 ##
249 # @UuidInfo:
250 #
251 # Guest UUID information (Universally Unique Identifier).
252 #
253 # @UUID: the UUID of the guest
254 #
255 # Since: 0.14.0
256 #
257 # Notes: If no UUID was specified for the guest, a null UUID is returned.
258 ##
259 { 'struct': 'UuidInfo', 'data': {'UUID': 'str'} }
260
261 ##
262 # @query-uuid:
263 #
264 # Query the guest UUID information.
265 #
266 # Returns: The @UuidInfo for the guest
267 #
268 # Since: 0.14.0
269 #
270 # Example:
271 #
272 # -> { "execute": "query-uuid" }
273 # <- { "return": { "UUID": "550e8400-e29b-41d4-a716-446655440000" } }
274 #
275 ##
276 { 'command': 'query-uuid', 'returns': 'UuidInfo' }
277
278 ##
279 # @EventInfo:
280 #
281 # Information about a QMP event
282 #
283 # @name: The event name
284 #
285 # Since: 1.2.0
286 ##
287 { 'struct': 'EventInfo', 'data': {'name': 'str'} }
288
289 ##
290 # @query-events:
291 #
292 # Return a list of supported QMP events by this server
293 #
294 # Returns: A list of @EventInfo for all supported events
295 #
296 # Since: 1.2.0
297 #
298 # Example:
299 #
300 # -> { "execute": "query-events" }
301 # <- {
302 #      "return": [
303 #          {
304 #             "name":"SHUTDOWN"
305 #          },
306 #          {
307 #             "name":"RESET"
308 #          }
309 #       ]
310 #    }
311 #
312 # Note: This example has been shortened as the real response is too long.
313 #
314 ##
315 { 'command': 'query-events', 'returns': ['EventInfo'] }
316
317 ##
318 # @MigrationStats:
319 #
320 # Detailed migration status.
321 #
322 # @transferred: amount of bytes already transferred to the target VM
323 #
324 # @remaining: amount of bytes remaining to be transferred to the target VM
325 #
326 # @total: total amount of bytes involved in the migration process
327 #
328 # @duplicate: number of duplicate (zero) pages (since 1.2)
329 #
330 # @skipped: number of skipped zero pages (since 1.5)
331 #
332 # @normal: number of normal pages (since 1.2)
333 #
334 # @normal-bytes: number of normal bytes sent (since 1.2)
335 #
336 # @dirty-pages-rate: number of pages dirtied by second by the
337 #        guest (since 1.3)
338 #
339 # @mbps: throughput in megabits/sec. (since 1.6)
340 #
341 # @dirty-sync-count: number of times that dirty ram was synchronized (since 2.1)
342 #
343 # @postcopy-requests: The number of page requests received from the destination
344 #        (since 2.7)
345 #
346 # @page-size: The number of bytes per page for the various page-based
347 #        statistics (since 2.10)
348 #
349 # Since: 0.14.0
350 ##
351 { 'struct': 'MigrationStats',
352   'data': {'transferred': 'int', 'remaining': 'int', 'total': 'int' ,
353            'duplicate': 'int', 'skipped': 'int', 'normal': 'int',
354            'normal-bytes': 'int', 'dirty-pages-rate' : 'int',
355            'mbps' : 'number', 'dirty-sync-count' : 'int',
356            'postcopy-requests' : 'int', 'page-size' : 'int' } }
357
358 ##
359 # @XBZRLECacheStats:
360 #
361 # Detailed XBZRLE migration cache statistics
362 #
363 # @cache-size: XBZRLE cache size
364 #
365 # @bytes: amount of bytes already transferred to the target VM
366 #
367 # @pages: amount of pages transferred to the target VM
368 #
369 # @cache-miss: number of cache miss
370 #
371 # @cache-miss-rate: rate of cache miss (since 2.1)
372 #
373 # @overflow: number of overflows
374 #
375 # Since: 1.2
376 ##
377 { 'struct': 'XBZRLECacheStats',
378   'data': {'cache-size': 'int', 'bytes': 'int', 'pages': 'int',
379            'cache-miss': 'int', 'cache-miss-rate': 'number',
380            'overflow': 'int' } }
381
382 ##
383 # @MigrationStatus:
384 #
385 # An enumeration of migration status.
386 #
387 # @none: no migration has ever happened.
388 #
389 # @setup: migration process has been initiated.
390 #
391 # @cancelling: in the process of cancelling migration.
392 #
393 # @cancelled: cancelling migration is finished.
394 #
395 # @active: in the process of doing migration.
396 #
397 # @postcopy-active: like active, but now in postcopy mode. (since 2.5)
398 #
399 # @completed: migration is finished.
400 #
401 # @failed: some error occurred during migration process.
402 #
403 # @colo: VM is in the process of fault tolerance, VM can not get into this
404 #        state unless colo capability is enabled for migration. (since 2.8)
405 #
406 # Since: 2.3
407 #
408 ##
409 { 'enum': 'MigrationStatus',
410   'data': [ 'none', 'setup', 'cancelling', 'cancelled',
411             'active', 'postcopy-active', 'completed', 'failed', 'colo' ] }
412
413 ##
414 # @MigrationInfo:
415 #
416 # Information about current migration process.
417 #
418 # @status: @MigrationStatus describing the current migration status.
419 #          If this field is not returned, no migration process
420 #          has been initiated
421 #
422 # @ram: @MigrationStats containing detailed migration
423 #       status, only returned if status is 'active' or
424 #       'completed'(since 1.2)
425 #
426 # @disk: @MigrationStats containing detailed disk migration
427 #        status, only returned if status is 'active' and it is a block
428 #        migration
429 #
430 # @xbzrle-cache: @XBZRLECacheStats containing detailed XBZRLE
431 #                migration statistics, only returned if XBZRLE feature is on and
432 #                status is 'active' or 'completed' (since 1.2)
433 #
434 # @total-time: total amount of milliseconds since migration started.
435 #        If migration has ended, it returns the total migration
436 #        time. (since 1.2)
437 #
438 # @downtime: only present when migration finishes correctly
439 #        total downtime in milliseconds for the guest.
440 #        (since 1.3)
441 #
442 # @expected-downtime: only present while migration is active
443 #        expected downtime in milliseconds for the guest in last walk
444 #        of the dirty bitmap. (since 1.3)
445 #
446 # @setup-time: amount of setup time in milliseconds _before_ the
447 #        iterations begin but _after_ the QMP command is issued. This is designed
448 #        to provide an accounting of any activities (such as RDMA pinning) which
449 #        may be expensive, but do not actually occur during the iterative
450 #        migration rounds themselves. (since 1.6)
451 #
452 # @cpu-throttle-percentage: percentage of time guest cpus are being
453 #        throttled during auto-converge. This is only present when auto-converge
454 #        has started throttling guest cpus. (Since 2.7)
455 #
456 # @error-desc: the human readable error description string, when
457 #              @status is 'failed'. Clients should not attempt to parse the
458 #              error strings. (Since 2.7)
459 #
460 # Since: 0.14.0
461 ##
462 { 'struct': 'MigrationInfo',
463   'data': {'*status': 'MigrationStatus', '*ram': 'MigrationStats',
464            '*disk': 'MigrationStats',
465            '*xbzrle-cache': 'XBZRLECacheStats',
466            '*total-time': 'int',
467            '*expected-downtime': 'int',
468            '*downtime': 'int',
469            '*setup-time': 'int',
470            '*cpu-throttle-percentage': 'int',
471            '*error-desc': 'str'} }
472
473 ##
474 # @query-migrate:
475 #
476 # Returns information about current migration process. If migration
477 # is active there will be another json-object with RAM migration
478 # status and if block migration is active another one with block
479 # migration status.
480 #
481 # Returns: @MigrationInfo
482 #
483 # Since: 0.14.0
484 #
485 # Example:
486 #
487 # 1. Before the first migration
488 #
489 # -> { "execute": "query-migrate" }
490 # <- { "return": {} }
491 #
492 # 2. Migration is done and has succeeded
493 #
494 # -> { "execute": "query-migrate" }
495 # <- { "return": {
496 #         "status": "completed",
497 #         "ram":{
498 #           "transferred":123,
499 #           "remaining":123,
500 #           "total":246,
501 #           "total-time":12345,
502 #           "setup-time":12345,
503 #           "downtime":12345,
504 #           "duplicate":123,
505 #           "normal":123,
506 #           "normal-bytes":123456,
507 #           "dirty-sync-count":15
508 #         }
509 #      }
510 #    }
511 #
512 # 3. Migration is done and has failed
513 #
514 # -> { "execute": "query-migrate" }
515 # <- { "return": { "status": "failed" } }
516 #
517 # 4. Migration is being performed and is not a block migration:
518 #
519 # -> { "execute": "query-migrate" }
520 # <- {
521 #       "return":{
522 #          "status":"active",
523 #          "ram":{
524 #             "transferred":123,
525 #             "remaining":123,
526 #             "total":246,
527 #             "total-time":12345,
528 #             "setup-time":12345,
529 #             "expected-downtime":12345,
530 #             "duplicate":123,
531 #             "normal":123,
532 #             "normal-bytes":123456,
533 #             "dirty-sync-count":15
534 #          }
535 #       }
536 #    }
537 #
538 # 5. Migration is being performed and is a block migration:
539 #
540 # -> { "execute": "query-migrate" }
541 # <- {
542 #       "return":{
543 #          "status":"active",
544 #          "ram":{
545 #             "total":1057024,
546 #             "remaining":1053304,
547 #             "transferred":3720,
548 #             "total-time":12345,
549 #             "setup-time":12345,
550 #             "expected-downtime":12345,
551 #             "duplicate":123,
552 #             "normal":123,
553 #             "normal-bytes":123456,
554 #             "dirty-sync-count":15
555 #          },
556 #          "disk":{
557 #             "total":20971520,
558 #             "remaining":20880384,
559 #             "transferred":91136
560 #          }
561 #       }
562 #    }
563 #
564 # 6. Migration is being performed and XBZRLE is active:
565 #
566 # -> { "execute": "query-migrate" }
567 # <- {
568 #       "return":{
569 #          "status":"active",
570 #          "capabilities" : [ { "capability": "xbzrle", "state" : true } ],
571 #          "ram":{
572 #             "total":1057024,
573 #             "remaining":1053304,
574 #             "transferred":3720,
575 #             "total-time":12345,
576 #             "setup-time":12345,
577 #             "expected-downtime":12345,
578 #             "duplicate":10,
579 #             "normal":3333,
580 #             "normal-bytes":3412992,
581 #             "dirty-sync-count":15
582 #          },
583 #          "xbzrle-cache":{
584 #             "cache-size":67108864,
585 #             "bytes":20971520,
586 #             "pages":2444343,
587 #             "cache-miss":2244,
588 #             "cache-miss-rate":0.123,
589 #             "overflow":34434
590 #          }
591 #       }
592 #    }
593 #
594 ##
595 { 'command': 'query-migrate', 'returns': 'MigrationInfo' }
596
597 ##
598 # @MigrationCapability:
599 #
600 # Migration capabilities enumeration
601 #
602 # @xbzrle: Migration supports xbzrle (Xor Based Zero Run Length Encoding).
603 #          This feature allows us to minimize migration traffic for certain work
604 #          loads, by sending compressed difference of the pages
605 #
606 # @rdma-pin-all: Controls whether or not the entire VM memory footprint is
607 #          mlock()'d on demand or all at once. Refer to docs/rdma.txt for usage.
608 #          Disabled by default. (since 2.0)
609 #
610 # @zero-blocks: During storage migration encode blocks of zeroes efficiently. This
611 #          essentially saves 1MB of zeroes per block on the wire. Enabling requires
612 #          source and target VM to support this feature. To enable it is sufficient
613 #          to enable the capability on the source VM. The feature is disabled by
614 #          default. (since 1.6)
615 #
616 # @compress: Use multiple compression threads to accelerate live migration.
617 #          This feature can help to reduce the migration traffic, by sending
618 #          compressed pages. Please note that if compress and xbzrle are both
619 #          on, compress only takes effect in the ram bulk stage, after that,
620 #          it will be disabled and only xbzrle takes effect, this can help to
621 #          minimize migration traffic. The feature is disabled by default.
622 #          (since 2.4 )
623 #
624 # @events: generate events for each migration state change
625 #          (since 2.4 )
626 #
627 # @auto-converge: If enabled, QEMU will automatically throttle down the guest
628 #          to speed up convergence of RAM migration. (since 1.6)
629 #
630 # @postcopy-ram: Start executing on the migration target before all of RAM has
631 #          been migrated, pulling the remaining pages along as needed. NOTE: If
632 #          the migration fails during postcopy the VM will fail.  (since 2.6)
633 #
634 # @x-colo: If enabled, migration will never end, and the state of the VM on the
635 #        primary side will be migrated continuously to the VM on secondary
636 #        side, this process is called COarse-Grain LOck Stepping (COLO) for
637 #        Non-stop Service. (since 2.8)
638 #
639 # @release-ram: if enabled, qemu will free the migrated ram pages on the source
640 #        during postcopy-ram migration. (since 2.9)
641 #
642 # @block: If enabled, QEMU will also migrate the contents of all block
643 #          devices.  Default is disabled.  A possible alternative uses
644 #          mirror jobs to a builtin NBD server on the destination, which
645 #          offers more flexibility.
646 #          (Since 2.10)
647 #
648 # @return-path: If enabled, migration will use the return path even
649 #               for precopy. (since 2.10)
650 #
651 # Since: 1.2
652 ##
653 { 'enum': 'MigrationCapability',
654   'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks',
655            'compress', 'events', 'postcopy-ram', 'x-colo', 'release-ram',
656            'block', 'return-path' ] }
657
658 ##
659 # @MigrationCapabilityStatus:
660 #
661 # Migration capability information
662 #
663 # @capability: capability enum
664 #
665 # @state: capability state bool
666 #
667 # Since: 1.2
668 ##
669 { 'struct': 'MigrationCapabilityStatus',
670   'data': { 'capability' : 'MigrationCapability', 'state' : 'bool' } }
671
672 ##
673 # @migrate-set-capabilities:
674 #
675 # Enable/Disable the following migration capabilities (like xbzrle)
676 #
677 # @capabilities: json array of capability modifications to make
678 #
679 # Since: 1.2
680 #
681 # Example:
682 #
683 # -> { "execute": "migrate-set-capabilities" , "arguments":
684 #      { "capabilities": [ { "capability": "xbzrle", "state": true } ] } }
685 #
686 ##
687 { 'command': 'migrate-set-capabilities',
688   'data': { 'capabilities': ['MigrationCapabilityStatus'] } }
689
690 ##
691 # @query-migrate-capabilities:
692 #
693 # Returns information about the current migration capabilities status
694 #
695 # Returns: @MigrationCapabilitiesStatus
696 #
697 # Since: 1.2
698 #
699 # Example:
700 #
701 # -> { "execute": "query-migrate-capabilities" }
702 # <- { "return": [
703 #       {"state": false, "capability": "xbzrle"},
704 #       {"state": false, "capability": "rdma-pin-all"},
705 #       {"state": false, "capability": "auto-converge"},
706 #       {"state": false, "capability": "zero-blocks"},
707 #       {"state": false, "capability": "compress"},
708 #       {"state": true, "capability": "events"},
709 #       {"state": false, "capability": "postcopy-ram"},
710 #       {"state": false, "capability": "x-colo"}
711 #    ]}
712 #
713 ##
714 { 'command': 'query-migrate-capabilities', 'returns':   ['MigrationCapabilityStatus']}
715
716 ##
717 # @MigrationParameter:
718 #
719 # Migration parameters enumeration
720 #
721 # @compress-level: Set the compression level to be used in live migration,
722 #          the compression level is an integer between 0 and 9, where 0 means
723 #          no compression, 1 means the best compression speed, and 9 means best
724 #          compression ratio which will consume more CPU.
725 #
726 # @compress-threads: Set compression thread count to be used in live migration,
727 #          the compression thread count is an integer between 1 and 255.
728 #
729 # @decompress-threads: Set decompression thread count to be used in live
730 #          migration, the decompression thread count is an integer between 1
731 #          and 255. Usually, decompression is at least 4 times as fast as
732 #          compression, so set the decompress-threads to the number about 1/4
733 #          of compress-threads is adequate.
734 #
735 # @cpu-throttle-initial: Initial percentage of time guest cpus are throttled
736 #                        when migration auto-converge is activated. The
737 #                        default value is 20. (Since 2.7)
738 #
739 # @cpu-throttle-increment: throttle percentage increase each time
740 #                          auto-converge detects that migration is not making
741 #                          progress. The default value is 10. (Since 2.7)
742 #
743 # @tls-creds: ID of the 'tls-creds' object that provides credentials for
744 #             establishing a TLS connection over the migration data channel.
745 #             On the outgoing side of the migration, the credentials must
746 #             be for a 'client' endpoint, while for the incoming side the
747 #             credentials must be for a 'server' endpoint. Setting this
748 #             will enable TLS for all migrations. The default is unset,
749 #             resulting in unsecured migration at the QEMU level. (Since 2.7)
750 #
751 # @tls-hostname: hostname of the target host for the migration. This is
752 #                required when using x509 based TLS credentials and the
753 #                migration URI does not already include a hostname. For
754 #                example if using fd: or exec: based migration, the
755 #                hostname must be provided so that the server's x509
756 #                certificate identity can be validated. (Since 2.7)
757 #
758 # @max-bandwidth: to set maximum speed for migration. maximum speed in
759 #                 bytes per second. (Since 2.8)
760 #
761 # @downtime-limit: set maximum tolerated downtime for migration. maximum
762 #                  downtime in milliseconds (Since 2.8)
763 #
764 # @x-checkpoint-delay: The delay time (in ms) between two COLO checkpoints in
765 #          periodic mode. (Since 2.8)
766 #
767 # @block-incremental: Affects how much storage is migrated when the
768 #       block migration capability is enabled.  When false, the entire
769 #       storage backing chain is migrated into a flattened image at
770 #       the destination; when true, only the active qcow2 layer is
771 #       migrated and the destination must already have access to the
772 #       same backing chain as was used on the source.  (since 2.10)
773 #
774 # Since: 2.4
775 ##
776 { 'enum': 'MigrationParameter',
777   'data': ['compress-level', 'compress-threads', 'decompress-threads',
778            'cpu-throttle-initial', 'cpu-throttle-increment',
779            'tls-creds', 'tls-hostname', 'max-bandwidth',
780            'downtime-limit', 'x-checkpoint-delay', 'block-incremental' ] }
781
782 ##
783 # @MigrateSetParameters:
784 #
785 # @compress-level: compression level
786 #
787 # @compress-threads: compression thread count
788 #
789 # @decompress-threads: decompression thread count
790 #
791 # @cpu-throttle-initial: Initial percentage of time guest cpus are
792 #                        throttled when migration auto-converge is activated.
793 #                        The default value is 20. (Since 2.7)
794 #
795 # @cpu-throttle-increment: throttle percentage increase each time
796 #                          auto-converge detects that migration is not making
797 #                          progress. The default value is 10. (Since 2.7)
798 #
799 # @tls-creds: ID of the 'tls-creds' object that provides credentials
800 #             for establishing a TLS connection over the migration data
801 #             channel. On the outgoing side of the migration, the credentials
802 #             must be for a 'client' endpoint, while for the incoming side the
803 #             credentials must be for a 'server' endpoint. Setting this
804 #             to a non-empty string enables TLS for all migrations.
805 #             An empty string means that QEMU will use plain text mode for
806 #             migration, rather than TLS (Since 2.9)
807 #             Previously (since 2.7), this was reported by omitting
808 #             tls-creds instead.
809 #
810 # @tls-hostname: hostname of the target host for the migration. This
811 #                is required when using x509 based TLS credentials and the
812 #                migration URI does not already include a hostname. For
813 #                example if using fd: or exec: based migration, the
814 #                hostname must be provided so that the server's x509
815 #                certificate identity can be validated. (Since 2.7)
816 #                An empty string means that QEMU will use the hostname
817 #                associated with the migration URI, if any. (Since 2.9)
818 #                Previously (since 2.7), this was reported by omitting
819 #                tls-hostname instead.
820 #
821 # @max-bandwidth: to set maximum speed for migration. maximum speed in
822 #                 bytes per second. (Since 2.8)
823 #
824 # @downtime-limit: set maximum tolerated downtime for migration. maximum
825 #                  downtime in milliseconds (Since 2.8)
826 #
827 # @x-checkpoint-delay: the delay time between two COLO checkpoints. (Since 2.8)
828 #
829 # @block-incremental: Affects how much storage is migrated when the
830 #       block migration capability is enabled.  When false, the entire
831 #       storage backing chain is migrated into a flattened image at
832 #       the destination; when true, only the active qcow2 layer is
833 #       migrated and the destination must already have access to the
834 #       same backing chain as was used on the source.  (since 2.10)
835 #
836 # Since: 2.4
837 ##
838 # TODO either fuse back into MigrationParameters, or make
839 # MigrationParameters members mandatory
840 { 'struct': 'MigrateSetParameters',
841   'data': { '*compress-level': 'int',
842             '*compress-threads': 'int',
843             '*decompress-threads': 'int',
844             '*cpu-throttle-initial': 'int',
845             '*cpu-throttle-increment': 'int',
846             '*tls-creds': 'StrOrNull',
847             '*tls-hostname': 'StrOrNull',
848             '*max-bandwidth': 'int',
849             '*downtime-limit': 'int',
850             '*x-checkpoint-delay': 'int',
851             '*block-incremental': 'bool' } }
852
853 ##
854 # @migrate-set-parameters:
855 #
856 # Set various migration parameters.
857 #
858 # Since: 2.4
859 #
860 # Example:
861 #
862 # -> { "execute": "migrate-set-parameters" ,
863 #      "arguments": { "compress-level": 1 } }
864 #
865 ##
866 { 'command': 'migrate-set-parameters', 'boxed': true,
867   'data': 'MigrateSetParameters' }
868
869 ##
870 # @MigrationParameters:
871 #
872 # The optional members aren't actually optional.
873 #
874 # @compress-level: compression level
875 #
876 # @compress-threads: compression thread count
877 #
878 # @decompress-threads: decompression thread count
879 #
880 # @cpu-throttle-initial: Initial percentage of time guest cpus are
881 #                        throttled when migration auto-converge is activated.
882 #                        (Since 2.7)
883 #
884 # @cpu-throttle-increment: throttle percentage increase each time
885 #                          auto-converge detects that migration is not making
886 #                          progress. (Since 2.7)
887 #
888 # @tls-creds: ID of the 'tls-creds' object that provides credentials
889 #             for establishing a TLS connection over the migration data
890 #             channel. On the outgoing side of the migration, the credentials
891 #             must be for a 'client' endpoint, while for the incoming side the
892 #             credentials must be for a 'server' endpoint.
893 #             An empty string means that QEMU will use plain text mode for
894 #             migration, rather than TLS (Since 2.7)
895 #             Note: 2.8 reports this by omitting tls-creds instead.
896 #
897 # @tls-hostname: hostname of the target host for the migration. This
898 #                is required when using x509 based TLS credentials and the
899 #                migration URI does not already include a hostname. For
900 #                example if using fd: or exec: based migration, the
901 #                hostname must be provided so that the server's x509
902 #                certificate identity can be validated. (Since 2.7)
903 #                An empty string means that QEMU will use the hostname
904 #                associated with the migration URI, if any. (Since 2.9)
905 #                Note: 2.8 reports this by omitting tls-hostname instead.
906 #
907 # @max-bandwidth: to set maximum speed for migration. maximum speed in
908 #                 bytes per second. (Since 2.8)
909 #
910 # @downtime-limit: set maximum tolerated downtime for migration. maximum
911 #                  downtime in milliseconds (Since 2.8)
912 #
913 # @x-checkpoint-delay: the delay time between two COLO checkpoints. (Since 2.8)
914 #
915 # @block-incremental: Affects how much storage is migrated when the
916 #       block migration capability is enabled.  When false, the entire
917 #       storage backing chain is migrated into a flattened image at
918 #       the destination; when true, only the active qcow2 layer is
919 #       migrated and the destination must already have access to the
920 #       same backing chain as was used on the source.  (since 2.10)
921 #
922 # Since: 2.4
923 ##
924 { 'struct': 'MigrationParameters',
925   'data': { '*compress-level': 'int',
926             '*compress-threads': 'int',
927             '*decompress-threads': 'int',
928             '*cpu-throttle-initial': 'int',
929             '*cpu-throttle-increment': 'int',
930             '*tls-creds': 'str',
931             '*tls-hostname': 'str',
932             '*max-bandwidth': 'int',
933             '*downtime-limit': 'int',
934             '*x-checkpoint-delay': 'int',
935             '*block-incremental': 'bool' } }
936
937 ##
938 # @query-migrate-parameters:
939 #
940 # Returns information about the current migration parameters
941 #
942 # Returns: @MigrationParameters
943 #
944 # Since: 2.4
945 #
946 # Example:
947 #
948 # -> { "execute": "query-migrate-parameters" }
949 # <- { "return": {
950 #          "decompress-threads": 2,
951 #          "cpu-throttle-increment": 10,
952 #          "compress-threads": 8,
953 #          "compress-level": 1,
954 #          "cpu-throttle-initial": 20,
955 #          "max-bandwidth": 33554432,
956 #          "downtime-limit": 300
957 #       }
958 #    }
959 #
960 ##
961 { 'command': 'query-migrate-parameters',
962   'returns': 'MigrationParameters' }
963
964 ##
965 # @client_migrate_info:
966 #
967 # Set migration information for remote display.  This makes the server
968 # ask the client to automatically reconnect using the new parameters
969 # once migration finished successfully.  Only implemented for SPICE.
970 #
971 # @protocol:     must be "spice"
972 # @hostname:     migration target hostname
973 # @port:         spice tcp port for plaintext channels
974 # @tls-port:     spice tcp port for tls-secured channels
975 # @cert-subject: server certificate subject
976 #
977 # Since: 0.14.0
978 #
979 # Example:
980 #
981 # -> { "execute": "client_migrate_info",
982 #      "arguments": { "protocol": "spice",
983 #                     "hostname": "virt42.lab.kraxel.org",
984 #                     "port": 1234 } }
985 # <- { "return": {} }
986 #
987 ##
988 { 'command': 'client_migrate_info',
989   'data': { 'protocol': 'str', 'hostname': 'str', '*port': 'int',
990             '*tls-port': 'int', '*cert-subject': 'str' } }
991
992 ##
993 # @migrate-start-postcopy:
994 #
995 # Followup to a migration command to switch the migration to postcopy mode.
996 # The postcopy-ram capability must be set before the original migration
997 # command.
998 #
999 # Since: 2.5
1000 #
1001 # Example:
1002 #
1003 # -> { "execute": "migrate-start-postcopy" }
1004 # <- { "return": {} }
1005 #
1006 ##
1007 { 'command': 'migrate-start-postcopy' }
1008
1009 ##
1010 # @COLOMessage:
1011 #
1012 # The message transmission between Primary side and Secondary side.
1013 #
1014 # @checkpoint-ready: Secondary VM (SVM) is ready for checkpointing
1015 #
1016 # @checkpoint-request: Primary VM (PVM) tells SVM to prepare for checkpointing
1017 #
1018 # @checkpoint-reply: SVM gets PVM's checkpoint request
1019 #
1020 # @vmstate-send: VM's state will be sent by PVM.
1021 #
1022 # @vmstate-size: The total size of VMstate.
1023 #
1024 # @vmstate-received: VM's state has been received by SVM.
1025 #
1026 # @vmstate-loaded: VM's state has been loaded by SVM.
1027 #
1028 # Since: 2.8
1029 ##
1030 { 'enum': 'COLOMessage',
1031   'data': [ 'checkpoint-ready', 'checkpoint-request', 'checkpoint-reply',
1032             'vmstate-send', 'vmstate-size', 'vmstate-received',
1033             'vmstate-loaded' ] }
1034
1035 ##
1036 # @COLOMode:
1037 #
1038 # The colo mode
1039 #
1040 # @unknown: unknown mode
1041 #
1042 # @primary: master side
1043 #
1044 # @secondary: slave side
1045 #
1046 # Since: 2.8
1047 ##
1048 { 'enum': 'COLOMode',
1049   'data': [ 'unknown', 'primary', 'secondary'] }
1050
1051 ##
1052 # @FailoverStatus:
1053 #
1054 # An enumeration of COLO failover status
1055 #
1056 # @none: no failover has ever happened
1057 #
1058 # @require: got failover requirement but not handled
1059 #
1060 # @active: in the process of doing failover
1061 #
1062 # @completed: finish the process of failover
1063 #
1064 # @relaunch: restart the failover process, from 'none' -> 'completed' (Since 2.9)
1065 #
1066 # Since: 2.8
1067 ##
1068 { 'enum': 'FailoverStatus',
1069   'data': [ 'none', 'require', 'active', 'completed', 'relaunch' ] }
1070
1071 ##
1072 # @x-colo-lost-heartbeat:
1073 #
1074 # Tell qemu that heartbeat is lost, request it to do takeover procedures.
1075 # If this command is sent to the PVM, the Primary side will exit COLO mode.
1076 # If sent to the Secondary, the Secondary side will run failover work,
1077 # then takes over server operation to become the service VM.
1078 #
1079 # Since: 2.8
1080 #
1081 # Example:
1082 #
1083 # -> { "execute": "x-colo-lost-heartbeat" }
1084 # <- { "return": {} }
1085 #
1086 ##
1087 { 'command': 'x-colo-lost-heartbeat' }
1088
1089 ##
1090 # @MouseInfo:
1091 #
1092 # Information about a mouse device.
1093 #
1094 # @name: the name of the mouse device
1095 #
1096 # @index: the index of the mouse device
1097 #
1098 # @current: true if this device is currently receiving mouse events
1099 #
1100 # @absolute: true if this device supports absolute coordinates as input
1101 #
1102 # Since: 0.14.0
1103 ##
1104 { 'struct': 'MouseInfo',
1105   'data': {'name': 'str', 'index': 'int', 'current': 'bool',
1106            'absolute': 'bool'} }
1107
1108 ##
1109 # @query-mice:
1110 #
1111 # Returns information about each active mouse device
1112 #
1113 # Returns: a list of @MouseInfo for each device
1114 #
1115 # Since: 0.14.0
1116 #
1117 # Example:
1118 #
1119 # -> { "execute": "query-mice" }
1120 # <- { "return": [
1121 #          {
1122 #             "name":"QEMU Microsoft Mouse",
1123 #             "index":0,
1124 #             "current":false,
1125 #             "absolute":false
1126 #          },
1127 #          {
1128 #             "name":"QEMU PS/2 Mouse",
1129 #             "index":1,
1130 #             "current":true,
1131 #             "absolute":true
1132 #          }
1133 #       ]
1134 #    }
1135 #
1136 ##
1137 { 'command': 'query-mice', 'returns': ['MouseInfo'] }
1138
1139 ##
1140 # @CpuInfoArch:
1141 #
1142 # An enumeration of cpu types that enable additional information during
1143 # @query-cpus.
1144 #
1145 # Since: 2.6
1146 ##
1147 { 'enum': 'CpuInfoArch',
1148   'data': ['x86', 'sparc', 'ppc', 'mips', 'tricore', 'other' ] }
1149
1150 ##
1151 # @CpuInfo:
1152 #
1153 # Information about a virtual CPU
1154 #
1155 # @CPU: the index of the virtual CPU
1156 #
1157 # @current: this only exists for backwards compatibility and should be ignored
1158 #
1159 # @halted: true if the virtual CPU is in the halt state.  Halt usually refers
1160 #          to a processor specific low power mode.
1161 #
1162 # @qom_path: path to the CPU object in the QOM tree (since 2.4)
1163 #
1164 # @thread_id: ID of the underlying host thread
1165 #
1166 # @props: properties describing to which node/socket/core/thread
1167 #         virtual CPU belongs to, provided if supported by board (since 2.10)
1168 #
1169 # @arch: architecture of the cpu, which determines which additional fields
1170 #        will be listed (since 2.6)
1171 #
1172 # Since: 0.14.0
1173 #
1174 # Notes: @halted is a transient state that changes frequently.  By the time the
1175 #        data is sent to the client, the guest may no longer be halted.
1176 ##
1177 { 'union': 'CpuInfo',
1178   'base': {'CPU': 'int', 'current': 'bool', 'halted': 'bool',
1179            'qom_path': 'str', 'thread_id': 'int',
1180            '*props': 'CpuInstanceProperties', 'arch': 'CpuInfoArch' },
1181   'discriminator': 'arch',
1182   'data': { 'x86': 'CpuInfoX86',
1183             'sparc': 'CpuInfoSPARC',
1184             'ppc': 'CpuInfoPPC',
1185             'mips': 'CpuInfoMIPS',
1186             'tricore': 'CpuInfoTricore',
1187             'other': 'CpuInfoOther' } }
1188
1189 ##
1190 # @CpuInfoX86:
1191 #
1192 # Additional information about a virtual i386 or x86_64 CPU
1193 #
1194 # @pc: the 64-bit instruction pointer
1195 #
1196 # Since: 2.6
1197 ##
1198 { 'struct': 'CpuInfoX86', 'data': { 'pc': 'int' } }
1199
1200 ##
1201 # @CpuInfoSPARC:
1202 #
1203 # Additional information about a virtual SPARC CPU
1204 #
1205 # @pc: the PC component of the instruction pointer
1206 #
1207 # @npc: the NPC component of the instruction pointer
1208 #
1209 # Since: 2.6
1210 ##
1211 { 'struct': 'CpuInfoSPARC', 'data': { 'pc': 'int', 'npc': 'int' } }
1212
1213 ##
1214 # @CpuInfoPPC:
1215 #
1216 # Additional information about a virtual PPC CPU
1217 #
1218 # @nip: the instruction pointer
1219 #
1220 # Since: 2.6
1221 ##
1222 { 'struct': 'CpuInfoPPC', 'data': { 'nip': 'int' } }
1223
1224 ##
1225 # @CpuInfoMIPS:
1226 #
1227 # Additional information about a virtual MIPS CPU
1228 #
1229 # @PC: the instruction pointer
1230 #
1231 # Since: 2.6
1232 ##
1233 { 'struct': 'CpuInfoMIPS', 'data': { 'PC': 'int' } }
1234
1235 ##
1236 # @CpuInfoTricore:
1237 #
1238 # Additional information about a virtual Tricore CPU
1239 #
1240 # @PC: the instruction pointer
1241 #
1242 # Since: 2.6
1243 ##
1244 { 'struct': 'CpuInfoTricore', 'data': { 'PC': 'int' } }
1245
1246 ##
1247 # @CpuInfoOther:
1248 #
1249 # No additional information is available about the virtual CPU
1250 #
1251 # Since: 2.6
1252 #
1253 ##
1254 { 'struct': 'CpuInfoOther', 'data': { } }
1255
1256 ##
1257 # @query-cpus:
1258 #
1259 # Returns a list of information about each virtual CPU.
1260 #
1261 # Returns: a list of @CpuInfo for each virtual CPU
1262 #
1263 # Since: 0.14.0
1264 #
1265 # Example:
1266 #
1267 # -> { "execute": "query-cpus" }
1268 # <- { "return": [
1269 #          {
1270 #             "CPU":0,
1271 #             "current":true,
1272 #             "halted":false,
1273 #             "qom_path":"/machine/unattached/device[0]",
1274 #             "arch":"x86",
1275 #             "pc":3227107138,
1276 #             "thread_id":3134
1277 #          },
1278 #          {
1279 #             "CPU":1,
1280 #             "current":false,
1281 #             "halted":true,
1282 #             "qom_path":"/machine/unattached/device[2]",
1283 #             "arch":"x86",
1284 #             "pc":7108165,
1285 #             "thread_id":3135
1286 #          }
1287 #       ]
1288 #    }
1289 #
1290 ##
1291 { 'command': 'query-cpus', 'returns': ['CpuInfo'] }
1292
1293 ##
1294 # @IOThreadInfo:
1295 #
1296 # Information about an iothread
1297 #
1298 # @id: the identifier of the iothread
1299 #
1300 # @thread-id: ID of the underlying host thread
1301 #
1302 # @poll-max-ns: maximum polling time in ns, 0 means polling is disabled
1303 #               (since 2.9)
1304 #
1305 # @poll-grow: how many ns will be added to polling time, 0 means that it's not
1306 #             configured (since 2.9)
1307 #
1308 # @poll-shrink: how many ns will be removed from polling time, 0 means that
1309 #               it's not configured (since 2.9)
1310 #
1311 # Since: 2.0
1312 ##
1313 { 'struct': 'IOThreadInfo',
1314   'data': {'id': 'str',
1315            'thread-id': 'int',
1316            'poll-max-ns': 'int',
1317            'poll-grow': 'int',
1318            'poll-shrink': 'int' } }
1319
1320 ##
1321 # @query-iothreads:
1322 #
1323 # Returns a list of information about each iothread.
1324 #
1325 # Note: this list excludes the QEMU main loop thread, which is not declared
1326 # using the -object iothread command-line option.  It is always the main thread
1327 # of the process.
1328 #
1329 # Returns: a list of @IOThreadInfo for each iothread
1330 #
1331 # Since: 2.0
1332 #
1333 # Example:
1334 #
1335 # -> { "execute": "query-iothreads" }
1336 # <- { "return": [
1337 #          {
1338 #             "id":"iothread0",
1339 #             "thread-id":3134
1340 #          },
1341 #          {
1342 #             "id":"iothread1",
1343 #             "thread-id":3135
1344 #          }
1345 #       ]
1346 #    }
1347 #
1348 ##
1349 { 'command': 'query-iothreads', 'returns': ['IOThreadInfo'] }
1350
1351 ##
1352 # @VncBasicInfo:
1353 #
1354 # The basic information for vnc network connection
1355 #
1356 # @host: IP address
1357 #
1358 # @service: The service name of the vnc port. This may depend on the host
1359 #           system's service database so symbolic names should not be relied
1360 #           on.
1361 #
1362 # @family: address family
1363 #
1364 # @websocket: true in case the socket is a websocket (since 2.3).
1365 #
1366 # Since: 2.1
1367 ##
1368 { 'struct': 'VncBasicInfo',
1369   'data': { 'host': 'str',
1370             'service': 'str',
1371             'family': 'NetworkAddressFamily',
1372             'websocket': 'bool' } }
1373
1374 ##
1375 # @VncServerInfo:
1376 #
1377 # The network connection information for server
1378 #
1379 # @auth: authentication method used for
1380 #        the plain (non-websocket) VNC server
1381 #
1382 # Since: 2.1
1383 ##
1384 { 'struct': 'VncServerInfo',
1385   'base': 'VncBasicInfo',
1386   'data': { '*auth': 'str' } }
1387
1388 ##
1389 # @VncClientInfo:
1390 #
1391 # Information about a connected VNC client.
1392 #
1393 # @x509_dname: If x509 authentication is in use, the Distinguished
1394 #              Name of the client.
1395 #
1396 # @sasl_username: If SASL authentication is in use, the SASL username
1397 #                 used for authentication.
1398 #
1399 # Since: 0.14.0
1400 ##
1401 { 'struct': 'VncClientInfo',
1402   'base': 'VncBasicInfo',
1403   'data': { '*x509_dname': 'str', '*sasl_username': 'str' } }
1404
1405 ##
1406 # @VncInfo:
1407 #
1408 # Information about the VNC session.
1409 #
1410 # @enabled: true if the VNC server is enabled, false otherwise
1411 #
1412 # @host: The hostname the VNC server is bound to.  This depends on
1413 #        the name resolution on the host and may be an IP address.
1414 #
1415 # @family: 'ipv6' if the host is listening for IPv6 connections
1416 #                    'ipv4' if the host is listening for IPv4 connections
1417 #                    'unix' if the host is listening on a unix domain socket
1418 #                    'unknown' otherwise
1419 #
1420 # @service: The service name of the server's port.  This may depends
1421 #           on the host system's service database so symbolic names should not
1422 #           be relied on.
1423 #
1424 # @auth: the current authentication type used by the server
1425 #        'none' if no authentication is being used
1426 #        'vnc' if VNC authentication is being used
1427 #        'vencrypt+plain' if VEncrypt is used with plain text authentication
1428 #        'vencrypt+tls+none' if VEncrypt is used with TLS and no authentication
1429 #        'vencrypt+tls+vnc' if VEncrypt is used with TLS and VNC authentication
1430 #        'vencrypt+tls+plain' if VEncrypt is used with TLS and plain text auth
1431 #        'vencrypt+x509+none' if VEncrypt is used with x509 and no auth
1432 #        'vencrypt+x509+vnc' if VEncrypt is used with x509 and VNC auth
1433 #        'vencrypt+x509+plain' if VEncrypt is used with x509 and plain text auth
1434 #        'vencrypt+tls+sasl' if VEncrypt is used with TLS and SASL auth
1435 #        'vencrypt+x509+sasl' if VEncrypt is used with x509 and SASL auth
1436 #
1437 # @clients: a list of @VncClientInfo of all currently connected clients
1438 #
1439 # Since: 0.14.0
1440 ##
1441 { 'struct': 'VncInfo',
1442   'data': {'enabled': 'bool', '*host': 'str',
1443            '*family': 'NetworkAddressFamily',
1444            '*service': 'str', '*auth': 'str', '*clients': ['VncClientInfo']} }
1445
1446 ##
1447 # @VncPrimaryAuth:
1448 #
1449 # vnc primary authentication method.
1450 #
1451 # Since: 2.3
1452 ##
1453 { 'enum': 'VncPrimaryAuth',
1454   'data': [ 'none', 'vnc', 'ra2', 'ra2ne', 'tight', 'ultra',
1455             'tls', 'vencrypt', 'sasl' ] }
1456
1457 ##
1458 # @VncVencryptSubAuth:
1459 #
1460 # vnc sub authentication method with vencrypt.
1461 #
1462 # Since: 2.3
1463 ##
1464 { 'enum': 'VncVencryptSubAuth',
1465   'data': [ 'plain',
1466             'tls-none',  'x509-none',
1467             'tls-vnc',   'x509-vnc',
1468             'tls-plain', 'x509-plain',
1469             'tls-sasl',  'x509-sasl' ] }
1470
1471
1472 ##
1473 # @VncServerInfo2:
1474 #
1475 # The network connection information for server
1476 #
1477 # @auth: The current authentication type used by the servers
1478 #
1479 # @vencrypt: The vencrypt sub authentication type used by the
1480 #            servers, only specified in case auth == vencrypt.
1481 #
1482 # Since: 2.9
1483 ##
1484 { 'struct': 'VncServerInfo2',
1485   'base': 'VncBasicInfo',
1486   'data': { 'auth'      : 'VncPrimaryAuth',
1487             '*vencrypt' : 'VncVencryptSubAuth' } }
1488
1489
1490 ##
1491 # @VncInfo2:
1492 #
1493 # Information about a vnc server
1494 #
1495 # @id: vnc server name.
1496 #
1497 # @server: A list of @VncBasincInfo describing all listening sockets.
1498 #          The list can be empty (in case the vnc server is disabled).
1499 #          It also may have multiple entries: normal + websocket,
1500 #          possibly also ipv4 + ipv6 in the future.
1501 #
1502 # @clients: A list of @VncClientInfo of all currently connected clients.
1503 #           The list can be empty, for obvious reasons.
1504 #
1505 # @auth: The current authentication type used by the non-websockets servers
1506 #
1507 # @vencrypt: The vencrypt authentication type used by the servers,
1508 #            only specified in case auth == vencrypt.
1509 #
1510 # @display: The display device the vnc server is linked to.
1511 #
1512 # Since: 2.3
1513 ##
1514 { 'struct': 'VncInfo2',
1515   'data': { 'id'        : 'str',
1516             'server'    : ['VncServerInfo2'],
1517             'clients'   : ['VncClientInfo'],
1518             'auth'      : 'VncPrimaryAuth',
1519             '*vencrypt' : 'VncVencryptSubAuth',
1520             '*display'  : 'str' } }
1521
1522 ##
1523 # @query-vnc:
1524 #
1525 # Returns information about the current VNC server
1526 #
1527 # Returns: @VncInfo
1528 #
1529 # Since: 0.14.0
1530 #
1531 # Example:
1532 #
1533 # -> { "execute": "query-vnc" }
1534 # <- { "return": {
1535 #          "enabled":true,
1536 #          "host":"0.0.0.0",
1537 #          "service":"50402",
1538 #          "auth":"vnc",
1539 #          "family":"ipv4",
1540 #          "clients":[
1541 #             {
1542 #                "host":"127.0.0.1",
1543 #                "service":"50401",
1544 #                "family":"ipv4"
1545 #             }
1546 #          ]
1547 #       }
1548 #    }
1549 #
1550 ##
1551 { 'command': 'query-vnc', 'returns': 'VncInfo' }
1552
1553 ##
1554 # @query-vnc-servers:
1555 #
1556 # Returns a list of vnc servers.  The list can be empty.
1557 #
1558 # Returns: a list of @VncInfo2
1559 #
1560 # Since: 2.3
1561 ##
1562 { 'command': 'query-vnc-servers', 'returns': ['VncInfo2'] }
1563
1564 ##
1565 # @SpiceBasicInfo:
1566 #
1567 # The basic information for SPICE network connection
1568 #
1569 # @host: IP address
1570 #
1571 # @port: port number
1572 #
1573 # @family: address family
1574 #
1575 # Since: 2.1
1576 ##
1577 { 'struct': 'SpiceBasicInfo',
1578   'data': { 'host': 'str',
1579             'port': 'str',
1580             'family': 'NetworkAddressFamily' } }
1581
1582 ##
1583 # @SpiceServerInfo:
1584 #
1585 # Information about a SPICE server
1586 #
1587 # @auth: authentication method
1588 #
1589 # Since: 2.1
1590 ##
1591 { 'struct': 'SpiceServerInfo',
1592   'base': 'SpiceBasicInfo',
1593   'data': { '*auth': 'str' } }
1594
1595 ##
1596 # @SpiceChannel:
1597 #
1598 # Information about a SPICE client channel.
1599 #
1600 # @connection-id: SPICE connection id number.  All channels with the same id
1601 #                 belong to the same SPICE session.
1602 #
1603 # @channel-type: SPICE channel type number.  "1" is the main control
1604 #                channel, filter for this one if you want to track spice
1605 #                sessions only
1606 #
1607 # @channel-id: SPICE channel ID number.  Usually "0", might be different when
1608 #              multiple channels of the same type exist, such as multiple
1609 #              display channels in a multihead setup
1610 #
1611 # @tls: true if the channel is encrypted, false otherwise.
1612 #
1613 # Since: 0.14.0
1614 ##
1615 { 'struct': 'SpiceChannel',
1616   'base': 'SpiceBasicInfo',
1617   'data': {'connection-id': 'int', 'channel-type': 'int', 'channel-id': 'int',
1618            'tls': 'bool'} }
1619
1620 ##
1621 # @SpiceQueryMouseMode:
1622 #
1623 # An enumeration of Spice mouse states.
1624 #
1625 # @client: Mouse cursor position is determined by the client.
1626 #
1627 # @server: Mouse cursor position is determined by the server.
1628 #
1629 # @unknown: No information is available about mouse mode used by
1630 #           the spice server.
1631 #
1632 # Note: spice/enums.h has a SpiceMouseMode already, hence the name.
1633 #
1634 # Since: 1.1
1635 ##
1636 { 'enum': 'SpiceQueryMouseMode',
1637   'data': [ 'client', 'server', 'unknown' ] }
1638
1639 ##
1640 # @SpiceInfo:
1641 #
1642 # Information about the SPICE session.
1643 #
1644 # @enabled: true if the SPICE server is enabled, false otherwise
1645 #
1646 # @migrated: true if the last guest migration completed and spice
1647 #            migration had completed as well. false otherwise. (since 1.4)
1648 #
1649 # @host: The hostname the SPICE server is bound to.  This depends on
1650 #        the name resolution on the host and may be an IP address.
1651 #
1652 # @port: The SPICE server's port number.
1653 #
1654 # @compiled-version: SPICE server version.
1655 #
1656 # @tls-port: The SPICE server's TLS port number.
1657 #
1658 # @auth: the current authentication type used by the server
1659 #        'none'  if no authentication is being used
1660 #        'spice' uses SASL or direct TLS authentication, depending on command
1661 #                line options
1662 #
1663 # @mouse-mode: The mode in which the mouse cursor is displayed currently. Can
1664 #              be determined by the client or the server, or unknown if spice
1665 #              server doesn't provide this information. (since: 1.1)
1666 #
1667 # @channels: a list of @SpiceChannel for each active spice channel
1668 #
1669 # Since: 0.14.0
1670 ##
1671 { 'struct': 'SpiceInfo',
1672   'data': {'enabled': 'bool', 'migrated': 'bool', '*host': 'str', '*port': 'int',
1673            '*tls-port': 'int', '*auth': 'str', '*compiled-version': 'str',
1674            'mouse-mode': 'SpiceQueryMouseMode', '*channels': ['SpiceChannel']} }
1675
1676 ##
1677 # @query-spice:
1678 #
1679 # Returns information about the current SPICE server
1680 #
1681 # Returns: @SpiceInfo
1682 #
1683 # Since: 0.14.0
1684 #
1685 # Example:
1686 #
1687 # -> { "execute": "query-spice" }
1688 # <- { "return": {
1689 #          "enabled": true,
1690 #          "auth": "spice",
1691 #          "port": 5920,
1692 #          "tls-port": 5921,
1693 #          "host": "0.0.0.0",
1694 #          "channels": [
1695 #             {
1696 #                "port": "54924",
1697 #                "family": "ipv4",
1698 #                "channel-type": 1,
1699 #                "connection-id": 1804289383,
1700 #                "host": "127.0.0.1",
1701 #                "channel-id": 0,
1702 #                "tls": true
1703 #             },
1704 #             {
1705 #                "port": "36710",
1706 #                "family": "ipv4",
1707 #                "channel-type": 4,
1708 #                "connection-id": 1804289383,
1709 #                "host": "127.0.0.1",
1710 #                "channel-id": 0,
1711 #                "tls": false
1712 #             },
1713 #             [ ... more channels follow ... ]
1714 #          ]
1715 #       }
1716 #    }
1717 #
1718 ##
1719 { 'command': 'query-spice', 'returns': 'SpiceInfo' }
1720
1721 ##
1722 # @BalloonInfo:
1723 #
1724 # Information about the guest balloon device.
1725 #
1726 # @actual: the number of bytes the balloon currently contains
1727 #
1728 # Since: 0.14.0
1729 #
1730 ##
1731 { 'struct': 'BalloonInfo', 'data': {'actual': 'int' } }
1732
1733 ##
1734 # @query-balloon:
1735 #
1736 # Return information about the balloon device.
1737 #
1738 # Returns: @BalloonInfo on success
1739 #
1740 #          If the balloon driver is enabled but not functional because the KVM
1741 #          kernel module cannot support it, KvmMissingCap
1742 #
1743 #          If no balloon device is present, DeviceNotActive
1744 #
1745 # Since: 0.14.0
1746 #
1747 # Example:
1748 #
1749 # -> { "execute": "query-balloon" }
1750 # <- { "return": {
1751 #          "actual": 1073741824,
1752 #       }
1753 #    }
1754 #
1755 ##
1756 { 'command': 'query-balloon', 'returns': 'BalloonInfo' }
1757
1758 ##
1759 # @PciMemoryRange:
1760 #
1761 # A PCI device memory region
1762 #
1763 # @base: the starting address (guest physical)
1764 #
1765 # @limit: the ending address (guest physical)
1766 #
1767 # Since: 0.14.0
1768 ##
1769 { 'struct': 'PciMemoryRange', 'data': {'base': 'int', 'limit': 'int'} }
1770
1771 ##
1772 # @PciMemoryRegion:
1773 #
1774 # Information about a PCI device I/O region.
1775 #
1776 # @bar: the index of the Base Address Register for this region
1777 #
1778 # @type: 'io' if the region is a PIO region
1779 #        'memory' if the region is a MMIO region
1780 #
1781 # @size: memory size
1782 #
1783 # @prefetch: if @type is 'memory', true if the memory is prefetchable
1784 #
1785 # @mem_type_64: if @type is 'memory', true if the BAR is 64-bit
1786 #
1787 # Since: 0.14.0
1788 ##
1789 { 'struct': 'PciMemoryRegion',
1790   'data': {'bar': 'int', 'type': 'str', 'address': 'int', 'size': 'int',
1791            '*prefetch': 'bool', '*mem_type_64': 'bool' } }
1792
1793 ##
1794 # @PciBusInfo:
1795 #
1796 # Information about a bus of a PCI Bridge device
1797 #
1798 # @number: primary bus interface number.  This should be the number of the
1799 #          bus the device resides on.
1800 #
1801 # @secondary: secondary bus interface number.  This is the number of the
1802 #             main bus for the bridge
1803 #
1804 # @subordinate: This is the highest number bus that resides below the
1805 #               bridge.
1806 #
1807 # @io_range: The PIO range for all devices on this bridge
1808 #
1809 # @memory_range: The MMIO range for all devices on this bridge
1810 #
1811 # @prefetchable_range: The range of prefetchable MMIO for all devices on
1812 #                      this bridge
1813 #
1814 # Since: 2.4
1815 ##
1816 { 'struct': 'PciBusInfo',
1817   'data': {'number': 'int', 'secondary': 'int', 'subordinate': 'int',
1818            'io_range': 'PciMemoryRange',
1819            'memory_range': 'PciMemoryRange',
1820            'prefetchable_range': 'PciMemoryRange' } }
1821
1822 ##
1823 # @PciBridgeInfo:
1824 #
1825 # Information about a PCI Bridge device
1826 #
1827 # @bus: information about the bus the device resides on
1828 #
1829 # @devices: a list of @PciDeviceInfo for each device on this bridge
1830 #
1831 # Since: 0.14.0
1832 ##
1833 { 'struct': 'PciBridgeInfo',
1834   'data': {'bus': 'PciBusInfo', '*devices': ['PciDeviceInfo']} }
1835
1836 ##
1837 # @PciDeviceClass:
1838 #
1839 # Information about the Class of a PCI device
1840 #
1841 # @desc: a string description of the device's class
1842 #
1843 # @class: the class code of the device
1844 #
1845 # Since: 2.4
1846 ##
1847 { 'struct': 'PciDeviceClass',
1848   'data': {'*desc': 'str', 'class': 'int'} }
1849
1850 ##
1851 # @PciDeviceId:
1852 #
1853 # Information about the Id of a PCI device
1854 #
1855 # @device: the PCI device id
1856 #
1857 # @vendor: the PCI vendor id
1858 #
1859 # Since: 2.4
1860 ##
1861 { 'struct': 'PciDeviceId',
1862   'data': {'device': 'int', 'vendor': 'int'} }
1863
1864 ##
1865 # @PciDeviceInfo:
1866 #
1867 # Information about a PCI device
1868 #
1869 # @bus: the bus number of the device
1870 #
1871 # @slot: the slot the device is located in
1872 #
1873 # @function: the function of the slot used by the device
1874 #
1875 # @class_info: the class of the device
1876 #
1877 # @id: the PCI device id
1878 #
1879 # @irq: if an IRQ is assigned to the device, the IRQ number
1880 #
1881 # @qdev_id: the device name of the PCI device
1882 #
1883 # @pci_bridge: if the device is a PCI bridge, the bridge information
1884 #
1885 # @regions: a list of the PCI I/O regions associated with the device
1886 #
1887 # Notes: the contents of @class_info.desc are not stable and should only be
1888 #        treated as informational.
1889 #
1890 # Since: 0.14.0
1891 ##
1892 { 'struct': 'PciDeviceInfo',
1893   'data': {'bus': 'int', 'slot': 'int', 'function': 'int',
1894            'class_info': 'PciDeviceClass', 'id': 'PciDeviceId',
1895            '*irq': 'int', 'qdev_id': 'str', '*pci_bridge': 'PciBridgeInfo',
1896            'regions': ['PciMemoryRegion']} }
1897
1898 ##
1899 # @PciInfo:
1900 #
1901 # Information about a PCI bus
1902 #
1903 # @bus: the bus index
1904 #
1905 # @devices: a list of devices on this bus
1906 #
1907 # Since: 0.14.0
1908 ##
1909 { 'struct': 'PciInfo', 'data': {'bus': 'int', 'devices': ['PciDeviceInfo']} }
1910
1911 ##
1912 # @query-pci:
1913 #
1914 # Return information about the PCI bus topology of the guest.
1915 #
1916 # Returns: a list of @PciInfo for each PCI bus. Each bus is
1917 # represented by a json-object, which has a key with a json-array of
1918 # all PCI devices attached to it. Each device is represented by a
1919 # json-object.
1920 #
1921 # Since: 0.14.0
1922 #
1923 # Example:
1924 #
1925 # -> { "execute": "query-pci" }
1926 # <- { "return": [
1927 #          {
1928 #             "bus": 0,
1929 #             "devices": [
1930 #                {
1931 #                   "bus": 0,
1932 #                   "qdev_id": "",
1933 #                   "slot": 0,
1934 #                   "class_info": {
1935 #                      "class": 1536,
1936 #                      "desc": "Host bridge"
1937 #                   },
1938 #                   "id": {
1939 #                      "device": 32902,
1940 #                      "vendor": 4663
1941 #                   },
1942 #                   "function": 0,
1943 #                   "regions": [
1944 #                   ]
1945 #                },
1946 #                {
1947 #                   "bus": 0,
1948 #                   "qdev_id": "",
1949 #                   "slot": 1,
1950 #                   "class_info": {
1951 #                      "class": 1537,
1952 #                      "desc": "ISA bridge"
1953 #                   },
1954 #                   "id": {
1955 #                      "device": 32902,
1956 #                      "vendor": 28672
1957 #                   },
1958 #                   "function": 0,
1959 #                   "regions": [
1960 #                   ]
1961 #                },
1962 #                {
1963 #                   "bus": 0,
1964 #                   "qdev_id": "",
1965 #                   "slot": 1,
1966 #                   "class_info": {
1967 #                      "class": 257,
1968 #                      "desc": "IDE controller"
1969 #                   },
1970 #                   "id": {
1971 #                      "device": 32902,
1972 #                      "vendor": 28688
1973 #                   },
1974 #                   "function": 1,
1975 #                   "regions": [
1976 #                      {
1977 #                         "bar": 4,
1978 #                         "size": 16,
1979 #                         "address": 49152,
1980 #                         "type": "io"
1981 #                      }
1982 #                   ]
1983 #                },
1984 #                {
1985 #                   "bus": 0,
1986 #                   "qdev_id": "",
1987 #                   "slot": 2,
1988 #                   "class_info": {
1989 #                      "class": 768,
1990 #                      "desc": "VGA controller"
1991 #                   },
1992 #                   "id": {
1993 #                      "device": 4115,
1994 #                      "vendor": 184
1995 #                   },
1996 #                   "function": 0,
1997 #                   "regions": [
1998 #                      {
1999 #                         "prefetch": true,
2000 #                         "mem_type_64": false,
2001 #                         "bar": 0,
2002 #                         "size": 33554432,
2003 #                         "address": 4026531840,
2004 #                         "type": "memory"
2005 #                      },
2006 #                      {
2007 #                         "prefetch": false,
2008 #                         "mem_type_64": false,
2009 #                         "bar": 1,
2010 #                         "size": 4096,
2011 #                         "address": 4060086272,
2012 #                         "type": "memory"
2013 #                      },
2014 #                      {
2015 #                         "prefetch": false,
2016 #                         "mem_type_64": false,
2017 #                         "bar": 6,
2018 #                         "size": 65536,
2019 #                         "address": -1,
2020 #                         "type": "memory"
2021 #                      }
2022 #                   ]
2023 #                },
2024 #                {
2025 #                   "bus": 0,
2026 #                   "qdev_id": "",
2027 #                   "irq": 11,
2028 #                   "slot": 4,
2029 #                   "class_info": {
2030 #                      "class": 1280,
2031 #                      "desc": "RAM controller"
2032 #                   },
2033 #                   "id": {
2034 #                      "device": 6900,
2035 #                      "vendor": 4098
2036 #                   },
2037 #                   "function": 0,
2038 #                   "regions": [
2039 #                      {
2040 #                         "bar": 0,
2041 #                         "size": 32,
2042 #                         "address": 49280,
2043 #                         "type": "io"
2044 #                      }
2045 #                   ]
2046 #                }
2047 #             ]
2048 #          }
2049 #       ]
2050 #    }
2051 #
2052 # Note: This example has been shortened as the real response is too long.
2053 #
2054 ##
2055 { 'command': 'query-pci', 'returns': ['PciInfo'] }
2056
2057 ##
2058 # @quit:
2059 #
2060 # This command will cause the QEMU process to exit gracefully.  While every
2061 # attempt is made to send the QMP response before terminating, this is not
2062 # guaranteed.  When using this interface, a premature EOF would not be
2063 # unexpected.
2064 #
2065 # Since: 0.14.0
2066 #
2067 # Example:
2068 #
2069 # -> { "execute": "quit" }
2070 # <- { "return": {} }
2071 ##
2072 { 'command': 'quit' }
2073
2074 ##
2075 # @stop:
2076 #
2077 # Stop all guest VCPU execution.
2078 #
2079 # Since:  0.14.0
2080 #
2081 # Notes:  This function will succeed even if the guest is already in the stopped
2082 #         state.  In "inmigrate" state, it will ensure that the guest
2083 #         remains paused once migration finishes, as if the -S option was
2084 #         passed on the command line.
2085 #
2086 # Example:
2087 #
2088 # -> { "execute": "stop" }
2089 # <- { "return": {} }
2090 #
2091 ##
2092 { 'command': 'stop' }
2093
2094 ##
2095 # @system_reset:
2096 #
2097 # Performs a hard reset of a guest.
2098 #
2099 # Since: 0.14.0
2100 #
2101 # Example:
2102 #
2103 # -> { "execute": "system_reset" }
2104 # <- { "return": {} }
2105 #
2106 ##
2107 { 'command': 'system_reset' }
2108
2109 ##
2110 # @system_powerdown:
2111 #
2112 # Requests that a guest perform a powerdown operation.
2113 #
2114 # Since: 0.14.0
2115 #
2116 # Notes: A guest may or may not respond to this command.  This command
2117 #        returning does not indicate that a guest has accepted the request or
2118 #        that it has shut down.  Many guests will respond to this command by
2119 #        prompting the user in some way.
2120 # Example:
2121 #
2122 # -> { "execute": "system_powerdown" }
2123 # <- { "return": {} }
2124 #
2125 ##
2126 { 'command': 'system_powerdown' }
2127
2128 ##
2129 # @cpu:
2130 #
2131 # This command is a nop that is only provided for the purposes of compatibility.
2132 #
2133 # Since: 0.14.0
2134 #
2135 # Notes: Do not use this command.
2136 ##
2137 { 'command': 'cpu', 'data': {'index': 'int'} }
2138
2139 ##
2140 # @cpu-add:
2141 #
2142 # Adds CPU with specified ID
2143 #
2144 # @id: ID of CPU to be created, valid values [0..max_cpus)
2145 #
2146 # Returns: Nothing on success
2147 #
2148 # Since: 1.5
2149 #
2150 # Example:
2151 #
2152 # -> { "execute": "cpu-add", "arguments": { "id": 2 } }
2153 # <- { "return": {} }
2154 #
2155 ##
2156 { 'command': 'cpu-add', 'data': {'id': 'int'} }
2157
2158 ##
2159 # @memsave:
2160 #
2161 # Save a portion of guest memory to a file.
2162 #
2163 # @val: the virtual address of the guest to start from
2164 #
2165 # @size: the size of memory region to save
2166 #
2167 # @filename: the file to save the memory to as binary data
2168 #
2169 # @cpu-index: the index of the virtual CPU to use for translating the
2170 #                       virtual address (defaults to CPU 0)
2171 #
2172 # Returns: Nothing on success
2173 #
2174 # Since: 0.14.0
2175 #
2176 # Notes: Errors were not reliably returned until 1.1
2177 #
2178 # Example:
2179 #
2180 # -> { "execute": "memsave",
2181 #      "arguments": { "val": 10,
2182 #                     "size": 100,
2183 #                     "filename": "/tmp/virtual-mem-dump" } }
2184 # <- { "return": {} }
2185 #
2186 ##
2187 { 'command': 'memsave',
2188   'data': {'val': 'int', 'size': 'int', 'filename': 'str', '*cpu-index': 'int'} }
2189
2190 ##
2191 # @pmemsave:
2192 #
2193 # Save a portion of guest physical memory to a file.
2194 #
2195 # @val: the physical address of the guest to start from
2196 #
2197 # @size: the size of memory region to save
2198 #
2199 # @filename: the file to save the memory to as binary data
2200 #
2201 # Returns: Nothing on success
2202 #
2203 # Since: 0.14.0
2204 #
2205 # Notes: Errors were not reliably returned until 1.1
2206 #
2207 # Example:
2208 #
2209 # -> { "execute": "pmemsave",
2210 #      "arguments": { "val": 10,
2211 #                     "size": 100,
2212 #                     "filename": "/tmp/physical-mem-dump" } }
2213 # <- { "return": {} }
2214 #
2215 ##
2216 { 'command': 'pmemsave',
2217   'data': {'val': 'int', 'size': 'int', 'filename': 'str'} }
2218
2219 ##
2220 # @cont:
2221 #
2222 # Resume guest VCPU execution.
2223 #
2224 # Since:  0.14.0
2225 #
2226 # Returns:  If successful, nothing
2227 #
2228 # Notes:  This command will succeed if the guest is currently running.  It
2229 #         will also succeed if the guest is in the "inmigrate" state; in
2230 #         this case, the effect of the command is to make sure the guest
2231 #         starts once migration finishes, removing the effect of the -S
2232 #         command line option if it was passed.
2233 #
2234 # Example:
2235 #
2236 # -> { "execute": "cont" }
2237 # <- { "return": {} }
2238 #
2239 ##
2240 { 'command': 'cont' }
2241
2242 ##
2243 # @system_wakeup:
2244 #
2245 # Wakeup guest from suspend.  Does nothing in case the guest isn't suspended.
2246 #
2247 # Since:  1.1
2248 #
2249 # Returns:  nothing.
2250 #
2251 # Example:
2252 #
2253 # -> { "execute": "system_wakeup" }
2254 # <- { "return": {} }
2255 #
2256 ##
2257 { 'command': 'system_wakeup' }
2258
2259 ##
2260 # @inject-nmi:
2261 #
2262 # Injects a Non-Maskable Interrupt into the default CPU (x86/s390) or all CPUs (ppc64).
2263 # The command fails when the guest doesn't support injecting.
2264 #
2265 # Returns:  If successful, nothing
2266 #
2267 # Since:  0.14.0
2268 #
2269 # Note: prior to 2.1, this command was only supported for x86 and s390 VMs
2270 #
2271 # Example:
2272 #
2273 # -> { "execute": "inject-nmi" }
2274 # <- { "return": {} }
2275 #
2276 ##
2277 { 'command': 'inject-nmi' }
2278
2279 ##
2280 # @balloon:
2281 #
2282 # Request the balloon driver to change its balloon size.
2283 #
2284 # @value: the target size of the balloon in bytes
2285 #
2286 # Returns: Nothing on success
2287 #          If the balloon driver is enabled but not functional because the KVM
2288 #            kernel module cannot support it, KvmMissingCap
2289 #          If no balloon device is present, DeviceNotActive
2290 #
2291 # Notes: This command just issues a request to the guest.  When it returns,
2292 #        the balloon size may not have changed.  A guest can change the balloon
2293 #        size independent of this command.
2294 #
2295 # Since: 0.14.0
2296 #
2297 # Example:
2298 #
2299 # -> { "execute": "balloon", "arguments": { "value": 536870912 } }
2300 # <- { "return": {} }
2301 #
2302 ##
2303 { 'command': 'balloon', 'data': {'value': 'int'} }
2304
2305 ##
2306 # @Abort:
2307 #
2308 # This action can be used to test transaction failure.
2309 #
2310 # Since: 1.6
2311 ##
2312 { 'struct': 'Abort',
2313   'data': { } }
2314
2315 ##
2316 # @ActionCompletionMode:
2317 #
2318 # An enumeration of Transactional completion modes.
2319 #
2320 # @individual: Do not attempt to cancel any other Actions if any Actions fail
2321 #              after the Transaction request succeeds. All Actions that
2322 #              can complete successfully will do so without waiting on others.
2323 #              This is the default.
2324 #
2325 # @grouped: If any Action fails after the Transaction succeeds, cancel all
2326 #           Actions. Actions do not complete until all Actions are ready to
2327 #           complete. May be rejected by Actions that do not support this
2328 #           completion mode.
2329 #
2330 # Since: 2.5
2331 ##
2332 { 'enum': 'ActionCompletionMode',
2333   'data': [ 'individual', 'grouped' ] }
2334
2335 ##
2336 # @TransactionAction:
2337 #
2338 # A discriminated record of operations that can be performed with
2339 # @transaction. Action @type can be:
2340 #
2341 # - @abort: since 1.6
2342 # - @block-dirty-bitmap-add: since 2.5
2343 # - @block-dirty-bitmap-clear: since 2.5
2344 # - @blockdev-backup: since 2.3
2345 # - @blockdev-snapshot: since 2.5
2346 # - @blockdev-snapshot-internal-sync: since 1.7
2347 # - @blockdev-snapshot-sync: since 1.1
2348 # - @drive-backup: since 1.6
2349 #
2350 # Since: 1.1
2351 ##
2352 { 'union': 'TransactionAction',
2353   'data': {
2354        'abort': 'Abort',
2355        'block-dirty-bitmap-add': 'BlockDirtyBitmapAdd',
2356        'block-dirty-bitmap-clear': 'BlockDirtyBitmap',
2357        'blockdev-backup': 'BlockdevBackup',
2358        'blockdev-snapshot': 'BlockdevSnapshot',
2359        'blockdev-snapshot-internal-sync': 'BlockdevSnapshotInternal',
2360        'blockdev-snapshot-sync': 'BlockdevSnapshotSync',
2361        'drive-backup': 'DriveBackup'
2362    } }
2363
2364 ##
2365 # @TransactionProperties:
2366 #
2367 # Optional arguments to modify the behavior of a Transaction.
2368 #
2369 # @completion-mode: Controls how jobs launched asynchronously by
2370 #                   Actions will complete or fail as a group.
2371 #                   See @ActionCompletionMode for details.
2372 #
2373 # Since: 2.5
2374 ##
2375 { 'struct': 'TransactionProperties',
2376   'data': {
2377        '*completion-mode': 'ActionCompletionMode'
2378   }
2379 }
2380
2381 ##
2382 # @transaction:
2383 #
2384 # Executes a number of transactionable QMP commands atomically. If any
2385 # operation fails, then the entire set of actions will be abandoned and the
2386 # appropriate error returned.
2387 #
2388 # For external snapshots, the dictionary contains the device, the file to use for
2389 # the new snapshot, and the format.  The default format, if not specified, is
2390 # qcow2.
2391 #
2392 # Each new snapshot defaults to being created by QEMU (wiping any
2393 # contents if the file already exists), but it is also possible to reuse
2394 # an externally-created file.  In the latter case, you should ensure that
2395 # the new image file has the same contents as the current one; QEMU cannot
2396 # perform any meaningful check.  Typically this is achieved by using the
2397 # current image file as the backing file for the new image.
2398 #
2399 # On failure, the original disks pre-snapshot attempt will be used.
2400 #
2401 # For internal snapshots, the dictionary contains the device and the snapshot's
2402 # name.  If an internal snapshot matching name already exists, the request will
2403 # be rejected.  Only some image formats support it, for example, qcow2, rbd,
2404 # and sheepdog.
2405 #
2406 # On failure, qemu will try delete the newly created internal snapshot in the
2407 # transaction.  When an I/O error occurs during deletion, the user needs to fix
2408 # it later with qemu-img or other command.
2409 #
2410 # @actions: List of @TransactionAction;
2411 #           information needed for the respective operations.
2412 #
2413 # @properties: structure of additional options to control the
2414 #              execution of the transaction. See @TransactionProperties
2415 #              for additional detail.
2416 #
2417 # Returns: nothing on success
2418 #
2419 #          Errors depend on the operations of the transaction
2420 #
2421 # Note: The transaction aborts on the first failure.  Therefore, there will be
2422 # information on only one failed operation returned in an error condition, and
2423 # subsequent actions will not have been attempted.
2424 #
2425 # Since: 1.1
2426 #
2427 # Example:
2428 #
2429 # -> { "execute": "transaction",
2430 #      "arguments": { "actions": [
2431 #          { "type": "blockdev-snapshot-sync", "data" : { "device": "ide-hd0",
2432 #                                      "snapshot-file": "/some/place/my-image",
2433 #                                      "format": "qcow2" } },
2434 #          { "type": "blockdev-snapshot-sync", "data" : { "node-name": "myfile",
2435 #                                      "snapshot-file": "/some/place/my-image2",
2436 #                                      "snapshot-node-name": "node3432",
2437 #                                      "mode": "existing",
2438 #                                      "format": "qcow2" } },
2439 #          { "type": "blockdev-snapshot-sync", "data" : { "device": "ide-hd1",
2440 #                                      "snapshot-file": "/some/place/my-image2",
2441 #                                      "mode": "existing",
2442 #                                      "format": "qcow2" } },
2443 #          { "type": "blockdev-snapshot-internal-sync", "data" : {
2444 #                                      "device": "ide-hd2",
2445 #                                      "name": "snapshot0" } } ] } }
2446 # <- { "return": {} }
2447 #
2448 ##
2449 { 'command': 'transaction',
2450   'data': { 'actions': [ 'TransactionAction' ],
2451             '*properties': 'TransactionProperties'
2452           }
2453 }
2454
2455 ##
2456 # @human-monitor-command:
2457 #
2458 # Execute a command on the human monitor and return the output.
2459 #
2460 # @command-line: the command to execute in the human monitor
2461 #
2462 # @cpu-index: The CPU to use for commands that require an implicit CPU
2463 #
2464 # Returns: the output of the command as a string
2465 #
2466 # Since: 0.14.0
2467 #
2468 # Notes: This command only exists as a stop-gap.  Its use is highly
2469 #        discouraged.  The semantics of this command are not
2470 #        guaranteed: this means that command names, arguments and
2471 #        responses can change or be removed at ANY time.  Applications
2472 #        that rely on long term stability guarantees should NOT
2473 #        use this command.
2474 #
2475 #        Known limitations:
2476 #
2477 #        * This command is stateless, this means that commands that depend
2478 #          on state information (such as getfd) might not work
2479 #
2480 #        * Commands that prompt the user for data don't currently work
2481 #
2482 # Example:
2483 #
2484 # -> { "execute": "human-monitor-command",
2485 #      "arguments": { "command-line": "info kvm" } }
2486 # <- { "return": "kvm support: enabled\r\n" }
2487 #
2488 ##
2489 { 'command': 'human-monitor-command',
2490   'data': {'command-line': 'str', '*cpu-index': 'int'},
2491   'returns': 'str' }
2492
2493 ##
2494 # @migrate_cancel:
2495 #
2496 # Cancel the current executing migration process.
2497 #
2498 # Returns: nothing on success
2499 #
2500 # Notes: This command succeeds even if there is no migration process running.
2501 #
2502 # Since: 0.14.0
2503 #
2504 # Example:
2505 #
2506 # -> { "execute": "migrate_cancel" }
2507 # <- { "return": {} }
2508 #
2509 ##
2510 { 'command': 'migrate_cancel' }
2511
2512 ##
2513 # @migrate_set_downtime:
2514 #
2515 # Set maximum tolerated downtime for migration.
2516 #
2517 # @value: maximum downtime in seconds
2518 #
2519 # Returns: nothing on success
2520 #
2521 # Notes: This command is deprecated in favor of 'migrate-set-parameters'
2522 #
2523 # Since: 0.14.0
2524 #
2525 # Example:
2526 #
2527 # -> { "execute": "migrate_set_downtime", "arguments": { "value": 0.1 } }
2528 # <- { "return": {} }
2529 #
2530 ##
2531 { 'command': 'migrate_set_downtime', 'data': {'value': 'number'} }
2532
2533 ##
2534 # @migrate_set_speed:
2535 #
2536 # Set maximum speed for migration.
2537 #
2538 # @value: maximum speed in bytes per second.
2539 #
2540 # Returns: nothing on success
2541 #
2542 # Notes: This command is deprecated in favor of 'migrate-set-parameters'
2543 #
2544 # Since: 0.14.0
2545 #
2546 # Example:
2547 #
2548 # -> { "execute": "migrate_set_speed", "arguments": { "value": 1024 } }
2549 # <- { "return": {} }
2550 #
2551 ##
2552 { 'command': 'migrate_set_speed', 'data': {'value': 'int'} }
2553
2554 ##
2555 # @migrate-set-cache-size:
2556 #
2557 # Set cache size to be used by XBZRLE migration
2558 #
2559 # @value: cache size in bytes
2560 #
2561 # The size will be rounded down to the nearest power of 2.
2562 # The cache size can be modified before and during ongoing migration
2563 #
2564 # Returns: nothing on success
2565 #
2566 # Since: 1.2
2567 #
2568 # Example:
2569 #
2570 # -> { "execute": "migrate-set-cache-size",
2571 #      "arguments": { "value": 536870912 } }
2572 # <- { "return": {} }
2573 #
2574 ##
2575 { 'command': 'migrate-set-cache-size', 'data': {'value': 'int'} }
2576
2577 ##
2578 # @query-migrate-cache-size:
2579 #
2580 # Query migration XBZRLE cache size
2581 #
2582 # Returns: XBZRLE cache size in bytes
2583 #
2584 # Since: 1.2
2585 #
2586 # Example:
2587 #
2588 # -> { "execute": "query-migrate-cache-size" }
2589 # <- { "return": 67108864 }
2590 #
2591 ##
2592 { 'command': 'query-migrate-cache-size', 'returns': 'int' }
2593
2594 ##
2595 # @ObjectPropertyInfo:
2596 #
2597 # @name: the name of the property
2598 #
2599 # @type: the type of the property.  This will typically come in one of four
2600 #        forms:
2601 #
2602 #        1) A primitive type such as 'u8', 'u16', 'bool', 'str', or 'double'.
2603 #           These types are mapped to the appropriate JSON type.
2604 #
2605 #        2) A child type in the form 'child<subtype>' where subtype is a qdev
2606 #           device type name.  Child properties create the composition tree.
2607 #
2608 #        3) A link type in the form 'link<subtype>' where subtype is a qdev
2609 #           device type name.  Link properties form the device model graph.
2610 #
2611 # Since: 1.2
2612 ##
2613 { 'struct': 'ObjectPropertyInfo',
2614   'data': { 'name': 'str', 'type': 'str' } }
2615
2616 ##
2617 # @qom-list:
2618 #
2619 # This command will list any properties of a object given a path in the object
2620 # model.
2621 #
2622 # @path: the path within the object model.  See @qom-get for a description of
2623 #        this parameter.
2624 #
2625 # Returns: a list of @ObjectPropertyInfo that describe the properties of the
2626 #          object.
2627 #
2628 # Since: 1.2
2629 ##
2630 { 'command': 'qom-list',
2631   'data': { 'path': 'str' },
2632   'returns': [ 'ObjectPropertyInfo' ] }
2633
2634 ##
2635 # @qom-get:
2636 #
2637 # This command will get a property from a object model path and return the
2638 # value.
2639 #
2640 # @path: The path within the object model.  There are two forms of supported
2641 #        paths--absolute and partial paths.
2642 #
2643 #        Absolute paths are derived from the root object and can follow child<>
2644 #        or link<> properties.  Since they can follow link<> properties, they
2645 #        can be arbitrarily long.  Absolute paths look like absolute filenames
2646 #        and are prefixed  with a leading slash.
2647 #
2648 #        Partial paths look like relative filenames.  They do not begin
2649 #        with a prefix.  The matching rules for partial paths are subtle but
2650 #        designed to make specifying objects easy.  At each level of the
2651 #        composition tree, the partial path is matched as an absolute path.
2652 #        The first match is not returned.  At least two matches are searched
2653 #        for.  A successful result is only returned if only one match is
2654 #        found.  If more than one match is found, a flag is return to
2655 #        indicate that the match was ambiguous.
2656 #
2657 # @property: The property name to read
2658 #
2659 # Returns: The property value.  The type depends on the property
2660 #          type. child<> and link<> properties are returned as #str
2661 #          pathnames.  All integer property types (u8, u16, etc) are
2662 #          returned as #int.
2663 #
2664 # Since: 1.2
2665 ##
2666 { 'command': 'qom-get',
2667   'data': { 'path': 'str', 'property': 'str' },
2668   'returns': 'any' }
2669
2670 ##
2671 # @qom-set:
2672 #
2673 # This command will set a property from a object model path.
2674 #
2675 # @path: see @qom-get for a description of this parameter
2676 #
2677 # @property: the property name to set
2678 #
2679 # @value: a value who's type is appropriate for the property type.  See @qom-get
2680 #         for a description of type mapping.
2681 #
2682 # Since: 1.2
2683 ##
2684 { 'command': 'qom-set',
2685   'data': { 'path': 'str', 'property': 'str', 'value': 'any' } }
2686
2687 ##
2688 # @set_password:
2689 #
2690 # Sets the password of a remote display session.
2691 #
2692 # @protocol: `vnc' to modify the VNC server password
2693 #            `spice' to modify the Spice server password
2694 #
2695 # @password: the new password
2696 #
2697 # @connected: how to handle existing clients when changing the
2698 #                       password.  If nothing is specified, defaults to `keep'
2699 #                       `fail' to fail the command if clients are connected
2700 #                       `disconnect' to disconnect existing clients
2701 #                       `keep' to maintain existing clients
2702 #
2703 # Returns: Nothing on success
2704 #          If Spice is not enabled, DeviceNotFound
2705 #
2706 # Since: 0.14.0
2707 #
2708 # Example:
2709 #
2710 # -> { "execute": "set_password", "arguments": { "protocol": "vnc",
2711 #                                                "password": "secret" } }
2712 # <- { "return": {} }
2713 #
2714 ##
2715 { 'command': 'set_password',
2716   'data': {'protocol': 'str', 'password': 'str', '*connected': 'str'} }
2717
2718 ##
2719 # @expire_password:
2720 #
2721 # Expire the password of a remote display server.
2722 #
2723 # @protocol: the name of the remote display protocol `vnc' or `spice'
2724 #
2725 # @time: when to expire the password.
2726 #        `now' to expire the password immediately
2727 #        `never' to cancel password expiration
2728 #        `+INT' where INT is the number of seconds from now (integer)
2729 #        `INT' where INT is the absolute time in seconds
2730 #
2731 # Returns: Nothing on success
2732 #          If @protocol is `spice' and Spice is not active, DeviceNotFound
2733 #
2734 # Since: 0.14.0
2735 #
2736 # Notes: Time is relative to the server and currently there is no way to
2737 #        coordinate server time with client time.  It is not recommended to
2738 #        use the absolute time version of the @time parameter unless you're
2739 #        sure you are on the same machine as the QEMU instance.
2740 #
2741 # Example:
2742 #
2743 # -> { "execute": "expire_password", "arguments": { "protocol": "vnc",
2744 #                                                   "time": "+60" } }
2745 # <- { "return": {} }
2746 #
2747 ##
2748 { 'command': 'expire_password', 'data': {'protocol': 'str', 'time': 'str'} }
2749
2750 ##
2751 # @change-vnc-password:
2752 #
2753 # Change the VNC server password.
2754 #
2755 # @password:  the new password to use with VNC authentication
2756 #
2757 # Since: 1.1
2758 #
2759 # Notes:  An empty password in this command will set the password to the empty
2760 #         string.  Existing clients are unaffected by executing this command.
2761 ##
2762 { 'command': 'change-vnc-password', 'data': {'password': 'str'} }
2763
2764 ##
2765 # @change:
2766 #
2767 # This command is multiple commands multiplexed together.
2768 #
2769 # @device: This is normally the name of a block device but it may also be 'vnc'.
2770 #          when it's 'vnc', then sub command depends on @target
2771 #
2772 # @target: If @device is a block device, then this is the new filename.
2773 #          If @device is 'vnc', then if the value 'password' selects the vnc
2774 #          change password command.   Otherwise, this specifies a new server URI
2775 #          address to listen to for VNC connections.
2776 #
2777 # @arg:    If @device is a block device, then this is an optional format to open
2778 #          the device with.
2779 #          If @device is 'vnc' and @target is 'password', this is the new VNC
2780 #          password to set.  See change-vnc-password for additional notes.
2781 #
2782 # Returns: Nothing on success.
2783 #          If @device is not a valid block device, DeviceNotFound
2784 #
2785 # Notes:  This interface is deprecated, and it is strongly recommended that you
2786 #         avoid using it.  For changing block devices, use
2787 #         blockdev-change-medium; for changing VNC parameters, use
2788 #         change-vnc-password.
2789 #
2790 # Since: 0.14.0
2791 #
2792 # Example:
2793 #
2794 # 1. Change a removable medium
2795 #
2796 # -> { "execute": "change",
2797 #      "arguments": { "device": "ide1-cd0",
2798 #                     "target": "/srv/images/Fedora-12-x86_64-DVD.iso" } }
2799 # <- { "return": {} }
2800 #
2801 # 2. Change VNC password
2802 #
2803 # -> { "execute": "change",
2804 #      "arguments": { "device": "vnc", "target": "password",
2805 #                     "arg": "foobar1" } }
2806 # <- { "return": {} }
2807 #
2808 ##
2809 { 'command': 'change',
2810   'data': {'device': 'str', 'target': 'str', '*arg': 'str'} }
2811
2812 ##
2813 # @ObjectTypeInfo:
2814 #
2815 # This structure describes a search result from @qom-list-types
2816 #
2817 # @name: the type name found in the search
2818 #
2819 # @abstract: the type is abstract and can't be directly instantiated.
2820 #            Omitted if false. (since 2.10)
2821 #
2822 # @parent: Name of parent type, if any (since 2.10)
2823 #
2824 # Since: 1.1
2825 ##
2826 { 'struct': 'ObjectTypeInfo',
2827   'data': { 'name': 'str', '*abstract': 'bool', '*parent': 'str' } }
2828
2829 ##
2830 # @qom-list-types:
2831 #
2832 # This command will return a list of types given search parameters
2833 #
2834 # @implements: if specified, only return types that implement this type name
2835 #
2836 # @abstract: if true, include abstract types in the results
2837 #
2838 # Returns: a list of @ObjectTypeInfo or an empty list if no results are found
2839 #
2840 # Since: 1.1
2841 ##
2842 { 'command': 'qom-list-types',
2843   'data': { '*implements': 'str', '*abstract': 'bool' },
2844   'returns': [ 'ObjectTypeInfo' ] }
2845
2846 ##
2847 # @DevicePropertyInfo:
2848 #
2849 # Information about device properties.
2850 #
2851 # @name: the name of the property
2852 # @type: the typename of the property
2853 # @description: if specified, the description of the property.
2854 #               (since 2.2)
2855 #
2856 # Since: 1.2
2857 ##
2858 { 'struct': 'DevicePropertyInfo',
2859   'data': { 'name': 'str', 'type': 'str', '*description': 'str' } }
2860
2861 ##
2862 # @device-list-properties:
2863 #
2864 # List properties associated with a device.
2865 #
2866 # @typename: the type name of a device
2867 #
2868 # Returns: a list of DevicePropertyInfo describing a devices properties
2869 #
2870 # Since: 1.2
2871 ##
2872 { 'command': 'device-list-properties',
2873   'data': { 'typename': 'str'},
2874   'returns': [ 'DevicePropertyInfo' ] }
2875
2876 ##
2877 # @migrate:
2878 #
2879 # Migrates the current running guest to another Virtual Machine.
2880 #
2881 # @uri: the Uniform Resource Identifier of the destination VM
2882 #
2883 # @blk: do block migration (full disk copy)
2884 #
2885 # @inc: incremental disk copy migration
2886 #
2887 # @detach: this argument exists only for compatibility reasons and
2888 #          is ignored by QEMU
2889 #
2890 # Returns: nothing on success
2891 #
2892 # Since: 0.14.0
2893 #
2894 # Notes:
2895 #
2896 # 1. The 'query-migrate' command should be used to check migration's progress
2897 #    and final result (this information is provided by the 'status' member)
2898 #
2899 # 2. All boolean arguments default to false
2900 #
2901 # 3. The user Monitor's "detach" argument is invalid in QMP and should not
2902 #    be used
2903 #
2904 # Example:
2905 #
2906 # -> { "execute": "migrate", "arguments": { "uri": "tcp:0:4446" } }
2907 # <- { "return": {} }
2908 #
2909 ##
2910 { 'command': 'migrate',
2911   'data': {'uri': 'str', '*blk': 'bool', '*inc': 'bool', '*detach': 'bool' } }
2912
2913 ##
2914 # @migrate-incoming:
2915 #
2916 # Start an incoming migration, the qemu must have been started
2917 # with -incoming defer
2918 #
2919 # @uri: The Uniform Resource Identifier identifying the source or
2920 #       address to listen on
2921 #
2922 # Returns: nothing on success
2923 #
2924 # Since: 2.3
2925 #
2926 # Notes:
2927 #
2928 # 1. It's a bad idea to use a string for the uri, but it needs to stay
2929 #    compatible with -incoming and the format of the uri is already exposed
2930 #    above libvirt.
2931 #
2932 # 2. QEMU must be started with -incoming defer to allow migrate-incoming to
2933 #    be used.
2934 #
2935 # 3. The uri format is the same as for -incoming
2936 #
2937 # Example:
2938 #
2939 # -> { "execute": "migrate-incoming",
2940 #      "arguments": { "uri": "tcp::4446" } }
2941 # <- { "return": {} }
2942 #
2943 ##
2944 { 'command': 'migrate-incoming', 'data': {'uri': 'str' } }
2945
2946 ##
2947 # @xen-save-devices-state:
2948 #
2949 # Save the state of all devices to file. The RAM and the block devices
2950 # of the VM are not saved by this command.
2951 #
2952 # @filename: the file to save the state of the devices to as binary
2953 # data. See xen-save-devices-state.txt for a description of the binary
2954 # format.
2955 #
2956 # Returns: Nothing on success
2957 #
2958 # Since: 1.1
2959 #
2960 # Example:
2961 #
2962 # -> { "execute": "xen-save-devices-state",
2963 #      "arguments": { "filename": "/tmp/save" } }
2964 # <- { "return": {} }
2965 #
2966 ##
2967 { 'command': 'xen-save-devices-state', 'data': {'filename': 'str'} }
2968
2969 ##
2970 # @xen-set-global-dirty-log:
2971 #
2972 # Enable or disable the global dirty log mode.
2973 #
2974 # @enable: true to enable, false to disable.
2975 #
2976 # Returns: nothing
2977 #
2978 # Since: 1.3
2979 #
2980 # Example:
2981 #
2982 # -> { "execute": "xen-set-global-dirty-log",
2983 #      "arguments": { "enable": true } }
2984 # <- { "return": {} }
2985 #
2986 ##
2987 { 'command': 'xen-set-global-dirty-log', 'data': { 'enable': 'bool' } }
2988
2989 ##
2990 # @device_add:
2991 #
2992 # @driver: the name of the new device's driver
2993 #
2994 # @bus: the device's parent bus (device tree path)
2995 #
2996 # @id: the device's ID, must be unique
2997 #
2998 # Additional arguments depend on the type.
2999 #
3000 # Add a device.
3001 #
3002 # Notes:
3003 # 1. For detailed information about this command, please refer to the
3004 #    'docs/qdev-device-use.txt' file.
3005 #
3006 # 2. It's possible to list device properties by running QEMU with the
3007 #    "-device DEVICE,help" command-line argument, where DEVICE is the
3008 #    device's name
3009 #
3010 # Example:
3011 #
3012 # -> { "execute": "device_add",
3013 #      "arguments": { "driver": "e1000", "id": "net1",
3014 #                     "bus": "pci.0",
3015 #                     "mac": "52:54:00:12:34:56" } }
3016 # <- { "return": {} }
3017 #
3018 # TODO: This command effectively bypasses QAPI completely due to its
3019 # "additional arguments" business.  It shouldn't have been added to
3020 # the schema in this form.  It should be qapified properly, or
3021 # replaced by a properly qapified command.
3022 #
3023 # Since: 0.13
3024 ##
3025 { 'command': 'device_add',
3026   'data': {'driver': 'str', '*bus': 'str', '*id': 'str'},
3027   'gen': false } # so we can get the additional arguments
3028
3029 ##
3030 # @device_del:
3031 #
3032 # Remove a device from a guest
3033 #
3034 # @id: the device's ID or QOM path
3035 #
3036 # Returns: Nothing on success
3037 #          If @id is not a valid device, DeviceNotFound
3038 #
3039 # Notes: When this command completes, the device may not be removed from the
3040 #        guest.  Hot removal is an operation that requires guest cooperation.
3041 #        This command merely requests that the guest begin the hot removal
3042 #        process.  Completion of the device removal process is signaled with a
3043 #        DEVICE_DELETED event. Guest reset will automatically complete removal
3044 #        for all devices.
3045 #
3046 # Since: 0.14.0
3047 #
3048 # Example:
3049 #
3050 # -> { "execute": "device_del",
3051 #      "arguments": { "id": "net1" } }
3052 # <- { "return": {} }
3053 #
3054 # -> { "execute": "device_del",
3055 #      "arguments": { "id": "/machine/peripheral-anon/device[0]" } }
3056 # <- { "return": {} }
3057 #
3058 ##
3059 { 'command': 'device_del', 'data': {'id': 'str'} }
3060
3061 ##
3062 # @DumpGuestMemoryFormat:
3063 #
3064 # An enumeration of guest-memory-dump's format.
3065 #
3066 # @elf: elf format
3067 #
3068 # @kdump-zlib: kdump-compressed format with zlib-compressed
3069 #
3070 # @kdump-lzo: kdump-compressed format with lzo-compressed
3071 #
3072 # @kdump-snappy: kdump-compressed format with snappy-compressed
3073 #
3074 # Since: 2.0
3075 ##
3076 { 'enum': 'DumpGuestMemoryFormat',
3077   'data': [ 'elf', 'kdump-zlib', 'kdump-lzo', 'kdump-snappy' ] }
3078
3079 ##
3080 # @dump-guest-memory:
3081 #
3082 # Dump guest's memory to vmcore. It is a synchronous operation that can take
3083 # very long depending on the amount of guest memory.
3084 #
3085 # @paging: if true, do paging to get guest's memory mapping. This allows
3086 #          using gdb to process the core file.
3087 #
3088 #          IMPORTANT: this option can make QEMU allocate several gigabytes
3089 #                     of RAM. This can happen for a large guest, or a
3090 #                     malicious guest pretending to be large.
3091 #
3092 #          Also, paging=true has the following limitations:
3093 #
3094 #             1. The guest may be in a catastrophic state or can have corrupted
3095 #                memory, which cannot be trusted
3096 #             2. The guest can be in real-mode even if paging is enabled. For
3097 #                example, the guest uses ACPI to sleep, and ACPI sleep state
3098 #                goes in real-mode
3099 #             3. Currently only supported on i386 and x86_64.
3100 #
3101 # @protocol: the filename or file descriptor of the vmcore. The supported
3102 #            protocols are:
3103 #
3104 #            1. file: the protocol starts with "file:", and the following
3105 #               string is the file's path.
3106 #            2. fd: the protocol starts with "fd:", and the following string
3107 #               is the fd's name.
3108 #
3109 # @detach: if true, QMP will return immediately rather than
3110 #          waiting for the dump to finish. The user can track progress
3111 #          using "query-dump". (since 2.6).
3112 #
3113 # @begin: if specified, the starting physical address.
3114 #
3115 # @length: if specified, the memory size, in bytes. If you don't
3116 #          want to dump all guest's memory, please specify the start @begin
3117 #          and @length
3118 #
3119 # @format: if specified, the format of guest memory dump. But non-elf
3120 #          format is conflict with paging and filter, ie. @paging, @begin and
3121 #          @length is not allowed to be specified with non-elf @format at the
3122 #          same time (since 2.0)
3123 #
3124 # Note: All boolean arguments default to false
3125 #
3126 # Returns: nothing on success
3127 #
3128 # Since: 1.2
3129 #
3130 # Example:
3131 #
3132 # -> { "execute": "dump-guest-memory",
3133 #      "arguments": { "protocol": "fd:dump" } }
3134 # <- { "return": {} }
3135 #
3136 ##
3137 { 'command': 'dump-guest-memory',
3138   'data': { 'paging': 'bool', 'protocol': 'str', '*detach': 'bool',
3139             '*begin': 'int', '*length': 'int',
3140             '*format': 'DumpGuestMemoryFormat'} }
3141
3142 ##
3143 # @DumpStatus:
3144 #
3145 # Describe the status of a long-running background guest memory dump.
3146 #
3147 # @none: no dump-guest-memory has started yet.
3148 #
3149 # @active: there is one dump running in background.
3150 #
3151 # @completed: the last dump has finished successfully.
3152 #
3153 # @failed: the last dump has failed.
3154 #
3155 # Since: 2.6
3156 ##
3157 { 'enum': 'DumpStatus',
3158   'data': [ 'none', 'active', 'completed', 'failed' ] }
3159
3160 ##
3161 # @DumpQueryResult:
3162 #
3163 # The result format for 'query-dump'.
3164 #
3165 # @status: enum of @DumpStatus, which shows current dump status
3166 #
3167 # @completed: bytes written in latest dump (uncompressed)
3168 #
3169 # @total: total bytes to be written in latest dump (uncompressed)
3170 #
3171 # Since: 2.6
3172 ##
3173 { 'struct': 'DumpQueryResult',
3174   'data': { 'status': 'DumpStatus',
3175             'completed': 'int',
3176             'total': 'int' } }
3177
3178 ##
3179 # @query-dump:
3180 #
3181 # Query latest dump status.
3182 #
3183 # Returns: A @DumpStatus object showing the dump status.
3184 #
3185 # Since: 2.6
3186 #
3187 # Example:
3188 #
3189 # -> { "execute": "query-dump" }
3190 # <- { "return": { "status": "active", "completed": 1024000,
3191 #                  "total": 2048000 } }
3192 #
3193 ##
3194 { 'command': 'query-dump', 'returns': 'DumpQueryResult' }
3195
3196 ##
3197 # @DumpGuestMemoryCapability:
3198 #
3199 # A list of the available formats for dump-guest-memory
3200 #
3201 # Since: 2.0
3202 ##
3203 { 'struct': 'DumpGuestMemoryCapability',
3204   'data': {
3205       'formats': ['DumpGuestMemoryFormat'] } }
3206
3207 ##
3208 # @query-dump-guest-memory-capability:
3209 #
3210 # Returns the available formats for dump-guest-memory
3211 #
3212 # Returns:  A @DumpGuestMemoryCapability object listing available formats for
3213 #           dump-guest-memory
3214 #
3215 # Since: 2.0
3216 #
3217 # Example:
3218 #
3219 # -> { "execute": "query-dump-guest-memory-capability" }
3220 # <- { "return": { "formats":
3221 #                  ["elf", "kdump-zlib", "kdump-lzo", "kdump-snappy"] }
3222 #
3223 ##
3224 { 'command': 'query-dump-guest-memory-capability',
3225   'returns': 'DumpGuestMemoryCapability' }
3226
3227 ##
3228 # @dump-skeys:
3229 #
3230 # Dump guest's storage keys
3231 #
3232 # @filename: the path to the file to dump to
3233 #
3234 # This command is only supported on s390 architecture.
3235 #
3236 # Since: 2.5
3237 #
3238 # Example:
3239 #
3240 # -> { "execute": "dump-skeys",
3241 #      "arguments": { "filename": "/tmp/skeys" } }
3242 # <- { "return": {} }
3243 #
3244 ##
3245 { 'command': 'dump-skeys',
3246   'data': { 'filename': 'str' } }
3247
3248 ##
3249 # @object-add:
3250 #
3251 # Create a QOM object.
3252 #
3253 # @qom-type: the class name for the object to be created
3254 #
3255 # @id: the name of the new object
3256 #
3257 # @props: a dictionary of properties to be passed to the backend
3258 #
3259 # Returns: Nothing on success
3260 #          Error if @qom-type is not a valid class name
3261 #
3262 # Since: 2.0
3263 #
3264 # Example:
3265 #
3266 # -> { "execute": "object-add",
3267 #      "arguments": { "qom-type": "rng-random", "id": "rng1",
3268 #                     "props": { "filename": "/dev/hwrng" } } }
3269 # <- { "return": {} }
3270 #
3271 ##
3272 { 'command': 'object-add',
3273   'data': {'qom-type': 'str', 'id': 'str', '*props': 'any'} }
3274
3275 ##
3276 # @object-del:
3277 #
3278 # Remove a QOM object.
3279 #
3280 # @id: the name of the QOM object to remove
3281 #
3282 # Returns: Nothing on success
3283 #          Error if @id is not a valid id for a QOM object
3284 #
3285 # Since: 2.0
3286 #
3287 # Example:
3288 #
3289 # -> { "execute": "object-del", "arguments": { "id": "rng1" } }
3290 # <- { "return": {} }
3291 #
3292 ##
3293 { 'command': 'object-del', 'data': {'id': 'str'} }
3294
3295 ##
3296 # @getfd:
3297 #
3298 # Receive a file descriptor via SCM rights and assign it a name
3299 #
3300 # @fdname: file descriptor name
3301 #
3302 # Returns: Nothing on success
3303 #
3304 # Since: 0.14.0
3305 #
3306 # Notes: If @fdname already exists, the file descriptor assigned to
3307 #        it will be closed and replaced by the received file
3308 #        descriptor.
3309 #
3310 #        The 'closefd' command can be used to explicitly close the
3311 #        file descriptor when it is no longer needed.
3312 #
3313 # Example:
3314 #
3315 # -> { "execute": "getfd", "arguments": { "fdname": "fd1" } }
3316 # <- { "return": {} }
3317 #
3318 ##
3319 { 'command': 'getfd', 'data': {'fdname': 'str'} }
3320
3321 ##
3322 # @closefd:
3323 #
3324 # Close a file descriptor previously passed via SCM rights
3325 #
3326 # @fdname: file descriptor name
3327 #
3328 # Returns: Nothing on success
3329 #
3330 # Since: 0.14.0
3331 #
3332 # Example:
3333 #
3334 # -> { "execute": "closefd", "arguments": { "fdname": "fd1" } }
3335 # <- { "return": {} }
3336 #
3337 ##
3338 { 'command': 'closefd', 'data': {'fdname': 'str'} }
3339
3340 ##
3341 # @MachineInfo:
3342 #
3343 # Information describing a machine.
3344 #
3345 # @name: the name of the machine
3346 #
3347 # @alias: an alias for the machine name
3348 #
3349 # @is-default: whether the machine is default
3350 #
3351 # @cpu-max: maximum number of CPUs supported by the machine type
3352 #           (since 1.5.0)
3353 #
3354 # @hotpluggable-cpus: cpu hotplug via -device is supported (since 2.7.0)
3355 #
3356 # Since: 1.2.0
3357 ##
3358 { 'struct': 'MachineInfo',
3359   'data': { 'name': 'str', '*alias': 'str',
3360             '*is-default': 'bool', 'cpu-max': 'int',
3361             'hotpluggable-cpus': 'bool'} }
3362
3363 ##
3364 # @query-machines:
3365 #
3366 # Return a list of supported machines
3367 #
3368 # Returns: a list of MachineInfo
3369 #
3370 # Since: 1.2.0
3371 ##
3372 { 'command': 'query-machines', 'returns': ['MachineInfo'] }
3373
3374 ##
3375 # @CpuDefinitionInfo:
3376 #
3377 # Virtual CPU definition.
3378 #
3379 # @name: the name of the CPU definition
3380 #
3381 # @migration-safe: whether a CPU definition can be safely used for
3382 #                  migration in combination with a QEMU compatibility machine
3383 #                  when migrating between different QMU versions and between
3384 #                  hosts with different sets of (hardware or software)
3385 #                  capabilities. If not provided, information is not available
3386 #                  and callers should not assume the CPU definition to be
3387 #                  migration-safe. (since 2.8)
3388 #
3389 # @static: whether a CPU definition is static and will not change depending on
3390 #          QEMU version, machine type, machine options and accelerator options.
3391 #          A static model is always migration-safe. (since 2.8)
3392 #
3393 # @unavailable-features: List of properties that prevent
3394 #                        the CPU model from running in the current
3395 #                        host. (since 2.8)
3396 # @typename: Type name that can be used as argument to @device-list-properties,
3397 #            to introspect properties configurable using -cpu or -global.
3398 #            (since 2.9)
3399 #
3400 # @unavailable-features is a list of QOM property names that
3401 # represent CPU model attributes that prevent the CPU from running.
3402 # If the QOM property is read-only, that means there's no known
3403 # way to make the CPU model run in the current host. Implementations
3404 # that choose not to provide specific information return the
3405 # property name "type".
3406 # If the property is read-write, it means that it MAY be possible
3407 # to run the CPU model in the current host if that property is
3408 # changed. Management software can use it as hints to suggest or
3409 # choose an alternative for the user, or just to generate meaningful
3410 # error messages explaining why the CPU model can't be used.
3411 # If @unavailable-features is an empty list, the CPU model is
3412 # runnable using the current host and machine-type.
3413 # If @unavailable-features is not present, runnability
3414 # information for the CPU is not available.
3415 #
3416 # Since: 1.2.0
3417 ##
3418 { 'struct': 'CpuDefinitionInfo',
3419   'data': { 'name': 'str', '*migration-safe': 'bool', 'static': 'bool',
3420             '*unavailable-features': [ 'str' ], 'typename': 'str' } }
3421
3422 ##
3423 # @query-cpu-definitions:
3424 #
3425 # Return a list of supported virtual CPU definitions
3426 #
3427 # Returns: a list of CpuDefInfo
3428 #
3429 # Since: 1.2.0
3430 ##
3431 { 'command': 'query-cpu-definitions', 'returns': ['CpuDefinitionInfo'] }
3432
3433 ##
3434 # @CpuModelInfo:
3435 #
3436 # Virtual CPU model.
3437 #
3438 # A CPU model consists of the name of a CPU definition, to which
3439 # delta changes are applied (e.g. features added/removed). Most magic values
3440 # that an architecture might require should be hidden behind the name.
3441 # However, if required, architectures can expose relevant properties.
3442 #
3443 # @name: the name of the CPU definition the model is based on
3444 # @props: a dictionary of QOM properties to be applied
3445 #
3446 # Since: 2.8.0
3447 ##
3448 { 'struct': 'CpuModelInfo',
3449   'data': { 'name': 'str',
3450             '*props': 'any' } }
3451
3452 ##
3453 # @CpuModelExpansionType:
3454 #
3455 # An enumeration of CPU model expansion types.
3456 #
3457 # @static: Expand to a static CPU model, a combination of a static base
3458 #          model name and property delta changes. As the static base model will
3459 #          never change, the expanded CPU model will be the same, independant of
3460 #          independent of QEMU version, machine type, machine options, and
3461 #          accelerator options. Therefore, the resulting model can be used by
3462 #          tooling without having to specify a compatibility machine - e.g. when
3463 #          displaying the "host" model. static CPU models are migration-safe.
3464 #
3465 # @full: Expand all properties. The produced model is not guaranteed to be
3466 #        migration-safe, but allows tooling to get an insight and work with
3467 #        model details.
3468 #
3469 # Note: When a non-migration-safe CPU model is expanded in static mode, some
3470 # features enabled by the CPU model may be omitted, because they can't be
3471 # implemented by a static CPU model definition (e.g. cache info passthrough and
3472 # PMU passthrough in x86). If you need an accurate representation of the
3473 # features enabled by a non-migration-safe CPU model, use @full. If you need a
3474 # static representation that will keep ABI compatibility even when changing QEMU
3475 # version or machine-type, use @static (but keep in mind that some features may
3476 # be omitted).
3477 #
3478 # Since: 2.8.0
3479 ##
3480 { 'enum': 'CpuModelExpansionType',
3481   'data': [ 'static', 'full' ] }
3482
3483
3484 ##
3485 # @CpuModelExpansionInfo:
3486 #
3487 # The result of a cpu model expansion.
3488 #
3489 # @model: the expanded CpuModelInfo.
3490 #
3491 # Since: 2.8.0
3492 ##
3493 { 'struct': 'CpuModelExpansionInfo',
3494   'data': { 'model': 'CpuModelInfo' } }
3495
3496
3497 ##
3498 # @query-cpu-model-expansion:
3499 #
3500 # Expands a given CPU model (or a combination of CPU model + additional options)
3501 # to different granularities, allowing tooling to get an understanding what a
3502 # specific CPU model looks like in QEMU under a certain configuration.
3503 #
3504 # This interface can be used to query the "host" CPU model.
3505 #
3506 # The data returned by this command may be affected by:
3507 #
3508 # * QEMU version: CPU models may look different depending on the QEMU version.
3509 #   (Except for CPU models reported as "static" in query-cpu-definitions.)
3510 # * machine-type: CPU model  may look different depending on the machine-type.
3511 #   (Except for CPU models reported as "static" in query-cpu-definitions.)
3512 # * machine options (including accelerator): in some architectures, CPU models
3513 #   may look different depending on machine and accelerator options. (Except for
3514 #   CPU models reported as "static" in query-cpu-definitions.)
3515 # * "-cpu" arguments and global properties: arguments to the -cpu option and
3516 #   global properties may affect expansion of CPU models. Using
3517 #   query-cpu-model-expansion while using these is not advised.
3518 #
3519 # Some architectures may not support all expansion types. s390x supports
3520 # "full" and "static".
3521 #
3522 # Returns: a CpuModelExpansionInfo. Returns an error if expanding CPU models is
3523 #          not supported, if the model cannot be expanded, if the model contains
3524 #          an unknown CPU definition name, unknown properties or properties
3525 #          with a wrong type. Also returns an error if an expansion type is
3526 #          not supported.
3527 #
3528 # Since: 2.8.0
3529 ##
3530 { 'command': 'query-cpu-model-expansion',
3531   'data': { 'type': 'CpuModelExpansionType',
3532             'model': 'CpuModelInfo' },
3533   'returns': 'CpuModelExpansionInfo' }
3534
3535 ##
3536 # @CpuModelCompareResult:
3537 #
3538 # An enumeration of CPU model comparation results. The result is usually
3539 # calculated using e.g. CPU features or CPU generations.
3540 #
3541 # @incompatible: If model A is incompatible to model B, model A is not
3542 #                guaranteed to run where model B runs and the other way around.
3543 #
3544 # @identical: If model A is identical to model B, model A is guaranteed to run
3545 #             where model B runs and the other way around.
3546 #
3547 # @superset: If model A is a superset of model B, model B is guaranteed to run
3548 #            where model A runs. There are no guarantees about the other way.
3549 #
3550 # @subset: If model A is a subset of model B, model A is guaranteed to run
3551 #          where model B runs. There are no guarantees about the other way.
3552 #
3553 # Since: 2.8.0
3554 ##
3555 { 'enum': 'CpuModelCompareResult',
3556   'data': [ 'incompatible', 'identical', 'superset', 'subset' ] }
3557
3558 ##
3559 # @CpuModelCompareInfo:
3560 #
3561 # The result of a CPU model comparison.
3562 #
3563 # @result: The result of the compare operation.
3564 # @responsible-properties: List of properties that led to the comparison result
3565 #                          not being identical.
3566 #
3567 # @responsible-properties is a list of QOM property names that led to
3568 # both CPUs not being detected as identical. For identical models, this
3569 # list is empty.
3570 # If a QOM property is read-only, that means there's no known way to make the
3571 # CPU models identical. If the special property name "type" is included, the
3572 # models are by definition not identical and cannot be made identical.
3573 #
3574 # Since: 2.8.0
3575 ##
3576 { 'struct': 'CpuModelCompareInfo',
3577   'data': {'result': 'CpuModelCompareResult',
3578            'responsible-properties': ['str']
3579           }
3580 }
3581
3582 ##
3583 # @query-cpu-model-comparison:
3584 #
3585 # Compares two CPU models, returning how they compare in a specific
3586 # configuration. The results indicates how both models compare regarding
3587 # runnability. This result can be used by tooling to make decisions if a
3588 # certain CPU model will run in a certain configuration or if a compatible
3589 # CPU model has to be created by baselining.
3590 #
3591 # Usually, a CPU model is compared against the maximum possible CPU model
3592 # of a certain configuration (e.g. the "host" model for KVM). If that CPU
3593 # model is identical or a subset, it will run in that configuration.
3594 #
3595 # The result returned by this command may be affected by:
3596 #
3597 # * QEMU version: CPU models may look different depending on the QEMU version.
3598 #   (Except for CPU models reported as "static" in query-cpu-definitions.)
3599 # * machine-type: CPU model may look different depending on the machine-type.
3600 #   (Except for CPU models reported as "static" in query-cpu-definitions.)
3601 # * machine options (including accelerator): in some architectures, CPU models
3602 #   may look different depending on machine and accelerator options. (Except for
3603 #   CPU models reported as "static" in query-cpu-definitions.)
3604 # * "-cpu" arguments and global properties: arguments to the -cpu option and
3605 #   global properties may affect expansion of CPU models. Using
3606 #   query-cpu-model-expansion while using these is not advised.
3607 #
3608 # Some architectures may not support comparing CPU models. s390x supports
3609 # comparing CPU models.
3610 #
3611 # Returns: a CpuModelBaselineInfo. Returns an error if comparing CPU models is
3612 #          not supported, if a model cannot be used, if a model contains
3613 #          an unknown cpu definition name, unknown properties or properties
3614 #          with wrong types.
3615 #
3616 # Since: 2.8.0
3617 ##
3618 { 'command': 'query-cpu-model-comparison',
3619   'data': { 'modela': 'CpuModelInfo', 'modelb': 'CpuModelInfo' },
3620   'returns': 'CpuModelCompareInfo' }
3621
3622 ##
3623 # @CpuModelBaselineInfo:
3624 #
3625 # The result of a CPU model baseline.
3626 #
3627 # @model: the baselined CpuModelInfo.
3628 #
3629 # Since: 2.8.0
3630 ##
3631 { 'struct': 'CpuModelBaselineInfo',
3632   'data': { 'model': 'CpuModelInfo' } }
3633
3634 ##
3635 # @query-cpu-model-baseline:
3636 #
3637 # Baseline two CPU models, creating a compatible third model. The created
3638 # model will always be a static, migration-safe CPU model (see "static"
3639 # CPU model expansion for details).
3640 #
3641 # This interface can be used by tooling to create a compatible CPU model out
3642 # two CPU models. The created CPU model will be identical to or a subset of
3643 # both CPU models when comparing them. Therefore, the created CPU model is
3644 # guaranteed to run where the given CPU models run.
3645 #
3646 # The result returned by this command may be affected by:
3647 #
3648 # * QEMU version: CPU models may look different depending on the QEMU version.
3649 #   (Except for CPU models reported as "static" in query-cpu-definitions.)
3650 # * machine-type: CPU model may look different depending on the machine-type.
3651 #   (Except for CPU models reported as "static" in query-cpu-definitions.)
3652 # * machine options (including accelerator): in some architectures, CPU models
3653 #   may look different depending on machine and accelerator options. (Except for
3654 #   CPU models reported as "static" in query-cpu-definitions.)
3655 # * "-cpu" arguments and global properties: arguments to the -cpu option and
3656 #   global properties may affect expansion of CPU models. Using
3657 #   query-cpu-model-expansion while using these is not advised.
3658 #
3659 # Some architectures may not support baselining CPU models. s390x supports
3660 # baselining CPU models.
3661 #
3662 # Returns: a CpuModelBaselineInfo. Returns an error if baselining CPU models is
3663 #          not supported, if a model cannot be used, if a model contains
3664 #          an unknown cpu definition name, unknown properties or properties
3665 #          with wrong types.
3666 #
3667 # Since: 2.8.0
3668 ##
3669 { 'command': 'query-cpu-model-baseline',
3670   'data': { 'modela': 'CpuModelInfo',
3671             'modelb': 'CpuModelInfo' },
3672   'returns': 'CpuModelBaselineInfo' }
3673
3674 ##
3675 # @AddfdInfo:
3676 #
3677 # Information about a file descriptor that was added to an fd set.
3678 #
3679 # @fdset-id: The ID of the fd set that @fd was added to.
3680 #
3681 # @fd: The file descriptor that was received via SCM rights and
3682 #      added to the fd set.
3683 #
3684 # Since: 1.2.0
3685 ##
3686 { 'struct': 'AddfdInfo', 'data': {'fdset-id': 'int', 'fd': 'int'} }
3687
3688 ##
3689 # @add-fd:
3690 #
3691 # Add a file descriptor, that was passed via SCM rights, to an fd set.
3692 #
3693 # @fdset-id: The ID of the fd set to add the file descriptor to.
3694 #
3695 # @opaque: A free-form string that can be used to describe the fd.
3696 #
3697 # Returns: @AddfdInfo on success
3698 #
3699 #          If file descriptor was not received, FdNotSupplied
3700 #
3701 #          If @fdset-id is a negative value, InvalidParameterValue
3702 #
3703 # Notes: The list of fd sets is shared by all monitor connections.
3704 #
3705 #        If @fdset-id is not specified, a new fd set will be created.
3706 #
3707 # Since: 1.2.0
3708 #
3709 # Example:
3710 #
3711 # -> { "execute": "add-fd", "arguments": { "fdset-id": 1 } }
3712 # <- { "return": { "fdset-id": 1, "fd": 3 } }
3713 #
3714 ##
3715 { 'command': 'add-fd', 'data': {'*fdset-id': 'int', '*opaque': 'str'},
3716   'returns': 'AddfdInfo' }
3717
3718 ##
3719 # @remove-fd:
3720 #
3721 # Remove a file descriptor from an fd set.
3722 #
3723 # @fdset-id: The ID of the fd set that the file descriptor belongs to.
3724 #
3725 # @fd: The file descriptor that is to be removed.
3726 #
3727 # Returns: Nothing on success
3728 #          If @fdset-id or @fd is not found, FdNotFound
3729 #
3730 # Since: 1.2.0
3731 #
3732 # Notes: The list of fd sets is shared by all monitor connections.
3733 #
3734 #        If @fd is not specified, all file descriptors in @fdset-id
3735 #        will be removed.
3736 #
3737 # Example:
3738 #
3739 # -> { "execute": "remove-fd", "arguments": { "fdset-id": 1, "fd": 3 } }
3740 # <- { "return": {} }
3741 #
3742 ##
3743 { 'command': 'remove-fd', 'data': {'fdset-id': 'int', '*fd': 'int'} }
3744
3745 ##
3746 # @FdsetFdInfo:
3747 #
3748 # Information about a file descriptor that belongs to an fd set.
3749 #
3750 # @fd: The file descriptor value.
3751 #
3752 # @opaque: A free-form string that can be used to describe the fd.
3753 #
3754 # Since: 1.2.0
3755 ##
3756 { 'struct': 'FdsetFdInfo',
3757   'data': {'fd': 'int', '*opaque': 'str'} }
3758
3759 ##
3760 # @FdsetInfo:
3761 #
3762 # Information about an fd set.
3763 #
3764 # @fdset-id: The ID of the fd set.
3765 #
3766 # @fds: A list of file descriptors that belong to this fd set.
3767 #
3768 # Since: 1.2.0
3769 ##
3770 { 'struct': 'FdsetInfo',
3771   'data': {'fdset-id': 'int', 'fds': ['FdsetFdInfo']} }
3772
3773 ##
3774 # @query-fdsets:
3775 #
3776 # Return information describing all fd sets.
3777 #
3778 # Returns: A list of @FdsetInfo
3779 #
3780 # Since: 1.2.0
3781 #
3782 # Note: The list of fd sets is shared by all monitor connections.
3783 #
3784 # Example:
3785 #
3786 # -> { "execute": "query-fdsets" }
3787 # <- { "return": [
3788 #        {
3789 #          "fds": [
3790 #            {
3791 #              "fd": 30,
3792 #              "opaque": "rdonly:/path/to/file"
3793 #            },
3794 #            {
3795 #              "fd": 24,
3796 #              "opaque": "rdwr:/path/to/file"
3797 #            }
3798 #          ],
3799 #          "fdset-id": 1
3800 #        },
3801 #        {
3802 #          "fds": [
3803 #            {
3804 #              "fd": 28
3805 #            },
3806 #            {
3807 #              "fd": 29
3808 #            }
3809 #          ],
3810 #          "fdset-id": 0
3811 #        }
3812 #      ]
3813 #    }
3814 #
3815 ##
3816 { 'command': 'query-fdsets', 'returns': ['FdsetInfo'] }
3817
3818 ##
3819 # @TargetInfo:
3820 #
3821 # Information describing the QEMU target.
3822 #
3823 # @arch: the target architecture (eg "x86_64", "i386", etc)
3824 #
3825 # Since: 1.2.0
3826 ##
3827 { 'struct': 'TargetInfo',
3828   'data': { 'arch': 'str' } }
3829
3830 ##
3831 # @query-target:
3832 #
3833 # Return information about the target for this QEMU
3834 #
3835 # Returns: TargetInfo
3836 #
3837 # Since: 1.2.0
3838 ##
3839 { 'command': 'query-target', 'returns': 'TargetInfo' }
3840
3841 ##
3842 # @QKeyCode:
3843 #
3844 # An enumeration of key name.
3845 #
3846 # This is used by the @send-key command.
3847 #
3848 # @unmapped: since 2.0
3849 # @pause: since 2.0
3850 # @ro: since 2.4
3851 # @kp_comma: since 2.4
3852 # @kp_equals: since 2.6
3853 # @power: since 2.6
3854 # @hiragana: since 2.9
3855 # @henkan: since 2.9
3856 # @yen: since 2.9
3857 #
3858 # @sleep: since 2.10
3859 # @wake: since 2.10
3860 # @audionext: since 2.10
3861 # @audioprev: since 2.10
3862 # @audiostop: since 2.10
3863 # @audioplay: since 2.10
3864 # @audiomute: since 2.10
3865 # @volumeup: since 2.10
3866 # @volumedown: since 2.10
3867 # @mediaselect: since 2.10
3868 # @mail: since 2.10
3869 # @calculator: since 2.10
3870 # @computer: since 2.10
3871 # @ac_home: since 2.10
3872 # @ac_back: since 2.10
3873 # @ac_forward: since 2.10
3874 # @ac_refresh: since 2.10
3875 # @ac_bookmarks: since 2.10
3876 # altgr, altgr_r: dropped in 2.10
3877 #
3878 # Since: 1.3.0
3879 #
3880 ##
3881 { 'enum': 'QKeyCode',
3882   'data': [ 'unmapped',
3883             'shift', 'shift_r', 'alt', 'alt_r', 'ctrl',
3884             'ctrl_r', 'menu', 'esc', '1', '2', '3', '4', '5', '6', '7', '8',
3885             '9', '0', 'minus', 'equal', 'backspace', 'tab', 'q', 'w', 'e',
3886             'r', 't', 'y', 'u', 'i', 'o', 'p', 'bracket_left', 'bracket_right',
3887             'ret', 'a', 's', 'd', 'f', 'g', 'h', 'j', 'k', 'l', 'semicolon',
3888             'apostrophe', 'grave_accent', 'backslash', 'z', 'x', 'c', 'v', 'b',
3889             'n', 'm', 'comma', 'dot', 'slash', 'asterisk', 'spc', 'caps_lock',
3890             'f1', 'f2', 'f3', 'f4', 'f5', 'f6', 'f7', 'f8', 'f9', 'f10',
3891             'num_lock', 'scroll_lock', 'kp_divide', 'kp_multiply',
3892             'kp_subtract', 'kp_add', 'kp_enter', 'kp_decimal', 'sysrq', 'kp_0',
3893             'kp_1', 'kp_2', 'kp_3', 'kp_4', 'kp_5', 'kp_6', 'kp_7', 'kp_8',
3894             'kp_9', 'less', 'f11', 'f12', 'print', 'home', 'pgup', 'pgdn', 'end',
3895             'left', 'up', 'down', 'right', 'insert', 'delete', 'stop', 'again',
3896             'props', 'undo', 'front', 'copy', 'open', 'paste', 'find', 'cut',
3897             'lf', 'help', 'meta_l', 'meta_r', 'compose', 'pause',
3898             'ro', 'hiragana', 'henkan', 'yen',
3899             'kp_comma', 'kp_equals', 'power', 'sleep', 'wake',
3900             'audionext', 'audioprev', 'audiostop', 'audioplay', 'audiomute',
3901             'volumeup', 'volumedown', 'mediaselect',
3902             'mail', 'calculator', 'computer',
3903             'ac_home', 'ac_back', 'ac_forward', 'ac_refresh', 'ac_bookmarks' ] }
3904
3905 ##
3906 # @KeyValue:
3907 #
3908 # Represents a keyboard key.
3909 #
3910 # Since: 1.3.0
3911 ##
3912 { 'union': 'KeyValue',
3913   'data': {
3914     'number': 'int',
3915     'qcode': 'QKeyCode' } }
3916
3917 ##
3918 # @send-key:
3919 #
3920 # Send keys to guest.
3921 #
3922 # @keys: An array of @KeyValue elements. All @KeyValues in this array are
3923 #        simultaneously sent to the guest. A @KeyValue.number value is sent
3924 #        directly to the guest, while @KeyValue.qcode must be a valid
3925 #        @QKeyCode value
3926 #
3927 # @hold-time: time to delay key up events, milliseconds. Defaults
3928 #             to 100
3929 #
3930 # Returns: Nothing on success
3931 #          If key is unknown or redundant, InvalidParameter
3932 #
3933 # Since: 1.3.0
3934 #
3935 # Example:
3936 #
3937 # -> { "execute": "send-key",
3938 #      "arguments": { "keys": [ { "type": "qcode", "data": "ctrl" },
3939 #                               { "type": "qcode", "data": "alt" },
3940 #                               { "type": "qcode", "data": "delete" } ] } }
3941 # <- { "return": {} }
3942 #
3943 ##
3944 { 'command': 'send-key',
3945   'data': { 'keys': ['KeyValue'], '*hold-time': 'int' } }
3946
3947 ##
3948 # @screendump:
3949 #
3950 # Write a PPM of the VGA screen to a file.
3951 #
3952 # @filename: the path of a new PPM file to store the image
3953 #
3954 # Returns: Nothing on success
3955 #
3956 # Since: 0.14.0
3957 #
3958 # Example:
3959 #
3960 # -> { "execute": "screendump",
3961 #      "arguments": { "filename": "/tmp/image" } }
3962 # <- { "return": {} }
3963 #
3964 ##
3965 { 'command': 'screendump', 'data': {'filename': 'str'} }
3966
3967
3968 ##
3969 # @TpmModel:
3970 #
3971 # An enumeration of TPM models
3972 #
3973 # @tpm-tis: TPM TIS model
3974 #
3975 # Since: 1.5
3976 ##
3977 { 'enum': 'TpmModel', 'data': [ 'tpm-tis' ] }
3978
3979 ##
3980 # @query-tpm-models:
3981 #
3982 # Return a list of supported TPM models
3983 #
3984 # Returns: a list of TpmModel
3985 #
3986 # Since: 1.5
3987 #
3988 # Example:
3989 #
3990 # -> { "execute": "query-tpm-models" }
3991 # <- { "return": [ "tpm-tis" ] }
3992 #
3993 ##
3994 { 'command': 'query-tpm-models', 'returns': ['TpmModel'] }
3995
3996 ##
3997 # @TpmType:
3998 #
3999 # An enumeration of TPM types
4000 #
4001 # @passthrough: TPM passthrough type
4002 #
4003 # Since: 1.5
4004 ##
4005 { 'enum': 'TpmType', 'data': [ 'passthrough' ] }
4006
4007 ##
4008 # @query-tpm-types:
4009 #
4010 # Return a list of supported TPM types
4011 #
4012 # Returns: a list of TpmType
4013 #
4014 # Since: 1.5
4015 #
4016 # Example:
4017 #
4018 # -> { "execute": "query-tpm-types" }
4019 # <- { "return": [ "passthrough" ] }
4020 #
4021 ##
4022 { 'command': 'query-tpm-types', 'returns': ['TpmType'] }
4023
4024 ##
4025 # @TPMPassthroughOptions:
4026 #
4027 # Information about the TPM passthrough type
4028 #
4029 # @path: string describing the path used for accessing the TPM device
4030 #
4031 # @cancel-path: string showing the TPM's sysfs cancel file
4032 #               for cancellation of TPM commands while they are executing
4033 #
4034 # Since: 1.5
4035 ##
4036 { 'struct': 'TPMPassthroughOptions', 'data': { '*path' : 'str',
4037                                              '*cancel-path' : 'str'} }
4038
4039 ##
4040 # @TpmTypeOptions:
4041 #
4042 # A union referencing different TPM backend types' configuration options
4043 #
4044 # @type: 'passthrough' The configuration options for the TPM passthrough type
4045 #
4046 # Since: 1.5
4047 ##
4048 { 'union': 'TpmTypeOptions',
4049    'data': { 'passthrough' : 'TPMPassthroughOptions' } }
4050
4051 ##
4052 # @TPMInfo:
4053 #
4054 # Information about the TPM
4055 #
4056 # @id: The Id of the TPM
4057 #
4058 # @model: The TPM frontend model
4059 #
4060 # @options: The TPM (backend) type configuration options
4061 #
4062 # Since: 1.5
4063 ##
4064 { 'struct': 'TPMInfo',
4065   'data': {'id': 'str',
4066            'model': 'TpmModel',
4067            'options': 'TpmTypeOptions' } }
4068
4069 ##
4070 # @query-tpm:
4071 #
4072 # Return information about the TPM device
4073 #
4074 # Returns: @TPMInfo on success
4075 #
4076 # Since: 1.5
4077 #
4078 # Example:
4079 #
4080 # -> { "execute": "query-tpm" }
4081 # <- { "return":
4082 #      [
4083 #        { "model": "tpm-tis",
4084 #          "options":
4085 #            { "type": "passthrough",
4086 #              "data":
4087 #                { "cancel-path": "/sys/class/misc/tpm0/device/cancel",
4088 #                  "path": "/dev/tpm0"
4089 #                }
4090 #            },
4091 #          "id": "tpm0"
4092 #        }
4093 #      ]
4094 #    }
4095 #
4096 ##
4097 { 'command': 'query-tpm', 'returns': ['TPMInfo'] }
4098
4099 ##
4100 # @AcpiTableOptions:
4101 #
4102 # Specify an ACPI table on the command line to load.
4103 #
4104 # At most one of @file and @data can be specified. The list of files specified
4105 # by any one of them is loaded and concatenated in order. If both are omitted,
4106 # @data is implied.
4107 #
4108 # Other fields / optargs can be used to override fields of the generic ACPI
4109 # table header; refer to the ACPI specification 5.0, section 5.2.6 System
4110 # Description Table Header. If a header field is not overridden, then the
4111 # corresponding value from the concatenated blob is used (in case of @file), or
4112 # it is filled in with a hard-coded value (in case of @data).
4113 #
4114 # String fields are copied into the matching ACPI member from lowest address
4115 # upwards, and silently truncated / NUL-padded to length.
4116 #
4117 # @sig: table signature / identifier (4 bytes)
4118 #
4119 # @rev: table revision number (dependent on signature, 1 byte)
4120 #
4121 # @oem_id: OEM identifier (6 bytes)
4122 #
4123 # @oem_table_id: OEM table identifier (8 bytes)
4124 #
4125 # @oem_rev: OEM-supplied revision number (4 bytes)
4126 #
4127 # @asl_compiler_id: identifier of the utility that created the table
4128 #                   (4 bytes)
4129 #
4130 # @asl_compiler_rev: revision number of the utility that created the
4131 #                    table (4 bytes)
4132 #
4133 # @file: colon (:) separated list of pathnames to load and
4134 #        concatenate as table data. The resultant binary blob is expected to
4135 #        have an ACPI table header. At least one file is required. This field
4136 #        excludes @data.
4137 #
4138 # @data: colon (:) separated list of pathnames to load and
4139 #        concatenate as table data. The resultant binary blob must not have an
4140 #        ACPI table header. At least one file is required. This field excludes
4141 #        @file.
4142 #
4143 # Since: 1.5
4144 ##
4145 { 'struct': 'AcpiTableOptions',
4146   'data': {
4147     '*sig':               'str',
4148     '*rev':               'uint8',
4149     '*oem_id':            'str',
4150     '*oem_table_id':      'str',
4151     '*oem_rev':           'uint32',
4152     '*asl_compiler_id':   'str',
4153     '*asl_compiler_rev':  'uint32',
4154     '*file':              'str',
4155     '*data':              'str' }}
4156
4157 ##
4158 # @CommandLineParameterType:
4159 #
4160 # Possible types for an option parameter.
4161 #
4162 # @string: accepts a character string
4163 #
4164 # @boolean: accepts "on" or "off"
4165 #
4166 # @number: accepts a number
4167 #
4168 # @size: accepts a number followed by an optional suffix (K)ilo,
4169 #        (M)ega, (G)iga, (T)era
4170 #
4171 # Since: 1.5
4172 ##
4173 { 'enum': 'CommandLineParameterType',
4174   'data': ['string', 'boolean', 'number', 'size'] }
4175
4176 ##
4177 # @CommandLineParameterInfo:
4178 #
4179 # Details about a single parameter of a command line option.
4180 #
4181 # @name: parameter name
4182 #
4183 # @type: parameter @CommandLineParameterType
4184 #
4185 # @help: human readable text string, not suitable for parsing.
4186 #
4187 # @default: default value string (since 2.1)
4188 #
4189 # Since: 1.5
4190 ##
4191 { 'struct': 'CommandLineParameterInfo',
4192   'data': { 'name': 'str',
4193             'type': 'CommandLineParameterType',
4194             '*help': 'str',
4195             '*default': 'str' } }
4196
4197 ##
4198 # @CommandLineOptionInfo:
4199 #
4200 # Details about a command line option, including its list of parameter details
4201 #
4202 # @option: option name
4203 #
4204 # @parameters: an array of @CommandLineParameterInfo
4205 #
4206 # Since: 1.5
4207 ##
4208 { 'struct': 'CommandLineOptionInfo',
4209   'data': { 'option': 'str', 'parameters': ['CommandLineParameterInfo'] } }
4210
4211 ##
4212 # @query-command-line-options:
4213 #
4214 # Query command line option schema.
4215 #
4216 # @option: option name
4217 #
4218 # Returns: list of @CommandLineOptionInfo for all options (or for the given
4219 #          @option).  Returns an error if the given @option doesn't exist.
4220 #
4221 # Since: 1.5
4222 #
4223 # Example:
4224 #
4225 # -> { "execute": "query-command-line-options",
4226 #      "arguments": { "option": "option-rom" } }
4227 # <- { "return": [
4228 #         {
4229 #             "parameters": [
4230 #                 {
4231 #                     "name": "romfile",
4232 #                     "type": "string"
4233 #                 },
4234 #                 {
4235 #                     "name": "bootindex",
4236 #                     "type": "number"
4237 #                 }
4238 #             ],
4239 #             "option": "option-rom"
4240 #         }
4241 #      ]
4242 #    }
4243 #
4244 ##
4245 {'command': 'query-command-line-options', 'data': { '*option': 'str' },
4246  'returns': ['CommandLineOptionInfo'] }
4247
4248 ##
4249 # @X86CPURegister32:
4250 #
4251 # A X86 32-bit register
4252 #
4253 # Since: 1.5
4254 ##
4255 { 'enum': 'X86CPURegister32',
4256   'data': [ 'EAX', 'EBX', 'ECX', 'EDX', 'ESP', 'EBP', 'ESI', 'EDI' ] }
4257
4258 ##
4259 # @X86CPUFeatureWordInfo:
4260 #
4261 # Information about a X86 CPU feature word
4262 #
4263 # @cpuid-input-eax: Input EAX value for CPUID instruction for that feature word
4264 #
4265 # @cpuid-input-ecx: Input ECX value for CPUID instruction for that
4266 #                   feature word
4267 #
4268 # @cpuid-register: Output register containing the feature bits
4269 #
4270 # @features: value of output register, containing the feature bits
4271 #
4272 # Since: 1.5
4273 ##
4274 { 'struct': 'X86CPUFeatureWordInfo',
4275   'data': { 'cpuid-input-eax': 'int',
4276             '*cpuid-input-ecx': 'int',
4277             'cpuid-register': 'X86CPURegister32',
4278             'features': 'int' } }
4279
4280 ##
4281 # @DummyForceArrays:
4282 #
4283 # Not used by QMP; hack to let us use X86CPUFeatureWordInfoList internally
4284 #
4285 # Since: 2.5
4286 ##
4287 { 'struct': 'DummyForceArrays',
4288   'data': { 'unused': ['X86CPUFeatureWordInfo'] } }
4289
4290
4291 ##
4292 # @InputButton:
4293 #
4294 # Button of a pointer input device (mouse, tablet).
4295 #
4296 # @side: front side button of a 5-button mouse (since 2.9)
4297 #
4298 # @extra: rear side button of a 5-button mouse (since 2.9)
4299 #
4300 # Since: 2.0
4301 ##
4302 { 'enum'  : 'InputButton',
4303   'data'  : [ 'left', 'middle', 'right', 'wheel-up', 'wheel-down', 'side',
4304   'extra' ] }
4305
4306 ##
4307 # @InputAxis:
4308 #
4309 # Position axis of a pointer input device (mouse, tablet).
4310 #
4311 # Since: 2.0
4312 ##
4313 { 'enum'  : 'InputAxis',
4314   'data'  : [ 'x', 'y' ] }
4315
4316 ##
4317 # @InputKeyEvent:
4318 #
4319 # Keyboard input event.
4320 #
4321 # @key:    Which key this event is for.
4322 # @down:   True for key-down and false for key-up events.
4323 #
4324 # Since: 2.0
4325 ##
4326 { 'struct'  : 'InputKeyEvent',
4327   'data'  : { 'key'     : 'KeyValue',
4328               'down'    : 'bool' } }
4329
4330 ##
4331 # @InputBtnEvent:
4332 #
4333 # Pointer button input event.
4334 #
4335 # @button: Which button this event is for.
4336 # @down:   True for key-down and false for key-up events.
4337 #
4338 # Since: 2.0
4339 ##
4340 { 'struct'  : 'InputBtnEvent',
4341   'data'  : { 'button'  : 'InputButton',
4342               'down'    : 'bool' } }
4343
4344 ##
4345 # @InputMoveEvent:
4346 #
4347 # Pointer motion input event.
4348 #
4349 # @axis:   Which axis is referenced by @value.
4350 # @value:  Pointer position.  For absolute coordinates the
4351 #          valid range is 0 -> 0x7ffff
4352 #
4353 # Since: 2.0
4354 ##
4355 { 'struct'  : 'InputMoveEvent',
4356   'data'  : { 'axis'    : 'InputAxis',
4357               'value'   : 'int' } }
4358
4359 ##
4360 # @InputEvent:
4361 #
4362 # Input event union.
4363 #
4364 # @type: the input type, one of:
4365 #  - 'key': Input event of Keyboard
4366 #  - 'btn': Input event of pointer buttons
4367 #  - 'rel': Input event of relative pointer motion
4368 #  - 'abs': Input event of absolute pointer motion
4369 #
4370 # Since: 2.0
4371 ##
4372 { 'union' : 'InputEvent',
4373   'data'  : { 'key'     : 'InputKeyEvent',
4374               'btn'     : 'InputBtnEvent',
4375               'rel'     : 'InputMoveEvent',
4376               'abs'     : 'InputMoveEvent' } }
4377
4378 ##
4379 # @input-send-event:
4380 #
4381 # Send input event(s) to guest.
4382 #
4383 # @device: display device to send event(s) to.
4384 # @head: head to send event(s) to, in case the
4385 #        display device supports multiple scanouts.
4386 # @events: List of InputEvent union.
4387 #
4388 # Returns: Nothing on success.
4389 #
4390 # The @device and @head parameters can be used to send the input event
4391 # to specific input devices in case (a) multiple input devices of the
4392 # same kind are added to the virtual machine and (b) you have
4393 # configured input routing (see docs/multiseat.txt) for those input
4394 # devices.  The parameters work exactly like the device and head
4395 # properties of input devices.  If @device is missing, only devices
4396 # that have no input routing config are admissible.  If @device is
4397 # specified, both input devices with and without input routing config
4398 # are admissible, but devices with input routing config take
4399 # precedence.
4400 #
4401 # Since: 2.6
4402 #
4403 # Note: The consoles are visible in the qom tree, under
4404 # /backend/console[$index]. They have a device link and head property,
4405 # so it is possible to map which console belongs to which device and
4406 # display.
4407 #
4408 # Example:
4409 #
4410 # 1. Press left mouse button.
4411 #
4412 # -> { "execute": "input-send-event",
4413 #     "arguments": { "device": "video0",
4414 #                    "events": [ { "type": "btn",
4415 #                    "data" : { "down": true, "button": "left" } } ] } }
4416 # <- { "return": {} }
4417 #
4418 # -> { "execute": "input-send-event",
4419 #     "arguments": { "device": "video0",
4420 #                    "events": [ { "type": "btn",
4421 #                    "data" : { "down": false, "button": "left" } } ] } }
4422 # <- { "return": {} }
4423 #
4424 # 2. Press ctrl-alt-del.
4425 #
4426 # -> { "execute": "input-send-event",
4427 #      "arguments": { "events": [
4428 #         { "type": "key", "data" : { "down": true,
4429 #           "key": {"type": "qcode", "data": "ctrl" } } },
4430 #         { "type": "key", "data" : { "down": true,
4431 #           "key": {"type": "qcode", "data": "alt" } } },
4432 #         { "type": "key", "data" : { "down": true,
4433 #           "key": {"type": "qcode", "data": "delete" } } } ] } }
4434 # <- { "return": {} }
4435 #
4436 # 3. Move mouse pointer to absolute coordinates (20000, 400).
4437 #
4438 # -> { "execute": "input-send-event" ,
4439 #   "arguments": { "events": [
4440 #                { "type": "abs", "data" : { "axis": "x", "value" : 20000 } },
4441 #                { "type": "abs", "data" : { "axis": "y", "value" : 400 } } ] } }
4442 # <- { "return": {} }
4443 #
4444 ##
4445 { 'command': 'input-send-event',
4446   'data': { '*device': 'str',
4447             '*head'  : 'int',
4448             'events' : [ 'InputEvent' ] } }
4449
4450 ##
4451 # @NumaOptionsType:
4452 #
4453 # @node: NUMA nodes configuration
4454 #
4455 # @dist: NUMA distance configuration (since 2.10)
4456 #
4457 # @cpu: property based CPU(s) to node mapping (Since: 2.10)
4458 #
4459 # Since: 2.1
4460 ##
4461 { 'enum': 'NumaOptionsType',
4462   'data': [ 'node', 'dist', 'cpu' ] }
4463
4464 ##
4465 # @NumaOptions:
4466 #
4467 # A discriminated record of NUMA options. (for OptsVisitor)
4468 #
4469 # Since: 2.1
4470 ##
4471 { 'union': 'NumaOptions',
4472   'base': { 'type': 'NumaOptionsType' },
4473   'discriminator': 'type',
4474   'data': {
4475     'node': 'NumaNodeOptions',
4476     'dist': 'NumaDistOptions',
4477     'cpu': 'NumaCpuOptions' }}
4478
4479 ##
4480 # @NumaNodeOptions:
4481 #
4482 # Create a guest NUMA node. (for OptsVisitor)
4483 #
4484 # @nodeid: NUMA node ID (increase by 1 from 0 if omitted)
4485 #
4486 # @cpus: VCPUs belonging to this node (assign VCPUS round-robin
4487 #         if omitted)
4488 #
4489 # @mem: memory size of this node; mutually exclusive with @memdev.
4490 #       Equally divide total memory among nodes if both @mem and @memdev are
4491 #       omitted.
4492 #
4493 # @memdev: memory backend object.  If specified for one node,
4494 #          it must be specified for all nodes.
4495 #
4496 # Since: 2.1
4497 ##
4498 { 'struct': 'NumaNodeOptions',
4499   'data': {
4500    '*nodeid': 'uint16',
4501    '*cpus':   ['uint16'],
4502    '*mem':    'size',
4503    '*memdev': 'str' }}
4504
4505 ##
4506 # @NumaDistOptions:
4507 #
4508 # Set the distance between 2 NUMA nodes.
4509 #
4510 # @src: source NUMA node.
4511 #
4512 # @dst: destination NUMA node.
4513 #
4514 # @val: NUMA distance from source node to destination node.
4515 #       When a node is unreachable from another node, set the distance
4516 #       between them to 255.
4517 #
4518 # Since: 2.10
4519 ##
4520 { 'struct': 'NumaDistOptions',
4521   'data': {
4522    'src': 'uint16',
4523    'dst': 'uint16',
4524    'val': 'uint8' }}
4525
4526 ##
4527 # @NumaCpuOptions:
4528 #
4529 # Option "-numa cpu" overrides default cpu to node mapping.
4530 # It accepts the same set of cpu properties as returned by
4531 # query-hotpluggable-cpus[].props, where node-id could be used to
4532 # override default node mapping.
4533 #
4534 # Since: 2.10
4535 ##
4536 { 'struct': 'NumaCpuOptions',
4537    'base': 'CpuInstanceProperties',
4538    'data' : {} }
4539
4540 ##
4541 # @HostMemPolicy:
4542 #
4543 # Host memory policy types
4544 #
4545 # @default: restore default policy, remove any nondefault policy
4546 #
4547 # @preferred: set the preferred host nodes for allocation
4548 #
4549 # @bind: a strict policy that restricts memory allocation to the
4550 #        host nodes specified
4551 #
4552 # @interleave: memory allocations are interleaved across the set
4553 #              of host nodes specified
4554 #
4555 # Since: 2.1
4556 ##
4557 { 'enum': 'HostMemPolicy',
4558   'data': [ 'default', 'preferred', 'bind', 'interleave' ] }
4559
4560 ##
4561 # @Memdev:
4562 #
4563 # Information about memory backend
4564 #
4565 # @id: backend's ID if backend has 'id' property (since 2.9)
4566 #
4567 # @size: memory backend size
4568 #
4569 # @merge: enables or disables memory merge support
4570 #
4571 # @dump: includes memory backend's memory in a core dump or not
4572 #
4573 # @prealloc: enables or disables memory preallocation
4574 #
4575 # @host-nodes: host nodes for its memory policy
4576 #
4577 # @policy: memory policy of memory backend
4578 #
4579 # Since: 2.1
4580 ##
4581 { 'struct': 'Memdev',
4582   'data': {
4583     '*id':        'str',
4584     'size':       'size',
4585     'merge':      'bool',
4586     'dump':       'bool',
4587     'prealloc':   'bool',
4588     'host-nodes': ['uint16'],
4589     'policy':     'HostMemPolicy' }}
4590
4591 ##
4592 # @query-memdev:
4593 #
4594 # Returns information for all memory backends.
4595 #
4596 # Returns: a list of @Memdev.
4597 #
4598 # Since: 2.1
4599 #
4600 # Example:
4601 #
4602 # -> { "execute": "query-memdev" }
4603 # <- { "return": [
4604 #        {
4605 #          "id": "mem1",
4606 #          "size": 536870912,
4607 #          "merge": false,
4608 #          "dump": true,
4609 #          "prealloc": false,
4610 #          "host-nodes": [0, 1],
4611 #          "policy": "bind"
4612 #        },
4613 #        {
4614 #          "size": 536870912,
4615 #          "merge": false,
4616 #          "dump": true,
4617 #          "prealloc": true,
4618 #          "host-nodes": [2, 3],
4619 #          "policy": "preferred"
4620 #        }
4621 #      ]
4622 #    }
4623 #
4624 ##
4625 { 'command': 'query-memdev', 'returns': ['Memdev'] }
4626
4627 ##
4628 # @PCDIMMDeviceInfo:
4629 #
4630 # PCDIMMDevice state information
4631 #
4632 # @id: device's ID
4633 #
4634 # @addr: physical address, where device is mapped
4635 #
4636 # @size: size of memory that the device provides
4637 #
4638 # @slot: slot number at which device is plugged in
4639 #
4640 # @node: NUMA node number where device is plugged in
4641 #
4642 # @memdev: memory backend linked with device
4643 #
4644 # @hotplugged: true if device was hotplugged
4645 #
4646 # @hotpluggable: true if device if could be added/removed while machine is running
4647 #
4648 # Since: 2.1
4649 ##
4650 { 'struct': 'PCDIMMDeviceInfo',
4651   'data': { '*id': 'str',
4652             'addr': 'int',
4653             'size': 'int',
4654             'slot': 'int',
4655             'node': 'int',
4656             'memdev': 'str',
4657             'hotplugged': 'bool',
4658             'hotpluggable': 'bool'
4659           }
4660 }
4661
4662 ##
4663 # @MemoryDeviceInfo:
4664 #
4665 # Union containing information about a memory device
4666 #
4667 # Since: 2.1
4668 ##
4669 { 'union': 'MemoryDeviceInfo', 'data': {'dimm': 'PCDIMMDeviceInfo'} }
4670
4671 ##
4672 # @query-memory-devices:
4673 #
4674 # Lists available memory devices and their state
4675 #
4676 # Since: 2.1
4677 #
4678 # Example:
4679 #
4680 # -> { "execute": "query-memory-devices" }
4681 # <- { "return": [ { "data":
4682 #                       { "addr": 5368709120,
4683 #                         "hotpluggable": true,
4684 #                         "hotplugged": true,
4685 #                         "id": "d1",
4686 #                         "memdev": "/objects/memX",
4687 #                         "node": 0,
4688 #                         "size": 1073741824,
4689 #                         "slot": 0},
4690 #                    "type": "dimm"
4691 #                  } ] }
4692 #
4693 ##
4694 { 'command': 'query-memory-devices', 'returns': ['MemoryDeviceInfo'] }
4695
4696 ##
4697 # @ACPISlotType:
4698 #
4699 # @DIMM: memory slot
4700 # @CPU: logical CPU slot (since 2.7)
4701 ##
4702 { 'enum': 'ACPISlotType', 'data': [ 'DIMM', 'CPU' ] }
4703
4704 ##
4705 # @ACPIOSTInfo:
4706 #
4707 # OSPM Status Indication for a device
4708 # For description of possible values of @source and @status fields
4709 # see "_OST (OSPM Status Indication)" chapter of ACPI5.0 spec.
4710 #
4711 # @device: device ID associated with slot
4712 #
4713 # @slot: slot ID, unique per slot of a given @slot-type
4714 #
4715 # @slot-type: type of the slot
4716 #
4717 # @source: an integer containing the source event
4718 #
4719 # @status: an integer containing the status code
4720 #
4721 # Since: 2.1
4722 ##
4723 { 'struct': 'ACPIOSTInfo',
4724   'data'  : { '*device': 'str',
4725               'slot': 'str',
4726               'slot-type': 'ACPISlotType',
4727               'source': 'int',
4728               'status': 'int' } }
4729
4730 ##
4731 # @query-acpi-ospm-status:
4732 #
4733 # Return a list of ACPIOSTInfo for devices that support status
4734 # reporting via ACPI _OST method.
4735 #
4736 # Since: 2.1
4737 #
4738 # Example:
4739 #
4740 # -> { "execute": "query-acpi-ospm-status" }
4741 # <- { "return": [ { "device": "d1", "slot": "0", "slot-type": "DIMM", "source": 1, "status": 0},
4742 #                  { "slot": "1", "slot-type": "DIMM", "source": 0, "status": 0},
4743 #                  { "slot": "2", "slot-type": "DIMM", "source": 0, "status": 0},
4744 #                  { "slot": "3", "slot-type": "DIMM", "source": 0, "status": 0}
4745 #    ]}
4746 #
4747 ##
4748 { 'command': 'query-acpi-ospm-status', 'returns': ['ACPIOSTInfo'] }
4749
4750 ##
4751 # @IoOperationType:
4752 #
4753 # An enumeration of the I/O operation types
4754 #
4755 # @read: read operation
4756 #
4757 # @write: write operation
4758 #
4759 # Since: 2.1
4760 ##
4761 { 'enum': 'IoOperationType',
4762   'data': [ 'read', 'write' ] }
4763
4764 ##
4765 # @rtc-reset-reinjection:
4766 #
4767 # This command will reset the RTC interrupt reinjection backlog.
4768 # Can be used if another mechanism to synchronize guest time
4769 # is in effect, for example QEMU guest agent's guest-set-time
4770 # command.
4771 #
4772 # Since: 2.1
4773 #
4774 # Example:
4775 #
4776 # -> { "execute": "rtc-reset-reinjection" }
4777 # <- { "return": {} }
4778 #
4779 ##
4780 { 'command': 'rtc-reset-reinjection' }
4781
4782 ##
4783 # @ReplayMode:
4784 #
4785 # Mode of the replay subsystem.
4786 #
4787 # @none: normal execution mode. Replay or record are not enabled.
4788 #
4789 # @record: record mode. All non-deterministic data is written into the
4790 #          replay log.
4791 #
4792 # @play: replay mode. Non-deterministic data required for system execution
4793 #        is read from the log.
4794 #
4795 # Since: 2.5
4796 ##
4797 { 'enum': 'ReplayMode',
4798   'data': [ 'none', 'record', 'play' ] }
4799
4800 ##
4801 # @xen-load-devices-state:
4802 #
4803 # Load the state of all devices from file. The RAM and the block devices
4804 # of the VM are not loaded by this command.
4805 #
4806 # @filename: the file to load the state of the devices from as binary
4807 # data. See xen-save-devices-state.txt for a description of the binary
4808 # format.
4809 #
4810 # Since: 2.7
4811 #
4812 # Example:
4813 #
4814 # -> { "execute": "xen-load-devices-state",
4815 #      "arguments": { "filename": "/tmp/resume" } }
4816 # <- { "return": {} }
4817 #
4818 ##
4819 { 'command': 'xen-load-devices-state', 'data': {'filename': 'str'} }
4820
4821 ##
4822 # @xen-set-replication:
4823 #
4824 # Enable or disable replication.
4825 #
4826 # @enable: true to enable, false to disable.
4827 #
4828 # @primary: true for primary or false for secondary.
4829 #
4830 # @failover: true to do failover, false to stop. but cannot be
4831 #            specified if 'enable' is true. default value is false.
4832 #
4833 # Returns: nothing.
4834 #
4835 # Example:
4836 #
4837 # -> { "execute": "xen-set-replication",
4838 #      "arguments": {"enable": true, "primary": false} }
4839 # <- { "return": {} }
4840 #
4841 # Since: 2.9
4842 ##
4843 { 'command': 'xen-set-replication',
4844   'data': { 'enable': 'bool', 'primary': 'bool', '*failover' : 'bool' } }
4845
4846 ##
4847 # @ReplicationStatus:
4848 #
4849 # The result format for 'query-xen-replication-status'.
4850 #
4851 # @error: true if an error happened, false if replication is normal.
4852 #
4853 # @desc: the human readable error description string, when
4854 #        @error is 'true'.
4855 #
4856 # Since: 2.9
4857 ##
4858 { 'struct': 'ReplicationStatus',
4859   'data': { 'error': 'bool', '*desc': 'str' } }
4860
4861 ##
4862 # @query-xen-replication-status:
4863 #
4864 # Query replication status while the vm is running.
4865 #
4866 # Returns: A @ReplicationResult object showing the status.
4867 #
4868 # Example:
4869 #
4870 # -> { "execute": "query-xen-replication-status" }
4871 # <- { "return": { "error": false } }
4872 #
4873 # Since: 2.9
4874 ##
4875 { 'command': 'query-xen-replication-status',
4876   'returns': 'ReplicationStatus' }
4877
4878 ##
4879 # @xen-colo-do-checkpoint:
4880 #
4881 # Xen uses this command to notify replication to trigger a checkpoint.
4882 #
4883 # Returns: nothing.
4884 #
4885 # Example:
4886 #
4887 # -> { "execute": "xen-colo-do-checkpoint" }
4888 # <- { "return": {} }
4889 #
4890 # Since: 2.9
4891 ##
4892 { 'command': 'xen-colo-do-checkpoint' }
4893
4894 ##
4895 # @GICCapability:
4896 #
4897 # The struct describes capability for a specific GIC (Generic
4898 # Interrupt Controller) version. These bits are not only decided by
4899 # QEMU/KVM software version, but also decided by the hardware that
4900 # the program is running upon.
4901 #
4902 # @version:  version of GIC to be described. Currently, only 2 and 3
4903 #            are supported.
4904 #
4905 # @emulated: whether current QEMU/hardware supports emulated GIC
4906 #            device in user space.
4907 #
4908 # @kernel:   whether current QEMU/hardware supports hardware
4909 #            accelerated GIC device in kernel.
4910 #
4911 # Since: 2.6
4912 ##
4913 { 'struct': 'GICCapability',
4914   'data': { 'version': 'int',
4915             'emulated': 'bool',
4916             'kernel': 'bool' } }
4917
4918 ##
4919 # @query-gic-capabilities:
4920 #
4921 # This command is ARM-only. It will return a list of GICCapability
4922 # objects that describe its capability bits.
4923 #
4924 # Returns: a list of GICCapability objects.
4925 #
4926 # Since: 2.6
4927 #
4928 # Example:
4929 #
4930 # -> { "execute": "query-gic-capabilities" }
4931 # <- { "return": [{ "version": 2, "emulated": true, "kernel": false },
4932 #                 { "version": 3, "emulated": false, "kernel": true } ] }
4933 #
4934 ##
4935 { 'command': 'query-gic-capabilities', 'returns': ['GICCapability'] }
4936
4937 ##
4938 # @CpuInstanceProperties:
4939 #
4940 # List of properties to be used for hotplugging a CPU instance,
4941 # it should be passed by management with device_add command when
4942 # a CPU is being hotplugged.
4943 #
4944 # @node-id: NUMA node ID the CPU belongs to
4945 # @socket-id: socket number within node/board the CPU belongs to
4946 # @core-id: core number within socket the CPU belongs to
4947 # @thread-id: thread number within core the CPU belongs to
4948 #
4949 # Note: currently there are 4 properties that could be present
4950 # but management should be prepared to pass through other
4951 # properties with device_add command to allow for future
4952 # interface extension. This also requires the filed names to be kept in
4953 # sync with the properties passed to -device/device_add.
4954 #
4955 # Since: 2.7
4956 ##
4957 { 'struct': 'CpuInstanceProperties',
4958   'data': { '*node-id': 'int',
4959             '*socket-id': 'int',
4960             '*core-id': 'int',
4961             '*thread-id': 'int'
4962   }
4963 }
4964
4965 ##
4966 # @HotpluggableCPU:
4967 #
4968 # @type: CPU object type for usage with device_add command
4969 # @props: list of properties to be used for hotplugging CPU
4970 # @vcpus-count: number of logical VCPU threads @HotpluggableCPU provides
4971 # @qom-path: link to existing CPU object if CPU is present or
4972 #            omitted if CPU is not present.
4973 #
4974 # Since: 2.7
4975 ##
4976 { 'struct': 'HotpluggableCPU',
4977   'data': { 'type': 'str',
4978             'vcpus-count': 'int',
4979             'props': 'CpuInstanceProperties',
4980             '*qom-path': 'str'
4981           }
4982 }
4983
4984 ##
4985 # @query-hotpluggable-cpus:
4986 #
4987 # Returns: a list of HotpluggableCPU objects.
4988 #
4989 # Since: 2.7
4990 #
4991 # Example:
4992 #
4993 # For pseries machine type started with -smp 2,cores=2,maxcpus=4 -cpu POWER8:
4994 #
4995 # -> { "execute": "query-hotpluggable-cpus" }
4996 # <- {"return": [
4997 #      { "props": { "core": 8 }, "type": "POWER8-spapr-cpu-core",
4998 #        "vcpus-count": 1 },
4999 #      { "props": { "core": 0 }, "type": "POWER8-spapr-cpu-core",
5000 #        "vcpus-count": 1, "qom-path": "/machine/unattached/device[0]"}
5001 #    ]}'
5002 #
5003 # For pc machine type started with -smp 1,maxcpus=2:
5004 #
5005 # -> { "execute": "query-hotpluggable-cpus" }
5006 # <- {"return": [
5007 #      {
5008 #         "type": "qemu64-x86_64-cpu", "vcpus-count": 1,
5009 #         "props": {"core-id": 0, "socket-id": 1, "thread-id": 0}
5010 #      },
5011 #      {
5012 #         "qom-path": "/machine/unattached/device[0]",
5013 #         "type": "qemu64-x86_64-cpu", "vcpus-count": 1,
5014 #         "props": {"core-id": 0, "socket-id": 0, "thread-id": 0}
5015 #      }
5016 #    ]}
5017 #
5018 ##
5019 { 'command': 'query-hotpluggable-cpus', 'returns': ['HotpluggableCPU'] }
5020
5021 ##
5022 # @GuidInfo:
5023 #
5024 # GUID information.
5025 #
5026 # @guid: the globally unique identifier
5027 #
5028 # Since: 2.9
5029 ##
5030 { 'struct': 'GuidInfo', 'data': {'guid': 'str'} }
5031
5032 ##
5033 # @query-vm-generation-id:
5034 #
5035 # Show Virtual Machine Generation ID
5036 #
5037 # Since 2.9
5038 ##
5039 { 'command': 'query-vm-generation-id', 'returns': 'GuidInfo' }
This page took 0.317878 seconds and 4 git commands to generate.