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