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