]> git.proxmox.com Git - mirror_qemu.git/blob - qapi-schema.json
qapi-schema: Collect TPM stuff in qapi/tpm.json
[mirror_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/tpm.json' }
90 { 'include': 'qapi/ui.json' }
91 { 'include': 'qapi/migration.json' }
92 { 'include': 'qapi/transaction.json' }
93 { 'include': 'qapi/event.json' }
94 { 'include': 'qapi/trace.json' }
95 { 'include': 'qapi/introspect.json' }
96
97 ##
98 # = QMP commands
99 ##
100
101 ##
102 # @qmp_capabilities:
103 #
104 # Enable QMP capabilities.
105 #
106 # Arguments: None.
107 #
108 # Example:
109 #
110 # -> { "execute": "qmp_capabilities" }
111 # <- { "return": {} }
112 #
113 # Notes: This command is valid exactly when first connecting: it must be
114 # issued before any other command will be accepted, and will fail once the
115 # monitor is accepting other commands. (see qemu docs/interop/qmp-spec.txt)
116 #
117 # Since: 0.13
118 #
119 ##
120 { 'command': 'qmp_capabilities' }
121
122 ##
123 # @LostTickPolicy:
124 #
125 # Policy for handling lost ticks in timer devices.
126 #
127 # @discard: throw away the missed tick(s) and continue with future injection
128 # normally. Guest time may be delayed, unless the OS has explicit
129 # handling of lost ticks
130 #
131 # @delay: continue to deliver ticks at the normal rate. Guest time will be
132 # delayed due to the late tick
133 #
134 # @merge: merge the missed tick(s) into one tick and inject. Guest time
135 # may be delayed, depending on how the OS reacts to the merging
136 # of ticks
137 #
138 # @slew: deliver ticks at a higher rate to catch up with the missed tick. The
139 # guest time should not be delayed once catchup is complete.
140 #
141 # Since: 2.0
142 ##
143 { 'enum': 'LostTickPolicy',
144 'data': ['discard', 'delay', 'merge', 'slew' ] }
145
146 ##
147 # @add_client:
148 #
149 # Allow client connections for VNC, Spice and socket based
150 # character devices to be passed in to QEMU via SCM_RIGHTS.
151 #
152 # @protocol: protocol name. Valid names are "vnc", "spice" or the
153 # name of a character device (eg. from -chardev id=XXXX)
154 #
155 # @fdname: file descriptor name previously passed via 'getfd' command
156 #
157 # @skipauth: whether to skip authentication. Only applies
158 # to "vnc" and "spice" protocols
159 #
160 # @tls: whether to perform TLS. Only applies to the "spice"
161 # protocol
162 #
163 # Returns: nothing on success.
164 #
165 # Since: 0.14.0
166 #
167 # Example:
168 #
169 # -> { "execute": "add_client", "arguments": { "protocol": "vnc",
170 # "fdname": "myclient" } }
171 # <- { "return": {} }
172 #
173 ##
174 { 'command': 'add_client',
175 'data': { 'protocol': 'str', 'fdname': 'str', '*skipauth': 'bool',
176 '*tls': 'bool' } }
177
178 ##
179 # @NameInfo:
180 #
181 # Guest name information.
182 #
183 # @name: The name of the guest
184 #
185 # Since: 0.14.0
186 ##
187 { 'struct': 'NameInfo', 'data': {'*name': 'str'} }
188
189 ##
190 # @query-name:
191 #
192 # Return the name information of a guest.
193 #
194 # Returns: @NameInfo of the guest
195 #
196 # Since: 0.14.0
197 #
198 # Example:
199 #
200 # -> { "execute": "query-name" }
201 # <- { "return": { "name": "qemu-name" } }
202 #
203 ##
204 { 'command': 'query-name', 'returns': 'NameInfo' }
205
206 ##
207 # @KvmInfo:
208 #
209 # Information about support for KVM acceleration
210 #
211 # @enabled: true if KVM acceleration is active
212 #
213 # @present: true if KVM acceleration is built into this executable
214 #
215 # Since: 0.14.0
216 ##
217 { 'struct': 'KvmInfo', 'data': {'enabled': 'bool', 'present': 'bool'} }
218
219 ##
220 # @query-kvm:
221 #
222 # Returns information about KVM acceleration
223 #
224 # Returns: @KvmInfo
225 #
226 # Since: 0.14.0
227 #
228 # Example:
229 #
230 # -> { "execute": "query-kvm" }
231 # <- { "return": { "enabled": true, "present": true } }
232 #
233 ##
234 { 'command': 'query-kvm', 'returns': 'KvmInfo' }
235
236 ##
237 # @UuidInfo:
238 #
239 # Guest UUID information (Universally Unique Identifier).
240 #
241 # @UUID: the UUID of the guest
242 #
243 # Since: 0.14.0
244 #
245 # Notes: If no UUID was specified for the guest, a null UUID is returned.
246 ##
247 { 'struct': 'UuidInfo', 'data': {'UUID': 'str'} }
248
249 ##
250 # @query-uuid:
251 #
252 # Query the guest UUID information.
253 #
254 # Returns: The @UuidInfo for the guest
255 #
256 # Since: 0.14.0
257 #
258 # Example:
259 #
260 # -> { "execute": "query-uuid" }
261 # <- { "return": { "UUID": "550e8400-e29b-41d4-a716-446655440000" } }
262 #
263 ##
264 { 'command': 'query-uuid', 'returns': 'UuidInfo' }
265
266 ##
267 # @EventInfo:
268 #
269 # Information about a QMP event
270 #
271 # @name: The event name
272 #
273 # Since: 1.2.0
274 ##
275 { 'struct': 'EventInfo', 'data': {'name': 'str'} }
276
277 ##
278 # @query-events:
279 #
280 # Return a list of supported QMP events by this server
281 #
282 # Returns: A list of @EventInfo for all supported events
283 #
284 # Since: 1.2.0
285 #
286 # Example:
287 #
288 # -> { "execute": "query-events" }
289 # <- {
290 # "return": [
291 # {
292 # "name":"SHUTDOWN"
293 # },
294 # {
295 # "name":"RESET"
296 # }
297 # ]
298 # }
299 #
300 # Note: This example has been shortened as the real response is too long.
301 #
302 ##
303 { 'command': 'query-events', 'returns': ['EventInfo'] }
304
305 ##
306 # @CpuInfoArch:
307 #
308 # An enumeration of cpu types that enable additional information during
309 # @query-cpus.
310 #
311 # Since: 2.6
312 ##
313 { 'enum': 'CpuInfoArch',
314 'data': ['x86', 'sparc', 'ppc', 'mips', 'tricore', 'other' ] }
315
316 ##
317 # @CpuInfo:
318 #
319 # Information about a virtual CPU
320 #
321 # @CPU: the index of the virtual CPU
322 #
323 # @current: this only exists for backwards compatibility and should be ignored
324 #
325 # @halted: true if the virtual CPU is in the halt state. Halt usually refers
326 # to a processor specific low power mode.
327 #
328 # @qom_path: path to the CPU object in the QOM tree (since 2.4)
329 #
330 # @thread_id: ID of the underlying host thread
331 #
332 # @props: properties describing to which node/socket/core/thread
333 # virtual CPU belongs to, provided if supported by board (since 2.10)
334 #
335 # @arch: architecture of the cpu, which determines which additional fields
336 # will be listed (since 2.6)
337 #
338 # Since: 0.14.0
339 #
340 # Notes: @halted is a transient state that changes frequently. By the time the
341 # data is sent to the client, the guest may no longer be halted.
342 ##
343 { 'union': 'CpuInfo',
344 'base': {'CPU': 'int', 'current': 'bool', 'halted': 'bool',
345 'qom_path': 'str', 'thread_id': 'int',
346 '*props': 'CpuInstanceProperties', 'arch': 'CpuInfoArch' },
347 'discriminator': 'arch',
348 'data': { 'x86': 'CpuInfoX86',
349 'sparc': 'CpuInfoSPARC',
350 'ppc': 'CpuInfoPPC',
351 'mips': 'CpuInfoMIPS',
352 'tricore': 'CpuInfoTricore',
353 'other': 'CpuInfoOther' } }
354
355 ##
356 # @CpuInfoX86:
357 #
358 # Additional information about a virtual i386 or x86_64 CPU
359 #
360 # @pc: the 64-bit instruction pointer
361 #
362 # Since: 2.6
363 ##
364 { 'struct': 'CpuInfoX86', 'data': { 'pc': 'int' } }
365
366 ##
367 # @CpuInfoSPARC:
368 #
369 # Additional information about a virtual SPARC CPU
370 #
371 # @pc: the PC component of the instruction pointer
372 #
373 # @npc: the NPC component of the instruction pointer
374 #
375 # Since: 2.6
376 ##
377 { 'struct': 'CpuInfoSPARC', 'data': { 'pc': 'int', 'npc': 'int' } }
378
379 ##
380 # @CpuInfoPPC:
381 #
382 # Additional information about a virtual PPC CPU
383 #
384 # @nip: the instruction pointer
385 #
386 # Since: 2.6
387 ##
388 { 'struct': 'CpuInfoPPC', 'data': { 'nip': 'int' } }
389
390 ##
391 # @CpuInfoMIPS:
392 #
393 # Additional information about a virtual MIPS CPU
394 #
395 # @PC: the instruction pointer
396 #
397 # Since: 2.6
398 ##
399 { 'struct': 'CpuInfoMIPS', 'data': { 'PC': 'int' } }
400
401 ##
402 # @CpuInfoTricore:
403 #
404 # Additional information about a virtual Tricore CPU
405 #
406 # @PC: the instruction pointer
407 #
408 # Since: 2.6
409 ##
410 { 'struct': 'CpuInfoTricore', 'data': { 'PC': 'int' } }
411
412 ##
413 # @CpuInfoOther:
414 #
415 # No additional information is available about the virtual CPU
416 #
417 # Since: 2.6
418 #
419 ##
420 { 'struct': 'CpuInfoOther', 'data': { } }
421
422 ##
423 # @query-cpus:
424 #
425 # Returns a list of information about each virtual CPU.
426 #
427 # Returns: a list of @CpuInfo for each virtual CPU
428 #
429 # Since: 0.14.0
430 #
431 # Example:
432 #
433 # -> { "execute": "query-cpus" }
434 # <- { "return": [
435 # {
436 # "CPU":0,
437 # "current":true,
438 # "halted":false,
439 # "qom_path":"/machine/unattached/device[0]",
440 # "arch":"x86",
441 # "pc":3227107138,
442 # "thread_id":3134
443 # },
444 # {
445 # "CPU":1,
446 # "current":false,
447 # "halted":true,
448 # "qom_path":"/machine/unattached/device[2]",
449 # "arch":"x86",
450 # "pc":7108165,
451 # "thread_id":3135
452 # }
453 # ]
454 # }
455 #
456 ##
457 { 'command': 'query-cpus', 'returns': ['CpuInfo'] }
458
459 ##
460 # @IOThreadInfo:
461 #
462 # Information about an iothread
463 #
464 # @id: the identifier of the iothread
465 #
466 # @thread-id: ID of the underlying host thread
467 #
468 # @poll-max-ns: maximum polling time in ns, 0 means polling is disabled
469 # (since 2.9)
470 #
471 # @poll-grow: how many ns will be added to polling time, 0 means that it's not
472 # configured (since 2.9)
473 #
474 # @poll-shrink: how many ns will be removed from polling time, 0 means that
475 # it's not configured (since 2.9)
476 #
477 # Since: 2.0
478 ##
479 { 'struct': 'IOThreadInfo',
480 'data': {'id': 'str',
481 'thread-id': 'int',
482 'poll-max-ns': 'int',
483 'poll-grow': 'int',
484 'poll-shrink': 'int' } }
485
486 ##
487 # @query-iothreads:
488 #
489 # Returns a list of information about each iothread.
490 #
491 # Note: this list excludes the QEMU main loop thread, which is not declared
492 # using the -object iothread command-line option. It is always the main thread
493 # of the process.
494 #
495 # Returns: a list of @IOThreadInfo for each iothread
496 #
497 # Since: 2.0
498 #
499 # Example:
500 #
501 # -> { "execute": "query-iothreads" }
502 # <- { "return": [
503 # {
504 # "id":"iothread0",
505 # "thread-id":3134
506 # },
507 # {
508 # "id":"iothread1",
509 # "thread-id":3135
510 # }
511 # ]
512 # }
513 #
514 ##
515 { 'command': 'query-iothreads', 'returns': ['IOThreadInfo'] }
516
517 ##
518 # @BalloonInfo:
519 #
520 # Information about the guest balloon device.
521 #
522 # @actual: the number of bytes the balloon currently contains
523 #
524 # Since: 0.14.0
525 #
526 ##
527 { 'struct': 'BalloonInfo', 'data': {'actual': 'int' } }
528
529 ##
530 # @query-balloon:
531 #
532 # Return information about the balloon device.
533 #
534 # Returns: @BalloonInfo on success
535 #
536 # If the balloon driver is enabled but not functional because the KVM
537 # kernel module cannot support it, KvmMissingCap
538 #
539 # If no balloon device is present, DeviceNotActive
540 #
541 # Since: 0.14.0
542 #
543 # Example:
544 #
545 # -> { "execute": "query-balloon" }
546 # <- { "return": {
547 # "actual": 1073741824,
548 # }
549 # }
550 #
551 ##
552 { 'command': 'query-balloon', 'returns': 'BalloonInfo' }
553
554 ##
555 # @PciMemoryRange:
556 #
557 # A PCI device memory region
558 #
559 # @base: the starting address (guest physical)
560 #
561 # @limit: the ending address (guest physical)
562 #
563 # Since: 0.14.0
564 ##
565 { 'struct': 'PciMemoryRange', 'data': {'base': 'int', 'limit': 'int'} }
566
567 ##
568 # @PciMemoryRegion:
569 #
570 # Information about a PCI device I/O region.
571 #
572 # @bar: the index of the Base Address Register for this region
573 #
574 # @type: 'io' if the region is a PIO region
575 # 'memory' if the region is a MMIO region
576 #
577 # @size: memory size
578 #
579 # @prefetch: if @type is 'memory', true if the memory is prefetchable
580 #
581 # @mem_type_64: if @type is 'memory', true if the BAR is 64-bit
582 #
583 # Since: 0.14.0
584 ##
585 { 'struct': 'PciMemoryRegion',
586 'data': {'bar': 'int', 'type': 'str', 'address': 'int', 'size': 'int',
587 '*prefetch': 'bool', '*mem_type_64': 'bool' } }
588
589 ##
590 # @PciBusInfo:
591 #
592 # Information about a bus of a PCI Bridge device
593 #
594 # @number: primary bus interface number. This should be the number of the
595 # bus the device resides on.
596 #
597 # @secondary: secondary bus interface number. This is the number of the
598 # main bus for the bridge
599 #
600 # @subordinate: This is the highest number bus that resides below the
601 # bridge.
602 #
603 # @io_range: The PIO range for all devices on this bridge
604 #
605 # @memory_range: The MMIO range for all devices on this bridge
606 #
607 # @prefetchable_range: The range of prefetchable MMIO for all devices on
608 # this bridge
609 #
610 # Since: 2.4
611 ##
612 { 'struct': 'PciBusInfo',
613 'data': {'number': 'int', 'secondary': 'int', 'subordinate': 'int',
614 'io_range': 'PciMemoryRange',
615 'memory_range': 'PciMemoryRange',
616 'prefetchable_range': 'PciMemoryRange' } }
617
618 ##
619 # @PciBridgeInfo:
620 #
621 # Information about a PCI Bridge device
622 #
623 # @bus: information about the bus the device resides on
624 #
625 # @devices: a list of @PciDeviceInfo for each device on this bridge
626 #
627 # Since: 0.14.0
628 ##
629 { 'struct': 'PciBridgeInfo',
630 'data': {'bus': 'PciBusInfo', '*devices': ['PciDeviceInfo']} }
631
632 ##
633 # @PciDeviceClass:
634 #
635 # Information about the Class of a PCI device
636 #
637 # @desc: a string description of the device's class
638 #
639 # @class: the class code of the device
640 #
641 # Since: 2.4
642 ##
643 { 'struct': 'PciDeviceClass',
644 'data': {'*desc': 'str', 'class': 'int'} }
645
646 ##
647 # @PciDeviceId:
648 #
649 # Information about the Id of a PCI device
650 #
651 # @device: the PCI device id
652 #
653 # @vendor: the PCI vendor id
654 #
655 # Since: 2.4
656 ##
657 { 'struct': 'PciDeviceId',
658 'data': {'device': 'int', 'vendor': 'int'} }
659
660 ##
661 # @PciDeviceInfo:
662 #
663 # Information about a PCI device
664 #
665 # @bus: the bus number of the device
666 #
667 # @slot: the slot the device is located in
668 #
669 # @function: the function of the slot used by the device
670 #
671 # @class_info: the class of the device
672 #
673 # @id: the PCI device id
674 #
675 # @irq: if an IRQ is assigned to the device, the IRQ number
676 #
677 # @qdev_id: the device name of the PCI device
678 #
679 # @pci_bridge: if the device is a PCI bridge, the bridge information
680 #
681 # @regions: a list of the PCI I/O regions associated with the device
682 #
683 # Notes: the contents of @class_info.desc are not stable and should only be
684 # treated as informational.
685 #
686 # Since: 0.14.0
687 ##
688 { 'struct': 'PciDeviceInfo',
689 'data': {'bus': 'int', 'slot': 'int', 'function': 'int',
690 'class_info': 'PciDeviceClass', 'id': 'PciDeviceId',
691 '*irq': 'int', 'qdev_id': 'str', '*pci_bridge': 'PciBridgeInfo',
692 'regions': ['PciMemoryRegion']} }
693
694 ##
695 # @PciInfo:
696 #
697 # Information about a PCI bus
698 #
699 # @bus: the bus index
700 #
701 # @devices: a list of devices on this bus
702 #
703 # Since: 0.14.0
704 ##
705 { 'struct': 'PciInfo', 'data': {'bus': 'int', 'devices': ['PciDeviceInfo']} }
706
707 ##
708 # @query-pci:
709 #
710 # Return information about the PCI bus topology of the guest.
711 #
712 # Returns: a list of @PciInfo for each PCI bus. Each bus is
713 # represented by a json-object, which has a key with a json-array of
714 # all PCI devices attached to it. Each device is represented by a
715 # json-object.
716 #
717 # Since: 0.14.0
718 #
719 # Example:
720 #
721 # -> { "execute": "query-pci" }
722 # <- { "return": [
723 # {
724 # "bus": 0,
725 # "devices": [
726 # {
727 # "bus": 0,
728 # "qdev_id": "",
729 # "slot": 0,
730 # "class_info": {
731 # "class": 1536,
732 # "desc": "Host bridge"
733 # },
734 # "id": {
735 # "device": 32902,
736 # "vendor": 4663
737 # },
738 # "function": 0,
739 # "regions": [
740 # ]
741 # },
742 # {
743 # "bus": 0,
744 # "qdev_id": "",
745 # "slot": 1,
746 # "class_info": {
747 # "class": 1537,
748 # "desc": "ISA bridge"
749 # },
750 # "id": {
751 # "device": 32902,
752 # "vendor": 28672
753 # },
754 # "function": 0,
755 # "regions": [
756 # ]
757 # },
758 # {
759 # "bus": 0,
760 # "qdev_id": "",
761 # "slot": 1,
762 # "class_info": {
763 # "class": 257,
764 # "desc": "IDE controller"
765 # },
766 # "id": {
767 # "device": 32902,
768 # "vendor": 28688
769 # },
770 # "function": 1,
771 # "regions": [
772 # {
773 # "bar": 4,
774 # "size": 16,
775 # "address": 49152,
776 # "type": "io"
777 # }
778 # ]
779 # },
780 # {
781 # "bus": 0,
782 # "qdev_id": "",
783 # "slot": 2,
784 # "class_info": {
785 # "class": 768,
786 # "desc": "VGA controller"
787 # },
788 # "id": {
789 # "device": 4115,
790 # "vendor": 184
791 # },
792 # "function": 0,
793 # "regions": [
794 # {
795 # "prefetch": true,
796 # "mem_type_64": false,
797 # "bar": 0,
798 # "size": 33554432,
799 # "address": 4026531840,
800 # "type": "memory"
801 # },
802 # {
803 # "prefetch": false,
804 # "mem_type_64": false,
805 # "bar": 1,
806 # "size": 4096,
807 # "address": 4060086272,
808 # "type": "memory"
809 # },
810 # {
811 # "prefetch": false,
812 # "mem_type_64": false,
813 # "bar": 6,
814 # "size": 65536,
815 # "address": -1,
816 # "type": "memory"
817 # }
818 # ]
819 # },
820 # {
821 # "bus": 0,
822 # "qdev_id": "",
823 # "irq": 11,
824 # "slot": 4,
825 # "class_info": {
826 # "class": 1280,
827 # "desc": "RAM controller"
828 # },
829 # "id": {
830 # "device": 6900,
831 # "vendor": 4098
832 # },
833 # "function": 0,
834 # "regions": [
835 # {
836 # "bar": 0,
837 # "size": 32,
838 # "address": 49280,
839 # "type": "io"
840 # }
841 # ]
842 # }
843 # ]
844 # }
845 # ]
846 # }
847 #
848 # Note: This example has been shortened as the real response is too long.
849 #
850 ##
851 { 'command': 'query-pci', 'returns': ['PciInfo'] }
852
853 ##
854 # @quit:
855 #
856 # This command will cause the QEMU process to exit gracefully. While every
857 # attempt is made to send the QMP response before terminating, this is not
858 # guaranteed. When using this interface, a premature EOF would not be
859 # unexpected.
860 #
861 # Since: 0.14.0
862 #
863 # Example:
864 #
865 # -> { "execute": "quit" }
866 # <- { "return": {} }
867 ##
868 { 'command': 'quit' }
869
870 ##
871 # @stop:
872 #
873 # Stop all guest VCPU execution.
874 #
875 # Since: 0.14.0
876 #
877 # Notes: This function will succeed even if the guest is already in the stopped
878 # state. In "inmigrate" state, it will ensure that the guest
879 # remains paused once migration finishes, as if the -S option was
880 # passed on the command line.
881 #
882 # Example:
883 #
884 # -> { "execute": "stop" }
885 # <- { "return": {} }
886 #
887 ##
888 { 'command': 'stop' }
889
890 ##
891 # @system_reset:
892 #
893 # Performs a hard reset of a guest.
894 #
895 # Since: 0.14.0
896 #
897 # Example:
898 #
899 # -> { "execute": "system_reset" }
900 # <- { "return": {} }
901 #
902 ##
903 { 'command': 'system_reset' }
904
905 ##
906 # @system_powerdown:
907 #
908 # Requests that a guest perform a powerdown operation.
909 #
910 # Since: 0.14.0
911 #
912 # Notes: A guest may or may not respond to this command. This command
913 # returning does not indicate that a guest has accepted the request or
914 # that it has shut down. Many guests will respond to this command by
915 # prompting the user in some way.
916 # Example:
917 #
918 # -> { "execute": "system_powerdown" }
919 # <- { "return": {} }
920 #
921 ##
922 { 'command': 'system_powerdown' }
923
924 ##
925 # @cpu:
926 #
927 # This command is a nop that is only provided for the purposes of compatibility.
928 #
929 # Since: 0.14.0
930 #
931 # Notes: Do not use this command.
932 ##
933 { 'command': 'cpu', 'data': {'index': 'int'} }
934
935 ##
936 # @cpu-add:
937 #
938 # Adds CPU with specified ID
939 #
940 # @id: ID of CPU to be created, valid values [0..max_cpus)
941 #
942 # Returns: Nothing on success
943 #
944 # Since: 1.5
945 #
946 # Example:
947 #
948 # -> { "execute": "cpu-add", "arguments": { "id": 2 } }
949 # <- { "return": {} }
950 #
951 ##
952 { 'command': 'cpu-add', 'data': {'id': 'int'} }
953
954 ##
955 # @memsave:
956 #
957 # Save a portion of guest memory to a file.
958 #
959 # @val: the virtual address of the guest to start from
960 #
961 # @size: the size of memory region to save
962 #
963 # @filename: the file to save the memory to as binary data
964 #
965 # @cpu-index: the index of the virtual CPU to use for translating the
966 # virtual address (defaults to CPU 0)
967 #
968 # Returns: Nothing on success
969 #
970 # Since: 0.14.0
971 #
972 # Notes: Errors were not reliably returned until 1.1
973 #
974 # Example:
975 #
976 # -> { "execute": "memsave",
977 # "arguments": { "val": 10,
978 # "size": 100,
979 # "filename": "/tmp/virtual-mem-dump" } }
980 # <- { "return": {} }
981 #
982 ##
983 { 'command': 'memsave',
984 'data': {'val': 'int', 'size': 'int', 'filename': 'str', '*cpu-index': 'int'} }
985
986 ##
987 # @pmemsave:
988 #
989 # Save a portion of guest physical memory to a file.
990 #
991 # @val: the physical address of the guest to start from
992 #
993 # @size: the size of memory region to save
994 #
995 # @filename: the file to save the memory to as binary data
996 #
997 # Returns: Nothing on success
998 #
999 # Since: 0.14.0
1000 #
1001 # Notes: Errors were not reliably returned until 1.1
1002 #
1003 # Example:
1004 #
1005 # -> { "execute": "pmemsave",
1006 # "arguments": { "val": 10,
1007 # "size": 100,
1008 # "filename": "/tmp/physical-mem-dump" } }
1009 # <- { "return": {} }
1010 #
1011 ##
1012 { 'command': 'pmemsave',
1013 'data': {'val': 'int', 'size': 'int', 'filename': 'str'} }
1014
1015 ##
1016 # @cont:
1017 #
1018 # Resume guest VCPU execution.
1019 #
1020 # Since: 0.14.0
1021 #
1022 # Returns: If successful, nothing
1023 #
1024 # Notes: This command will succeed if the guest is currently running. It
1025 # will also succeed if the guest is in the "inmigrate" state; in
1026 # this case, the effect of the command is to make sure the guest
1027 # starts once migration finishes, removing the effect of the -S
1028 # command line option if it was passed.
1029 #
1030 # Example:
1031 #
1032 # -> { "execute": "cont" }
1033 # <- { "return": {} }
1034 #
1035 ##
1036 { 'command': 'cont' }
1037
1038 ##
1039 # @system_wakeup:
1040 #
1041 # Wakeup guest from suspend. Does nothing in case the guest isn't suspended.
1042 #
1043 # Since: 1.1
1044 #
1045 # Returns: nothing.
1046 #
1047 # Example:
1048 #
1049 # -> { "execute": "system_wakeup" }
1050 # <- { "return": {} }
1051 #
1052 ##
1053 { 'command': 'system_wakeup' }
1054
1055 ##
1056 # @inject-nmi:
1057 #
1058 # Injects a Non-Maskable Interrupt into the default CPU (x86/s390) or all CPUs (ppc64).
1059 # The command fails when the guest doesn't support injecting.
1060 #
1061 # Returns: If successful, nothing
1062 #
1063 # Since: 0.14.0
1064 #
1065 # Note: prior to 2.1, this command was only supported for x86 and s390 VMs
1066 #
1067 # Example:
1068 #
1069 # -> { "execute": "inject-nmi" }
1070 # <- { "return": {} }
1071 #
1072 ##
1073 { 'command': 'inject-nmi' }
1074
1075 ##
1076 # @balloon:
1077 #
1078 # Request the balloon driver to change its balloon size.
1079 #
1080 # @value: the target size of the balloon in bytes
1081 #
1082 # Returns: Nothing on success
1083 # If the balloon driver is enabled but not functional because the KVM
1084 # kernel module cannot support it, KvmMissingCap
1085 # If no balloon device is present, DeviceNotActive
1086 #
1087 # Notes: This command just issues a request to the guest. When it returns,
1088 # the balloon size may not have changed. A guest can change the balloon
1089 # size independent of this command.
1090 #
1091 # Since: 0.14.0
1092 #
1093 # Example:
1094 #
1095 # -> { "execute": "balloon", "arguments": { "value": 536870912 } }
1096 # <- { "return": {} }
1097 #
1098 ##
1099 { 'command': 'balloon', 'data': {'value': 'int'} }
1100
1101 ##
1102 # @human-monitor-command:
1103 #
1104 # Execute a command on the human monitor and return the output.
1105 #
1106 # @command-line: the command to execute in the human monitor
1107 #
1108 # @cpu-index: The CPU to use for commands that require an implicit CPU
1109 #
1110 # Returns: the output of the command as a string
1111 #
1112 # Since: 0.14.0
1113 #
1114 # Notes: This command only exists as a stop-gap. Its use is highly
1115 # discouraged. The semantics of this command are not
1116 # guaranteed: this means that command names, arguments and
1117 # responses can change or be removed at ANY time. Applications
1118 # that rely on long term stability guarantees should NOT
1119 # use this command.
1120 #
1121 # Known limitations:
1122 #
1123 # * This command is stateless, this means that commands that depend
1124 # on state information (such as getfd) might not work
1125 #
1126 # * Commands that prompt the user for data don't currently work
1127 #
1128 # Example:
1129 #
1130 # -> { "execute": "human-monitor-command",
1131 # "arguments": { "command-line": "info kvm" } }
1132 # <- { "return": "kvm support: enabled\r\n" }
1133 #
1134 ##
1135 { 'command': 'human-monitor-command',
1136 'data': {'command-line': 'str', '*cpu-index': 'int'},
1137 'returns': 'str' }
1138
1139 ##
1140 # @ObjectPropertyInfo:
1141 #
1142 # @name: the name of the property
1143 #
1144 # @type: the type of the property. This will typically come in one of four
1145 # forms:
1146 #
1147 # 1) A primitive type such as 'u8', 'u16', 'bool', 'str', or 'double'.
1148 # These types are mapped to the appropriate JSON type.
1149 #
1150 # 2) A child type in the form 'child<subtype>' where subtype is a qdev
1151 # device type name. Child properties create the composition tree.
1152 #
1153 # 3) A link type in the form 'link<subtype>' where subtype is a qdev
1154 # device type name. Link properties form the device model graph.
1155 #
1156 # Since: 1.2
1157 ##
1158 { 'struct': 'ObjectPropertyInfo',
1159 'data': { 'name': 'str', 'type': 'str' } }
1160
1161 ##
1162 # @qom-list:
1163 #
1164 # This command will list any properties of a object given a path in the object
1165 # model.
1166 #
1167 # @path: the path within the object model. See @qom-get for a description of
1168 # this parameter.
1169 #
1170 # Returns: a list of @ObjectPropertyInfo that describe the properties of the
1171 # object.
1172 #
1173 # Since: 1.2
1174 ##
1175 { 'command': 'qom-list',
1176 'data': { 'path': 'str' },
1177 'returns': [ 'ObjectPropertyInfo' ] }
1178
1179 ##
1180 # @qom-get:
1181 #
1182 # This command will get a property from a object model path and return the
1183 # value.
1184 #
1185 # @path: The path within the object model. There are two forms of supported
1186 # paths--absolute and partial paths.
1187 #
1188 # Absolute paths are derived from the root object and can follow child<>
1189 # or link<> properties. Since they can follow link<> properties, they
1190 # can be arbitrarily long. Absolute paths look like absolute filenames
1191 # and are prefixed with a leading slash.
1192 #
1193 # Partial paths look like relative filenames. They do not begin
1194 # with a prefix. The matching rules for partial paths are subtle but
1195 # designed to make specifying objects easy. At each level of the
1196 # composition tree, the partial path is matched as an absolute path.
1197 # The first match is not returned. At least two matches are searched
1198 # for. A successful result is only returned if only one match is
1199 # found. If more than one match is found, a flag is return to
1200 # indicate that the match was ambiguous.
1201 #
1202 # @property: The property name to read
1203 #
1204 # Returns: The property value. The type depends on the property
1205 # type. child<> and link<> properties are returned as #str
1206 # pathnames. All integer property types (u8, u16, etc) are
1207 # returned as #int.
1208 #
1209 # Since: 1.2
1210 ##
1211 { 'command': 'qom-get',
1212 'data': { 'path': 'str', 'property': 'str' },
1213 'returns': 'any' }
1214
1215 ##
1216 # @qom-set:
1217 #
1218 # This command will set a property from a object model path.
1219 #
1220 # @path: see @qom-get for a description of this parameter
1221 #
1222 # @property: the property name to set
1223 #
1224 # @value: a value who's type is appropriate for the property type. See @qom-get
1225 # for a description of type mapping.
1226 #
1227 # Since: 1.2
1228 ##
1229 { 'command': 'qom-set',
1230 'data': { 'path': 'str', 'property': 'str', 'value': 'any' } }
1231
1232 ##
1233 # @change:
1234 #
1235 # This command is multiple commands multiplexed together.
1236 #
1237 # @device: This is normally the name of a block device but it may also be 'vnc'.
1238 # when it's 'vnc', then sub command depends on @target
1239 #
1240 # @target: If @device is a block device, then this is the new filename.
1241 # If @device is 'vnc', then if the value 'password' selects the vnc
1242 # change password command. Otherwise, this specifies a new server URI
1243 # address to listen to for VNC connections.
1244 #
1245 # @arg: If @device is a block device, then this is an optional format to open
1246 # the device with.
1247 # If @device is 'vnc' and @target is 'password', this is the new VNC
1248 # password to set. See change-vnc-password for additional notes.
1249 #
1250 # Returns: Nothing on success.
1251 # If @device is not a valid block device, DeviceNotFound
1252 #
1253 # Notes: This interface is deprecated, and it is strongly recommended that you
1254 # avoid using it. For changing block devices, use
1255 # blockdev-change-medium; for changing VNC parameters, use
1256 # change-vnc-password.
1257 #
1258 # Since: 0.14.0
1259 #
1260 # Example:
1261 #
1262 # 1. Change a removable medium
1263 #
1264 # -> { "execute": "change",
1265 # "arguments": { "device": "ide1-cd0",
1266 # "target": "/srv/images/Fedora-12-x86_64-DVD.iso" } }
1267 # <- { "return": {} }
1268 #
1269 # 2. Change VNC password
1270 #
1271 # -> { "execute": "change",
1272 # "arguments": { "device": "vnc", "target": "password",
1273 # "arg": "foobar1" } }
1274 # <- { "return": {} }
1275 #
1276 ##
1277 { 'command': 'change',
1278 'data': {'device': 'str', 'target': 'str', '*arg': 'str'} }
1279
1280 ##
1281 # @ObjectTypeInfo:
1282 #
1283 # This structure describes a search result from @qom-list-types
1284 #
1285 # @name: the type name found in the search
1286 #
1287 # @abstract: the type is abstract and can't be directly instantiated.
1288 # Omitted if false. (since 2.10)
1289 #
1290 # @parent: Name of parent type, if any (since 2.10)
1291 #
1292 # Since: 1.1
1293 ##
1294 { 'struct': 'ObjectTypeInfo',
1295 'data': { 'name': 'str', '*abstract': 'bool', '*parent': 'str' } }
1296
1297 ##
1298 # @qom-list-types:
1299 #
1300 # This command will return a list of types given search parameters
1301 #
1302 # @implements: if specified, only return types that implement this type name
1303 #
1304 # @abstract: if true, include abstract types in the results
1305 #
1306 # Returns: a list of @ObjectTypeInfo or an empty list if no results are found
1307 #
1308 # Since: 1.1
1309 ##
1310 { 'command': 'qom-list-types',
1311 'data': { '*implements': 'str', '*abstract': 'bool' },
1312 'returns': [ 'ObjectTypeInfo' ] }
1313
1314 ##
1315 # @DevicePropertyInfo:
1316 #
1317 # Information about device properties.
1318 #
1319 # @name: the name of the property
1320 # @type: the typename of the property
1321 # @description: if specified, the description of the property.
1322 # (since 2.2)
1323 #
1324 # Since: 1.2
1325 ##
1326 { 'struct': 'DevicePropertyInfo',
1327 'data': { 'name': 'str', 'type': 'str', '*description': 'str' } }
1328
1329 ##
1330 # @device-list-properties:
1331 #
1332 # List properties associated with a device.
1333 #
1334 # @typename: the type name of a device
1335 #
1336 # Returns: a list of DevicePropertyInfo describing a devices properties
1337 #
1338 # Since: 1.2
1339 ##
1340 { 'command': 'device-list-properties',
1341 'data': { 'typename': 'str'},
1342 'returns': [ 'DevicePropertyInfo' ] }
1343
1344 ##
1345 # @xen-set-global-dirty-log:
1346 #
1347 # Enable or disable the global dirty log mode.
1348 #
1349 # @enable: true to enable, false to disable.
1350 #
1351 # Returns: nothing
1352 #
1353 # Since: 1.3
1354 #
1355 # Example:
1356 #
1357 # -> { "execute": "xen-set-global-dirty-log",
1358 # "arguments": { "enable": true } }
1359 # <- { "return": {} }
1360 #
1361 ##
1362 { 'command': 'xen-set-global-dirty-log', 'data': { 'enable': 'bool' } }
1363
1364 ##
1365 # @device_add:
1366 #
1367 # @driver: the name of the new device's driver
1368 #
1369 # @bus: the device's parent bus (device tree path)
1370 #
1371 # @id: the device's ID, must be unique
1372 #
1373 # Additional arguments depend on the type.
1374 #
1375 # Add a device.
1376 #
1377 # Notes:
1378 # 1. For detailed information about this command, please refer to the
1379 # 'docs/qdev-device-use.txt' file.
1380 #
1381 # 2. It's possible to list device properties by running QEMU with the
1382 # "-device DEVICE,help" command-line argument, where DEVICE is the
1383 # device's name
1384 #
1385 # Example:
1386 #
1387 # -> { "execute": "device_add",
1388 # "arguments": { "driver": "e1000", "id": "net1",
1389 # "bus": "pci.0",
1390 # "mac": "52:54:00:12:34:56" } }
1391 # <- { "return": {} }
1392 #
1393 # TODO: This command effectively bypasses QAPI completely due to its
1394 # "additional arguments" business. It shouldn't have been added to
1395 # the schema in this form. It should be qapified properly, or
1396 # replaced by a properly qapified command.
1397 #
1398 # Since: 0.13
1399 ##
1400 { 'command': 'device_add',
1401 'data': {'driver': 'str', '*bus': 'str', '*id': 'str'},
1402 'gen': false } # so we can get the additional arguments
1403
1404 ##
1405 # @device_del:
1406 #
1407 # Remove a device from a guest
1408 #
1409 # @id: the device's ID or QOM path
1410 #
1411 # Returns: Nothing on success
1412 # If @id is not a valid device, DeviceNotFound
1413 #
1414 # Notes: When this command completes, the device may not be removed from the
1415 # guest. Hot removal is an operation that requires guest cooperation.
1416 # This command merely requests that the guest begin the hot removal
1417 # process. Completion of the device removal process is signaled with a
1418 # DEVICE_DELETED event. Guest reset will automatically complete removal
1419 # for all devices.
1420 #
1421 # Since: 0.14.0
1422 #
1423 # Example:
1424 #
1425 # -> { "execute": "device_del",
1426 # "arguments": { "id": "net1" } }
1427 # <- { "return": {} }
1428 #
1429 # -> { "execute": "device_del",
1430 # "arguments": { "id": "/machine/peripheral-anon/device[0]" } }
1431 # <- { "return": {} }
1432 #
1433 ##
1434 { 'command': 'device_del', 'data': {'id': 'str'} }
1435
1436 ##
1437 # @DumpGuestMemoryFormat:
1438 #
1439 # An enumeration of guest-memory-dump's format.
1440 #
1441 # @elf: elf format
1442 #
1443 # @kdump-zlib: kdump-compressed format with zlib-compressed
1444 #
1445 # @kdump-lzo: kdump-compressed format with lzo-compressed
1446 #
1447 # @kdump-snappy: kdump-compressed format with snappy-compressed
1448 #
1449 # Since: 2.0
1450 ##
1451 { 'enum': 'DumpGuestMemoryFormat',
1452 'data': [ 'elf', 'kdump-zlib', 'kdump-lzo', 'kdump-snappy' ] }
1453
1454 ##
1455 # @dump-guest-memory:
1456 #
1457 # Dump guest's memory to vmcore. It is a synchronous operation that can take
1458 # very long depending on the amount of guest memory.
1459 #
1460 # @paging: if true, do paging to get guest's memory mapping. This allows
1461 # using gdb to process the core file.
1462 #
1463 # IMPORTANT: this option can make QEMU allocate several gigabytes
1464 # of RAM. This can happen for a large guest, or a
1465 # malicious guest pretending to be large.
1466 #
1467 # Also, paging=true has the following limitations:
1468 #
1469 # 1. The guest may be in a catastrophic state or can have corrupted
1470 # memory, which cannot be trusted
1471 # 2. The guest can be in real-mode even if paging is enabled. For
1472 # example, the guest uses ACPI to sleep, and ACPI sleep state
1473 # goes in real-mode
1474 # 3. Currently only supported on i386 and x86_64.
1475 #
1476 # @protocol: the filename or file descriptor of the vmcore. The supported
1477 # protocols are:
1478 #
1479 # 1. file: the protocol starts with "file:", and the following
1480 # string is the file's path.
1481 # 2. fd: the protocol starts with "fd:", and the following string
1482 # is the fd's name.
1483 #
1484 # @detach: if true, QMP will return immediately rather than
1485 # waiting for the dump to finish. The user can track progress
1486 # using "query-dump". (since 2.6).
1487 #
1488 # @begin: if specified, the starting physical address.
1489 #
1490 # @length: if specified, the memory size, in bytes. If you don't
1491 # want to dump all guest's memory, please specify the start @begin
1492 # and @length
1493 #
1494 # @format: if specified, the format of guest memory dump. But non-elf
1495 # format is conflict with paging and filter, ie. @paging, @begin and
1496 # @length is not allowed to be specified with non-elf @format at the
1497 # same time (since 2.0)
1498 #
1499 # Note: All boolean arguments default to false
1500 #
1501 # Returns: nothing on success
1502 #
1503 # Since: 1.2
1504 #
1505 # Example:
1506 #
1507 # -> { "execute": "dump-guest-memory",
1508 # "arguments": { "protocol": "fd:dump" } }
1509 # <- { "return": {} }
1510 #
1511 ##
1512 { 'command': 'dump-guest-memory',
1513 'data': { 'paging': 'bool', 'protocol': 'str', '*detach': 'bool',
1514 '*begin': 'int', '*length': 'int',
1515 '*format': 'DumpGuestMemoryFormat'} }
1516
1517 ##
1518 # @DumpStatus:
1519 #
1520 # Describe the status of a long-running background guest memory dump.
1521 #
1522 # @none: no dump-guest-memory has started yet.
1523 #
1524 # @active: there is one dump running in background.
1525 #
1526 # @completed: the last dump has finished successfully.
1527 #
1528 # @failed: the last dump has failed.
1529 #
1530 # Since: 2.6
1531 ##
1532 { 'enum': 'DumpStatus',
1533 'data': [ 'none', 'active', 'completed', 'failed' ] }
1534
1535 ##
1536 # @DumpQueryResult:
1537 #
1538 # The result format for 'query-dump'.
1539 #
1540 # @status: enum of @DumpStatus, which shows current dump status
1541 #
1542 # @completed: bytes written in latest dump (uncompressed)
1543 #
1544 # @total: total bytes to be written in latest dump (uncompressed)
1545 #
1546 # Since: 2.6
1547 ##
1548 { 'struct': 'DumpQueryResult',
1549 'data': { 'status': 'DumpStatus',
1550 'completed': 'int',
1551 'total': 'int' } }
1552
1553 ##
1554 # @query-dump:
1555 #
1556 # Query latest dump status.
1557 #
1558 # Returns: A @DumpStatus object showing the dump status.
1559 #
1560 # Since: 2.6
1561 #
1562 # Example:
1563 #
1564 # -> { "execute": "query-dump" }
1565 # <- { "return": { "status": "active", "completed": 1024000,
1566 # "total": 2048000 } }
1567 #
1568 ##
1569 { 'command': 'query-dump', 'returns': 'DumpQueryResult' }
1570
1571 ##
1572 # @DumpGuestMemoryCapability:
1573 #
1574 # A list of the available formats for dump-guest-memory
1575 #
1576 # Since: 2.0
1577 ##
1578 { 'struct': 'DumpGuestMemoryCapability',
1579 'data': {
1580 'formats': ['DumpGuestMemoryFormat'] } }
1581
1582 ##
1583 # @query-dump-guest-memory-capability:
1584 #
1585 # Returns the available formats for dump-guest-memory
1586 #
1587 # Returns: A @DumpGuestMemoryCapability object listing available formats for
1588 # dump-guest-memory
1589 #
1590 # Since: 2.0
1591 #
1592 # Example:
1593 #
1594 # -> { "execute": "query-dump-guest-memory-capability" }
1595 # <- { "return": { "formats":
1596 # ["elf", "kdump-zlib", "kdump-lzo", "kdump-snappy"] }
1597 #
1598 ##
1599 { 'command': 'query-dump-guest-memory-capability',
1600 'returns': 'DumpGuestMemoryCapability' }
1601
1602 ##
1603 # @dump-skeys:
1604 #
1605 # Dump guest's storage keys
1606 #
1607 # @filename: the path to the file to dump to
1608 #
1609 # This command is only supported on s390 architecture.
1610 #
1611 # Since: 2.5
1612 #
1613 # Example:
1614 #
1615 # -> { "execute": "dump-skeys",
1616 # "arguments": { "filename": "/tmp/skeys" } }
1617 # <- { "return": {} }
1618 #
1619 ##
1620 { 'command': 'dump-skeys',
1621 'data': { 'filename': 'str' } }
1622
1623 ##
1624 # @object-add:
1625 #
1626 # Create a QOM object.
1627 #
1628 # @qom-type: the class name for the object to be created
1629 #
1630 # @id: the name of the new object
1631 #
1632 # @props: a dictionary of properties to be passed to the backend
1633 #
1634 # Returns: Nothing on success
1635 # Error if @qom-type is not a valid class name
1636 #
1637 # Since: 2.0
1638 #
1639 # Example:
1640 #
1641 # -> { "execute": "object-add",
1642 # "arguments": { "qom-type": "rng-random", "id": "rng1",
1643 # "props": { "filename": "/dev/hwrng" } } }
1644 # <- { "return": {} }
1645 #
1646 ##
1647 { 'command': 'object-add',
1648 'data': {'qom-type': 'str', 'id': 'str', '*props': 'any'} }
1649
1650 ##
1651 # @object-del:
1652 #
1653 # Remove a QOM object.
1654 #
1655 # @id: the name of the QOM object to remove
1656 #
1657 # Returns: Nothing on success
1658 # Error if @id is not a valid id for a QOM object
1659 #
1660 # Since: 2.0
1661 #
1662 # Example:
1663 #
1664 # -> { "execute": "object-del", "arguments": { "id": "rng1" } }
1665 # <- { "return": {} }
1666 #
1667 ##
1668 { 'command': 'object-del', 'data': {'id': 'str'} }
1669
1670 ##
1671 # @getfd:
1672 #
1673 # Receive a file descriptor via SCM rights and assign it a name
1674 #
1675 # @fdname: file descriptor name
1676 #
1677 # Returns: Nothing on success
1678 #
1679 # Since: 0.14.0
1680 #
1681 # Notes: If @fdname already exists, the file descriptor assigned to
1682 # it will be closed and replaced by the received file
1683 # descriptor.
1684 #
1685 # The 'closefd' command can be used to explicitly close the
1686 # file descriptor when it is no longer needed.
1687 #
1688 # Example:
1689 #
1690 # -> { "execute": "getfd", "arguments": { "fdname": "fd1" } }
1691 # <- { "return": {} }
1692 #
1693 ##
1694 { 'command': 'getfd', 'data': {'fdname': 'str'} }
1695
1696 ##
1697 # @closefd:
1698 #
1699 # Close a file descriptor previously passed via SCM rights
1700 #
1701 # @fdname: file descriptor name
1702 #
1703 # Returns: Nothing on success
1704 #
1705 # Since: 0.14.0
1706 #
1707 # Example:
1708 #
1709 # -> { "execute": "closefd", "arguments": { "fdname": "fd1" } }
1710 # <- { "return": {} }
1711 #
1712 ##
1713 { 'command': 'closefd', 'data': {'fdname': 'str'} }
1714
1715 ##
1716 # @MachineInfo:
1717 #
1718 # Information describing a machine.
1719 #
1720 # @name: the name of the machine
1721 #
1722 # @alias: an alias for the machine name
1723 #
1724 # @is-default: whether the machine is default
1725 #
1726 # @cpu-max: maximum number of CPUs supported by the machine type
1727 # (since 1.5.0)
1728 #
1729 # @hotpluggable-cpus: cpu hotplug via -device is supported (since 2.7.0)
1730 #
1731 # Since: 1.2.0
1732 ##
1733 { 'struct': 'MachineInfo',
1734 'data': { 'name': 'str', '*alias': 'str',
1735 '*is-default': 'bool', 'cpu-max': 'int',
1736 'hotpluggable-cpus': 'bool'} }
1737
1738 ##
1739 # @query-machines:
1740 #
1741 # Return a list of supported machines
1742 #
1743 # Returns: a list of MachineInfo
1744 #
1745 # Since: 1.2.0
1746 ##
1747 { 'command': 'query-machines', 'returns': ['MachineInfo'] }
1748
1749 ##
1750 # @CpuDefinitionInfo:
1751 #
1752 # Virtual CPU definition.
1753 #
1754 # @name: the name of the CPU definition
1755 #
1756 # @migration-safe: whether a CPU definition can be safely used for
1757 # migration in combination with a QEMU compatibility machine
1758 # when migrating between different QMU versions and between
1759 # hosts with different sets of (hardware or software)
1760 # capabilities. If not provided, information is not available
1761 # and callers should not assume the CPU definition to be
1762 # migration-safe. (since 2.8)
1763 #
1764 # @static: whether a CPU definition is static and will not change depending on
1765 # QEMU version, machine type, machine options and accelerator options.
1766 # A static model is always migration-safe. (since 2.8)
1767 #
1768 # @unavailable-features: List of properties that prevent
1769 # the CPU model from running in the current
1770 # host. (since 2.8)
1771 # @typename: Type name that can be used as argument to @device-list-properties,
1772 # to introspect properties configurable using -cpu or -global.
1773 # (since 2.9)
1774 #
1775 # @unavailable-features is a list of QOM property names that
1776 # represent CPU model attributes that prevent the CPU from running.
1777 # If the QOM property is read-only, that means there's no known
1778 # way to make the CPU model run in the current host. Implementations
1779 # that choose not to provide specific information return the
1780 # property name "type".
1781 # If the property is read-write, it means that it MAY be possible
1782 # to run the CPU model in the current host if that property is
1783 # changed. Management software can use it as hints to suggest or
1784 # choose an alternative for the user, or just to generate meaningful
1785 # error messages explaining why the CPU model can't be used.
1786 # If @unavailable-features is an empty list, the CPU model is
1787 # runnable using the current host and machine-type.
1788 # If @unavailable-features is not present, runnability
1789 # information for the CPU is not available.
1790 #
1791 # Since: 1.2.0
1792 ##
1793 { 'struct': 'CpuDefinitionInfo',
1794 'data': { 'name': 'str', '*migration-safe': 'bool', 'static': 'bool',
1795 '*unavailable-features': [ 'str' ], 'typename': 'str' } }
1796
1797 ##
1798 # @query-cpu-definitions:
1799 #
1800 # Return a list of supported virtual CPU definitions
1801 #
1802 # Returns: a list of CpuDefInfo
1803 #
1804 # Since: 1.2.0
1805 ##
1806 { 'command': 'query-cpu-definitions', 'returns': ['CpuDefinitionInfo'] }
1807
1808 ##
1809 # @CpuModelInfo:
1810 #
1811 # Virtual CPU model.
1812 #
1813 # A CPU model consists of the name of a CPU definition, to which
1814 # delta changes are applied (e.g. features added/removed). Most magic values
1815 # that an architecture might require should be hidden behind the name.
1816 # However, if required, architectures can expose relevant properties.
1817 #
1818 # @name: the name of the CPU definition the model is based on
1819 # @props: a dictionary of QOM properties to be applied
1820 #
1821 # Since: 2.8.0
1822 ##
1823 { 'struct': 'CpuModelInfo',
1824 'data': { 'name': 'str',
1825 '*props': 'any' } }
1826
1827 ##
1828 # @CpuModelExpansionType:
1829 #
1830 # An enumeration of CPU model expansion types.
1831 #
1832 # @static: Expand to a static CPU model, a combination of a static base
1833 # model name and property delta changes. As the static base model will
1834 # never change, the expanded CPU model will be the same, independant of
1835 # independent of QEMU version, machine type, machine options, and
1836 # accelerator options. Therefore, the resulting model can be used by
1837 # tooling without having to specify a compatibility machine - e.g. when
1838 # displaying the "host" model. static CPU models are migration-safe.
1839 #
1840 # @full: Expand all properties. The produced model is not guaranteed to be
1841 # migration-safe, but allows tooling to get an insight and work with
1842 # model details.
1843 #
1844 # Note: When a non-migration-safe CPU model is expanded in static mode, some
1845 # features enabled by the CPU model may be omitted, because they can't be
1846 # implemented by a static CPU model definition (e.g. cache info passthrough and
1847 # PMU passthrough in x86). If you need an accurate representation of the
1848 # features enabled by a non-migration-safe CPU model, use @full. If you need a
1849 # static representation that will keep ABI compatibility even when changing QEMU
1850 # version or machine-type, use @static (but keep in mind that some features may
1851 # be omitted).
1852 #
1853 # Since: 2.8.0
1854 ##
1855 { 'enum': 'CpuModelExpansionType',
1856 'data': [ 'static', 'full' ] }
1857
1858
1859 ##
1860 # @CpuModelExpansionInfo:
1861 #
1862 # The result of a cpu model expansion.
1863 #
1864 # @model: the expanded CpuModelInfo.
1865 #
1866 # Since: 2.8.0
1867 ##
1868 { 'struct': 'CpuModelExpansionInfo',
1869 'data': { 'model': 'CpuModelInfo' } }
1870
1871
1872 ##
1873 # @query-cpu-model-expansion:
1874 #
1875 # Expands a given CPU model (or a combination of CPU model + additional options)
1876 # to different granularities, allowing tooling to get an understanding what a
1877 # specific CPU model looks like in QEMU under a certain configuration.
1878 #
1879 # This interface can be used to query the "host" CPU model.
1880 #
1881 # The data returned by this command may be affected by:
1882 #
1883 # * QEMU version: CPU models may look different depending on the QEMU version.
1884 # (Except for CPU models reported as "static" in query-cpu-definitions.)
1885 # * machine-type: CPU model may look different depending on the machine-type.
1886 # (Except for CPU models reported as "static" in query-cpu-definitions.)
1887 # * machine options (including accelerator): in some architectures, CPU models
1888 # may look different depending on machine and accelerator options. (Except for
1889 # CPU models reported as "static" in query-cpu-definitions.)
1890 # * "-cpu" arguments and global properties: arguments to the -cpu option and
1891 # global properties may affect expansion of CPU models. Using
1892 # query-cpu-model-expansion while using these is not advised.
1893 #
1894 # Some architectures may not support all expansion types. s390x supports
1895 # "full" and "static".
1896 #
1897 # Returns: a CpuModelExpansionInfo. Returns an error if expanding CPU models is
1898 # not supported, if the model cannot be expanded, if the model contains
1899 # an unknown CPU definition name, unknown properties or properties
1900 # with a wrong type. Also returns an error if an expansion type is
1901 # not supported.
1902 #
1903 # Since: 2.8.0
1904 ##
1905 { 'command': 'query-cpu-model-expansion',
1906 'data': { 'type': 'CpuModelExpansionType',
1907 'model': 'CpuModelInfo' },
1908 'returns': 'CpuModelExpansionInfo' }
1909
1910 ##
1911 # @CpuModelCompareResult:
1912 #
1913 # An enumeration of CPU model comparation results. The result is usually
1914 # calculated using e.g. CPU features or CPU generations.
1915 #
1916 # @incompatible: If model A is incompatible to model B, model A is not
1917 # guaranteed to run where model B runs and the other way around.
1918 #
1919 # @identical: If model A is identical to model B, model A is guaranteed to run
1920 # where model B runs and the other way around.
1921 #
1922 # @superset: If model A is a superset of model B, model B is guaranteed to run
1923 # where model A runs. There are no guarantees about the other way.
1924 #
1925 # @subset: If model A is a subset of model B, model A is guaranteed to run
1926 # where model B runs. There are no guarantees about the other way.
1927 #
1928 # Since: 2.8.0
1929 ##
1930 { 'enum': 'CpuModelCompareResult',
1931 'data': [ 'incompatible', 'identical', 'superset', 'subset' ] }
1932
1933 ##
1934 # @CpuModelCompareInfo:
1935 #
1936 # The result of a CPU model comparison.
1937 #
1938 # @result: The result of the compare operation.
1939 # @responsible-properties: List of properties that led to the comparison result
1940 # not being identical.
1941 #
1942 # @responsible-properties is a list of QOM property names that led to
1943 # both CPUs not being detected as identical. For identical models, this
1944 # list is empty.
1945 # If a QOM property is read-only, that means there's no known way to make the
1946 # CPU models identical. If the special property name "type" is included, the
1947 # models are by definition not identical and cannot be made identical.
1948 #
1949 # Since: 2.8.0
1950 ##
1951 { 'struct': 'CpuModelCompareInfo',
1952 'data': {'result': 'CpuModelCompareResult',
1953 'responsible-properties': ['str']
1954 }
1955 }
1956
1957 ##
1958 # @query-cpu-model-comparison:
1959 #
1960 # Compares two CPU models, returning how they compare in a specific
1961 # configuration. The results indicates how both models compare regarding
1962 # runnability. This result can be used by tooling to make decisions if a
1963 # certain CPU model will run in a certain configuration or if a compatible
1964 # CPU model has to be created by baselining.
1965 #
1966 # Usually, a CPU model is compared against the maximum possible CPU model
1967 # of a certain configuration (e.g. the "host" model for KVM). If that CPU
1968 # model is identical or a subset, it will run in that configuration.
1969 #
1970 # The result returned by this command may be affected by:
1971 #
1972 # * QEMU version: CPU models may look different depending on the QEMU version.
1973 # (Except for CPU models reported as "static" in query-cpu-definitions.)
1974 # * machine-type: CPU model may look different depending on the machine-type.
1975 # (Except for CPU models reported as "static" in query-cpu-definitions.)
1976 # * machine options (including accelerator): in some architectures, CPU models
1977 # may look different depending on machine and accelerator options. (Except for
1978 # CPU models reported as "static" in query-cpu-definitions.)
1979 # * "-cpu" arguments and global properties: arguments to the -cpu option and
1980 # global properties may affect expansion of CPU models. Using
1981 # query-cpu-model-expansion while using these is not advised.
1982 #
1983 # Some architectures may not support comparing CPU models. s390x supports
1984 # comparing CPU models.
1985 #
1986 # Returns: a CpuModelBaselineInfo. Returns an error if comparing CPU models is
1987 # not supported, if a model cannot be used, if a model contains
1988 # an unknown cpu definition name, unknown properties or properties
1989 # with wrong types.
1990 #
1991 # Since: 2.8.0
1992 ##
1993 { 'command': 'query-cpu-model-comparison',
1994 'data': { 'modela': 'CpuModelInfo', 'modelb': 'CpuModelInfo' },
1995 'returns': 'CpuModelCompareInfo' }
1996
1997 ##
1998 # @CpuModelBaselineInfo:
1999 #
2000 # The result of a CPU model baseline.
2001 #
2002 # @model: the baselined CpuModelInfo.
2003 #
2004 # Since: 2.8.0
2005 ##
2006 { 'struct': 'CpuModelBaselineInfo',
2007 'data': { 'model': 'CpuModelInfo' } }
2008
2009 ##
2010 # @query-cpu-model-baseline:
2011 #
2012 # Baseline two CPU models, creating a compatible third model. The created
2013 # model will always be a static, migration-safe CPU model (see "static"
2014 # CPU model expansion for details).
2015 #
2016 # This interface can be used by tooling to create a compatible CPU model out
2017 # two CPU models. The created CPU model will be identical to or a subset of
2018 # both CPU models when comparing them. Therefore, the created CPU model is
2019 # guaranteed to run where the given CPU models run.
2020 #
2021 # The result returned by this command may be affected by:
2022 #
2023 # * QEMU version: CPU models may look different depending on the QEMU version.
2024 # (Except for CPU models reported as "static" in query-cpu-definitions.)
2025 # * machine-type: CPU model may look different depending on the machine-type.
2026 # (Except for CPU models reported as "static" in query-cpu-definitions.)
2027 # * machine options (including accelerator): in some architectures, CPU models
2028 # may look different depending on machine and accelerator options. (Except for
2029 # CPU models reported as "static" in query-cpu-definitions.)
2030 # * "-cpu" arguments and global properties: arguments to the -cpu option and
2031 # global properties may affect expansion of CPU models. Using
2032 # query-cpu-model-expansion while using these is not advised.
2033 #
2034 # Some architectures may not support baselining CPU models. s390x supports
2035 # baselining CPU models.
2036 #
2037 # Returns: a CpuModelBaselineInfo. Returns an error if baselining CPU models is
2038 # not supported, if a model cannot be used, if a model contains
2039 # an unknown cpu definition name, unknown properties or properties
2040 # with wrong types.
2041 #
2042 # Since: 2.8.0
2043 ##
2044 { 'command': 'query-cpu-model-baseline',
2045 'data': { 'modela': 'CpuModelInfo',
2046 'modelb': 'CpuModelInfo' },
2047 'returns': 'CpuModelBaselineInfo' }
2048
2049 ##
2050 # @AddfdInfo:
2051 #
2052 # Information about a file descriptor that was added to an fd set.
2053 #
2054 # @fdset-id: The ID of the fd set that @fd was added to.
2055 #
2056 # @fd: The file descriptor that was received via SCM rights and
2057 # added to the fd set.
2058 #
2059 # Since: 1.2.0
2060 ##
2061 { 'struct': 'AddfdInfo', 'data': {'fdset-id': 'int', 'fd': 'int'} }
2062
2063 ##
2064 # @add-fd:
2065 #
2066 # Add a file descriptor, that was passed via SCM rights, to an fd set.
2067 #
2068 # @fdset-id: The ID of the fd set to add the file descriptor to.
2069 #
2070 # @opaque: A free-form string that can be used to describe the fd.
2071 #
2072 # Returns: @AddfdInfo on success
2073 #
2074 # If file descriptor was not received, FdNotSupplied
2075 #
2076 # If @fdset-id is a negative value, InvalidParameterValue
2077 #
2078 # Notes: The list of fd sets is shared by all monitor connections.
2079 #
2080 # If @fdset-id is not specified, a new fd set will be created.
2081 #
2082 # Since: 1.2.0
2083 #
2084 # Example:
2085 #
2086 # -> { "execute": "add-fd", "arguments": { "fdset-id": 1 } }
2087 # <- { "return": { "fdset-id": 1, "fd": 3 } }
2088 #
2089 ##
2090 { 'command': 'add-fd', 'data': {'*fdset-id': 'int', '*opaque': 'str'},
2091 'returns': 'AddfdInfo' }
2092
2093 ##
2094 # @remove-fd:
2095 #
2096 # Remove a file descriptor from an fd set.
2097 #
2098 # @fdset-id: The ID of the fd set that the file descriptor belongs to.
2099 #
2100 # @fd: The file descriptor that is to be removed.
2101 #
2102 # Returns: Nothing on success
2103 # If @fdset-id or @fd is not found, FdNotFound
2104 #
2105 # Since: 1.2.0
2106 #
2107 # Notes: The list of fd sets is shared by all monitor connections.
2108 #
2109 # If @fd is not specified, all file descriptors in @fdset-id
2110 # will be removed.
2111 #
2112 # Example:
2113 #
2114 # -> { "execute": "remove-fd", "arguments": { "fdset-id": 1, "fd": 3 } }
2115 # <- { "return": {} }
2116 #
2117 ##
2118 { 'command': 'remove-fd', 'data': {'fdset-id': 'int', '*fd': 'int'} }
2119
2120 ##
2121 # @FdsetFdInfo:
2122 #
2123 # Information about a file descriptor that belongs to an fd set.
2124 #
2125 # @fd: The file descriptor value.
2126 #
2127 # @opaque: A free-form string that can be used to describe the fd.
2128 #
2129 # Since: 1.2.0
2130 ##
2131 { 'struct': 'FdsetFdInfo',
2132 'data': {'fd': 'int', '*opaque': 'str'} }
2133
2134 ##
2135 # @FdsetInfo:
2136 #
2137 # Information about an fd set.
2138 #
2139 # @fdset-id: The ID of the fd set.
2140 #
2141 # @fds: A list of file descriptors that belong to this fd set.
2142 #
2143 # Since: 1.2.0
2144 ##
2145 { 'struct': 'FdsetInfo',
2146 'data': {'fdset-id': 'int', 'fds': ['FdsetFdInfo']} }
2147
2148 ##
2149 # @query-fdsets:
2150 #
2151 # Return information describing all fd sets.
2152 #
2153 # Returns: A list of @FdsetInfo
2154 #
2155 # Since: 1.2.0
2156 #
2157 # Note: The list of fd sets is shared by all monitor connections.
2158 #
2159 # Example:
2160 #
2161 # -> { "execute": "query-fdsets" }
2162 # <- { "return": [
2163 # {
2164 # "fds": [
2165 # {
2166 # "fd": 30,
2167 # "opaque": "rdonly:/path/to/file"
2168 # },
2169 # {
2170 # "fd": 24,
2171 # "opaque": "rdwr:/path/to/file"
2172 # }
2173 # ],
2174 # "fdset-id": 1
2175 # },
2176 # {
2177 # "fds": [
2178 # {
2179 # "fd": 28
2180 # },
2181 # {
2182 # "fd": 29
2183 # }
2184 # ],
2185 # "fdset-id": 0
2186 # }
2187 # ]
2188 # }
2189 #
2190 ##
2191 { 'command': 'query-fdsets', 'returns': ['FdsetInfo'] }
2192
2193 ##
2194 # @TargetInfo:
2195 #
2196 # Information describing the QEMU target.
2197 #
2198 # @arch: the target architecture (eg "x86_64", "i386", etc)
2199 #
2200 # Since: 1.2.0
2201 ##
2202 { 'struct': 'TargetInfo',
2203 'data': { 'arch': 'str' } }
2204
2205 ##
2206 # @query-target:
2207 #
2208 # Return information about the target for this QEMU
2209 #
2210 # Returns: TargetInfo
2211 #
2212 # Since: 1.2.0
2213 ##
2214 { 'command': 'query-target', 'returns': 'TargetInfo' }
2215
2216 ##
2217 # @AcpiTableOptions:
2218 #
2219 # Specify an ACPI table on the command line to load.
2220 #
2221 # At most one of @file and @data can be specified. The list of files specified
2222 # by any one of them is loaded and concatenated in order. If both are omitted,
2223 # @data is implied.
2224 #
2225 # Other fields / optargs can be used to override fields of the generic ACPI
2226 # table header; refer to the ACPI specification 5.0, section 5.2.6 System
2227 # Description Table Header. If a header field is not overridden, then the
2228 # corresponding value from the concatenated blob is used (in case of @file), or
2229 # it is filled in with a hard-coded value (in case of @data).
2230 #
2231 # String fields are copied into the matching ACPI member from lowest address
2232 # upwards, and silently truncated / NUL-padded to length.
2233 #
2234 # @sig: table signature / identifier (4 bytes)
2235 #
2236 # @rev: table revision number (dependent on signature, 1 byte)
2237 #
2238 # @oem_id: OEM identifier (6 bytes)
2239 #
2240 # @oem_table_id: OEM table identifier (8 bytes)
2241 #
2242 # @oem_rev: OEM-supplied revision number (4 bytes)
2243 #
2244 # @asl_compiler_id: identifier of the utility that created the table
2245 # (4 bytes)
2246 #
2247 # @asl_compiler_rev: revision number of the utility that created the
2248 # table (4 bytes)
2249 #
2250 # @file: colon (:) separated list of pathnames to load and
2251 # concatenate as table data. The resultant binary blob is expected to
2252 # have an ACPI table header. At least one file is required. This field
2253 # excludes @data.
2254 #
2255 # @data: colon (:) separated list of pathnames to load and
2256 # concatenate as table data. The resultant binary blob must not have an
2257 # ACPI table header. At least one file is required. This field excludes
2258 # @file.
2259 #
2260 # Since: 1.5
2261 ##
2262 { 'struct': 'AcpiTableOptions',
2263 'data': {
2264 '*sig': 'str',
2265 '*rev': 'uint8',
2266 '*oem_id': 'str',
2267 '*oem_table_id': 'str',
2268 '*oem_rev': 'uint32',
2269 '*asl_compiler_id': 'str',
2270 '*asl_compiler_rev': 'uint32',
2271 '*file': 'str',
2272 '*data': 'str' }}
2273
2274 ##
2275 # @CommandLineParameterType:
2276 #
2277 # Possible types for an option parameter.
2278 #
2279 # @string: accepts a character string
2280 #
2281 # @boolean: accepts "on" or "off"
2282 #
2283 # @number: accepts a number
2284 #
2285 # @size: accepts a number followed by an optional suffix (K)ilo,
2286 # (M)ega, (G)iga, (T)era
2287 #
2288 # Since: 1.5
2289 ##
2290 { 'enum': 'CommandLineParameterType',
2291 'data': ['string', 'boolean', 'number', 'size'] }
2292
2293 ##
2294 # @CommandLineParameterInfo:
2295 #
2296 # Details about a single parameter of a command line option.
2297 #
2298 # @name: parameter name
2299 #
2300 # @type: parameter @CommandLineParameterType
2301 #
2302 # @help: human readable text string, not suitable for parsing.
2303 #
2304 # @default: default value string (since 2.1)
2305 #
2306 # Since: 1.5
2307 ##
2308 { 'struct': 'CommandLineParameterInfo',
2309 'data': { 'name': 'str',
2310 'type': 'CommandLineParameterType',
2311 '*help': 'str',
2312 '*default': 'str' } }
2313
2314 ##
2315 # @CommandLineOptionInfo:
2316 #
2317 # Details about a command line option, including its list of parameter details
2318 #
2319 # @option: option name
2320 #
2321 # @parameters: an array of @CommandLineParameterInfo
2322 #
2323 # Since: 1.5
2324 ##
2325 { 'struct': 'CommandLineOptionInfo',
2326 'data': { 'option': 'str', 'parameters': ['CommandLineParameterInfo'] } }
2327
2328 ##
2329 # @query-command-line-options:
2330 #
2331 # Query command line option schema.
2332 #
2333 # @option: option name
2334 #
2335 # Returns: list of @CommandLineOptionInfo for all options (or for the given
2336 # @option). Returns an error if the given @option doesn't exist.
2337 #
2338 # Since: 1.5
2339 #
2340 # Example:
2341 #
2342 # -> { "execute": "query-command-line-options",
2343 # "arguments": { "option": "option-rom" } }
2344 # <- { "return": [
2345 # {
2346 # "parameters": [
2347 # {
2348 # "name": "romfile",
2349 # "type": "string"
2350 # },
2351 # {
2352 # "name": "bootindex",
2353 # "type": "number"
2354 # }
2355 # ],
2356 # "option": "option-rom"
2357 # }
2358 # ]
2359 # }
2360 #
2361 ##
2362 {'command': 'query-command-line-options', 'data': { '*option': 'str' },
2363 'returns': ['CommandLineOptionInfo'] }
2364
2365 ##
2366 # @X86CPURegister32:
2367 #
2368 # A X86 32-bit register
2369 #
2370 # Since: 1.5
2371 ##
2372 { 'enum': 'X86CPURegister32',
2373 'data': [ 'EAX', 'EBX', 'ECX', 'EDX', 'ESP', 'EBP', 'ESI', 'EDI' ] }
2374
2375 ##
2376 # @X86CPUFeatureWordInfo:
2377 #
2378 # Information about a X86 CPU feature word
2379 #
2380 # @cpuid-input-eax: Input EAX value for CPUID instruction for that feature word
2381 #
2382 # @cpuid-input-ecx: Input ECX value for CPUID instruction for that
2383 # feature word
2384 #
2385 # @cpuid-register: Output register containing the feature bits
2386 #
2387 # @features: value of output register, containing the feature bits
2388 #
2389 # Since: 1.5
2390 ##
2391 { 'struct': 'X86CPUFeatureWordInfo',
2392 'data': { 'cpuid-input-eax': 'int',
2393 '*cpuid-input-ecx': 'int',
2394 'cpuid-register': 'X86CPURegister32',
2395 'features': 'int' } }
2396
2397 ##
2398 # @DummyForceArrays:
2399 #
2400 # Not used by QMP; hack to let us use X86CPUFeatureWordInfoList internally
2401 #
2402 # Since: 2.5
2403 ##
2404 { 'struct': 'DummyForceArrays',
2405 'data': { 'unused': ['X86CPUFeatureWordInfo'] } }
2406
2407
2408 ##
2409 # @NumaOptionsType:
2410 #
2411 # @node: NUMA nodes configuration
2412 #
2413 # @dist: NUMA distance configuration (since 2.10)
2414 #
2415 # @cpu: property based CPU(s) to node mapping (Since: 2.10)
2416 #
2417 # Since: 2.1
2418 ##
2419 { 'enum': 'NumaOptionsType',
2420 'data': [ 'node', 'dist', 'cpu' ] }
2421
2422 ##
2423 # @NumaOptions:
2424 #
2425 # A discriminated record of NUMA options. (for OptsVisitor)
2426 #
2427 # Since: 2.1
2428 ##
2429 { 'union': 'NumaOptions',
2430 'base': { 'type': 'NumaOptionsType' },
2431 'discriminator': 'type',
2432 'data': {
2433 'node': 'NumaNodeOptions',
2434 'dist': 'NumaDistOptions',
2435 'cpu': 'NumaCpuOptions' }}
2436
2437 ##
2438 # @NumaNodeOptions:
2439 #
2440 # Create a guest NUMA node. (for OptsVisitor)
2441 #
2442 # @nodeid: NUMA node ID (increase by 1 from 0 if omitted)
2443 #
2444 # @cpus: VCPUs belonging to this node (assign VCPUS round-robin
2445 # if omitted)
2446 #
2447 # @mem: memory size of this node; mutually exclusive with @memdev.
2448 # Equally divide total memory among nodes if both @mem and @memdev are
2449 # omitted.
2450 #
2451 # @memdev: memory backend object. If specified for one node,
2452 # it must be specified for all nodes.
2453 #
2454 # Since: 2.1
2455 ##
2456 { 'struct': 'NumaNodeOptions',
2457 'data': {
2458 '*nodeid': 'uint16',
2459 '*cpus': ['uint16'],
2460 '*mem': 'size',
2461 '*memdev': 'str' }}
2462
2463 ##
2464 # @NumaDistOptions:
2465 #
2466 # Set the distance between 2 NUMA nodes.
2467 #
2468 # @src: source NUMA node.
2469 #
2470 # @dst: destination NUMA node.
2471 #
2472 # @val: NUMA distance from source node to destination node.
2473 # When a node is unreachable from another node, set the distance
2474 # between them to 255.
2475 #
2476 # Since: 2.10
2477 ##
2478 { 'struct': 'NumaDistOptions',
2479 'data': {
2480 'src': 'uint16',
2481 'dst': 'uint16',
2482 'val': 'uint8' }}
2483
2484 ##
2485 # @NumaCpuOptions:
2486 #
2487 # Option "-numa cpu" overrides default cpu to node mapping.
2488 # It accepts the same set of cpu properties as returned by
2489 # query-hotpluggable-cpus[].props, where node-id could be used to
2490 # override default node mapping.
2491 #
2492 # Since: 2.10
2493 ##
2494 { 'struct': 'NumaCpuOptions',
2495 'base': 'CpuInstanceProperties',
2496 'data' : {} }
2497
2498 ##
2499 # @HostMemPolicy:
2500 #
2501 # Host memory policy types
2502 #
2503 # @default: restore default policy, remove any nondefault policy
2504 #
2505 # @preferred: set the preferred host nodes for allocation
2506 #
2507 # @bind: a strict policy that restricts memory allocation to the
2508 # host nodes specified
2509 #
2510 # @interleave: memory allocations are interleaved across the set
2511 # of host nodes specified
2512 #
2513 # Since: 2.1
2514 ##
2515 { 'enum': 'HostMemPolicy',
2516 'data': [ 'default', 'preferred', 'bind', 'interleave' ] }
2517
2518 ##
2519 # @Memdev:
2520 #
2521 # Information about memory backend
2522 #
2523 # @id: backend's ID if backend has 'id' property (since 2.9)
2524 #
2525 # @size: memory backend size
2526 #
2527 # @merge: enables or disables memory merge support
2528 #
2529 # @dump: includes memory backend's memory in a core dump or not
2530 #
2531 # @prealloc: enables or disables memory preallocation
2532 #
2533 # @host-nodes: host nodes for its memory policy
2534 #
2535 # @policy: memory policy of memory backend
2536 #
2537 # Since: 2.1
2538 ##
2539 { 'struct': 'Memdev',
2540 'data': {
2541 '*id': 'str',
2542 'size': 'size',
2543 'merge': 'bool',
2544 'dump': 'bool',
2545 'prealloc': 'bool',
2546 'host-nodes': ['uint16'],
2547 'policy': 'HostMemPolicy' }}
2548
2549 ##
2550 # @query-memdev:
2551 #
2552 # Returns information for all memory backends.
2553 #
2554 # Returns: a list of @Memdev.
2555 #
2556 # Since: 2.1
2557 #
2558 # Example:
2559 #
2560 # -> { "execute": "query-memdev" }
2561 # <- { "return": [
2562 # {
2563 # "id": "mem1",
2564 # "size": 536870912,
2565 # "merge": false,
2566 # "dump": true,
2567 # "prealloc": false,
2568 # "host-nodes": [0, 1],
2569 # "policy": "bind"
2570 # },
2571 # {
2572 # "size": 536870912,
2573 # "merge": false,
2574 # "dump": true,
2575 # "prealloc": true,
2576 # "host-nodes": [2, 3],
2577 # "policy": "preferred"
2578 # }
2579 # ]
2580 # }
2581 #
2582 ##
2583 { 'command': 'query-memdev', 'returns': ['Memdev'] }
2584
2585 ##
2586 # @PCDIMMDeviceInfo:
2587 #
2588 # PCDIMMDevice state information
2589 #
2590 # @id: device's ID
2591 #
2592 # @addr: physical address, where device is mapped
2593 #
2594 # @size: size of memory that the device provides
2595 #
2596 # @slot: slot number at which device is plugged in
2597 #
2598 # @node: NUMA node number where device is plugged in
2599 #
2600 # @memdev: memory backend linked with device
2601 #
2602 # @hotplugged: true if device was hotplugged
2603 #
2604 # @hotpluggable: true if device if could be added/removed while machine is running
2605 #
2606 # Since: 2.1
2607 ##
2608 { 'struct': 'PCDIMMDeviceInfo',
2609 'data': { '*id': 'str',
2610 'addr': 'int',
2611 'size': 'int',
2612 'slot': 'int',
2613 'node': 'int',
2614 'memdev': 'str',
2615 'hotplugged': 'bool',
2616 'hotpluggable': 'bool'
2617 }
2618 }
2619
2620 ##
2621 # @MemoryDeviceInfo:
2622 #
2623 # Union containing information about a memory device
2624 #
2625 # Since: 2.1
2626 ##
2627 { 'union': 'MemoryDeviceInfo', 'data': {'dimm': 'PCDIMMDeviceInfo'} }
2628
2629 ##
2630 # @query-memory-devices:
2631 #
2632 # Lists available memory devices and their state
2633 #
2634 # Since: 2.1
2635 #
2636 # Example:
2637 #
2638 # -> { "execute": "query-memory-devices" }
2639 # <- { "return": [ { "data":
2640 # { "addr": 5368709120,
2641 # "hotpluggable": true,
2642 # "hotplugged": true,
2643 # "id": "d1",
2644 # "memdev": "/objects/memX",
2645 # "node": 0,
2646 # "size": 1073741824,
2647 # "slot": 0},
2648 # "type": "dimm"
2649 # } ] }
2650 #
2651 ##
2652 { 'command': 'query-memory-devices', 'returns': ['MemoryDeviceInfo'] }
2653
2654 ##
2655 # @ACPISlotType:
2656 #
2657 # @DIMM: memory slot
2658 # @CPU: logical CPU slot (since 2.7)
2659 ##
2660 { 'enum': 'ACPISlotType', 'data': [ 'DIMM', 'CPU' ] }
2661
2662 ##
2663 # @ACPIOSTInfo:
2664 #
2665 # OSPM Status Indication for a device
2666 # For description of possible values of @source and @status fields
2667 # see "_OST (OSPM Status Indication)" chapter of ACPI5.0 spec.
2668 #
2669 # @device: device ID associated with slot
2670 #
2671 # @slot: slot ID, unique per slot of a given @slot-type
2672 #
2673 # @slot-type: type of the slot
2674 #
2675 # @source: an integer containing the source event
2676 #
2677 # @status: an integer containing the status code
2678 #
2679 # Since: 2.1
2680 ##
2681 { 'struct': 'ACPIOSTInfo',
2682 'data' : { '*device': 'str',
2683 'slot': 'str',
2684 'slot-type': 'ACPISlotType',
2685 'source': 'int',
2686 'status': 'int' } }
2687
2688 ##
2689 # @query-acpi-ospm-status:
2690 #
2691 # Return a list of ACPIOSTInfo for devices that support status
2692 # reporting via ACPI _OST method.
2693 #
2694 # Since: 2.1
2695 #
2696 # Example:
2697 #
2698 # -> { "execute": "query-acpi-ospm-status" }
2699 # <- { "return": [ { "device": "d1", "slot": "0", "slot-type": "DIMM", "source": 1, "status": 0},
2700 # { "slot": "1", "slot-type": "DIMM", "source": 0, "status": 0},
2701 # { "slot": "2", "slot-type": "DIMM", "source": 0, "status": 0},
2702 # { "slot": "3", "slot-type": "DIMM", "source": 0, "status": 0}
2703 # ]}
2704 #
2705 ##
2706 { 'command': 'query-acpi-ospm-status', 'returns': ['ACPIOSTInfo'] }
2707
2708 ##
2709 # @IoOperationType:
2710 #
2711 # An enumeration of the I/O operation types
2712 #
2713 # @read: read operation
2714 #
2715 # @write: write operation
2716 #
2717 # Since: 2.1
2718 ##
2719 { 'enum': 'IoOperationType',
2720 'data': [ 'read', 'write' ] }
2721
2722 ##
2723 # @rtc-reset-reinjection:
2724 #
2725 # This command will reset the RTC interrupt reinjection backlog.
2726 # Can be used if another mechanism to synchronize guest time
2727 # is in effect, for example QEMU guest agent's guest-set-time
2728 # command.
2729 #
2730 # Since: 2.1
2731 #
2732 # Example:
2733 #
2734 # -> { "execute": "rtc-reset-reinjection" }
2735 # <- { "return": {} }
2736 #
2737 ##
2738 { 'command': 'rtc-reset-reinjection' }
2739
2740 ##
2741 # @ReplayMode:
2742 #
2743 # Mode of the replay subsystem.
2744 #
2745 # @none: normal execution mode. Replay or record are not enabled.
2746 #
2747 # @record: record mode. All non-deterministic data is written into the
2748 # replay log.
2749 #
2750 # @play: replay mode. Non-deterministic data required for system execution
2751 # is read from the log.
2752 #
2753 # Since: 2.5
2754 ##
2755 { 'enum': 'ReplayMode',
2756 'data': [ 'none', 'record', 'play' ] }
2757
2758 ##
2759 # @xen-load-devices-state:
2760 #
2761 # Load the state of all devices from file. The RAM and the block devices
2762 # of the VM are not loaded by this command.
2763 #
2764 # @filename: the file to load the state of the devices from as binary
2765 # data. See xen-save-devices-state.txt for a description of the binary
2766 # format.
2767 #
2768 # Since: 2.7
2769 #
2770 # Example:
2771 #
2772 # -> { "execute": "xen-load-devices-state",
2773 # "arguments": { "filename": "/tmp/resume" } }
2774 # <- { "return": {} }
2775 #
2776 ##
2777 { 'command': 'xen-load-devices-state', 'data': {'filename': 'str'} }
2778
2779 ##
2780 # @GICCapability:
2781 #
2782 # The struct describes capability for a specific GIC (Generic
2783 # Interrupt Controller) version. These bits are not only decided by
2784 # QEMU/KVM software version, but also decided by the hardware that
2785 # the program is running upon.
2786 #
2787 # @version: version of GIC to be described. Currently, only 2 and 3
2788 # are supported.
2789 #
2790 # @emulated: whether current QEMU/hardware supports emulated GIC
2791 # device in user space.
2792 #
2793 # @kernel: whether current QEMU/hardware supports hardware
2794 # accelerated GIC device in kernel.
2795 #
2796 # Since: 2.6
2797 ##
2798 { 'struct': 'GICCapability',
2799 'data': { 'version': 'int',
2800 'emulated': 'bool',
2801 'kernel': 'bool' } }
2802
2803 ##
2804 # @query-gic-capabilities:
2805 #
2806 # This command is ARM-only. It will return a list of GICCapability
2807 # objects that describe its capability bits.
2808 #
2809 # Returns: a list of GICCapability objects.
2810 #
2811 # Since: 2.6
2812 #
2813 # Example:
2814 #
2815 # -> { "execute": "query-gic-capabilities" }
2816 # <- { "return": [{ "version": 2, "emulated": true, "kernel": false },
2817 # { "version": 3, "emulated": false, "kernel": true } ] }
2818 #
2819 ##
2820 { 'command': 'query-gic-capabilities', 'returns': ['GICCapability'] }
2821
2822 ##
2823 # @CpuInstanceProperties:
2824 #
2825 # List of properties to be used for hotplugging a CPU instance,
2826 # it should be passed by management with device_add command when
2827 # a CPU is being hotplugged.
2828 #
2829 # @node-id: NUMA node ID the CPU belongs to
2830 # @socket-id: socket number within node/board the CPU belongs to
2831 # @core-id: core number within socket the CPU belongs to
2832 # @thread-id: thread number within core the CPU belongs to
2833 #
2834 # Note: currently there are 4 properties that could be present
2835 # but management should be prepared to pass through other
2836 # properties with device_add command to allow for future
2837 # interface extension. This also requires the filed names to be kept in
2838 # sync with the properties passed to -device/device_add.
2839 #
2840 # Since: 2.7
2841 ##
2842 { 'struct': 'CpuInstanceProperties',
2843 'data': { '*node-id': 'int',
2844 '*socket-id': 'int',
2845 '*core-id': 'int',
2846 '*thread-id': 'int'
2847 }
2848 }
2849
2850 ##
2851 # @HotpluggableCPU:
2852 #
2853 # @type: CPU object type for usage with device_add command
2854 # @props: list of properties to be used for hotplugging CPU
2855 # @vcpus-count: number of logical VCPU threads @HotpluggableCPU provides
2856 # @qom-path: link to existing CPU object if CPU is present or
2857 # omitted if CPU is not present.
2858 #
2859 # Since: 2.7
2860 ##
2861 { 'struct': 'HotpluggableCPU',
2862 'data': { 'type': 'str',
2863 'vcpus-count': 'int',
2864 'props': 'CpuInstanceProperties',
2865 '*qom-path': 'str'
2866 }
2867 }
2868
2869 ##
2870 # @query-hotpluggable-cpus:
2871 #
2872 # Returns: a list of HotpluggableCPU objects.
2873 #
2874 # Since: 2.7
2875 #
2876 # Example:
2877 #
2878 # For pseries machine type started with -smp 2,cores=2,maxcpus=4 -cpu POWER8:
2879 #
2880 # -> { "execute": "query-hotpluggable-cpus" }
2881 # <- {"return": [
2882 # { "props": { "core": 8 }, "type": "POWER8-spapr-cpu-core",
2883 # "vcpus-count": 1 },
2884 # { "props": { "core": 0 }, "type": "POWER8-spapr-cpu-core",
2885 # "vcpus-count": 1, "qom-path": "/machine/unattached/device[0]"}
2886 # ]}'
2887 #
2888 # For pc machine type started with -smp 1,maxcpus=2:
2889 #
2890 # -> { "execute": "query-hotpluggable-cpus" }
2891 # <- {"return": [
2892 # {
2893 # "type": "qemu64-x86_64-cpu", "vcpus-count": 1,
2894 # "props": {"core-id": 0, "socket-id": 1, "thread-id": 0}
2895 # },
2896 # {
2897 # "qom-path": "/machine/unattached/device[0]",
2898 # "type": "qemu64-x86_64-cpu", "vcpus-count": 1,
2899 # "props": {"core-id": 0, "socket-id": 0, "thread-id": 0}
2900 # }
2901 # ]}
2902 #
2903 ##
2904 { 'command': 'query-hotpluggable-cpus', 'returns': ['HotpluggableCPU'] }
2905
2906 ##
2907 # @GuidInfo:
2908 #
2909 # GUID information.
2910 #
2911 # @guid: the globally unique identifier
2912 #
2913 # Since: 2.9
2914 ##
2915 { 'struct': 'GuidInfo', 'data': {'guid': 'str'} }
2916
2917 ##
2918 # @query-vm-generation-id:
2919 #
2920 # Show Virtual Machine Generation ID
2921 #
2922 # Since 2.9
2923 ##
2924 { 'command': 'query-vm-generation-id', 'returns': 'GuidInfo' }