1# -*- Mode: Python -*- 2# vim: filetype=python 3# 4# This work is licensed under the terms of the GNU GPL, version 2 or later. 5# See the COPYING file in the top-level directory. 6 7## 8# ******** 9# Machines 10# ******** 11## 12 13{ 'include': 'common.json' } 14{ 'include': 'machine-common.json' } 15 16## 17# @SysEmuTarget: 18# 19# The comprehensive enumeration of QEMU system emulation ("softmmu") 20# targets. Run "./configure --help" in the project root directory, 21# and look for the \*-softmmu targets near the "--target-list" option. 22# The individual target constants are not documented here, for the 23# time being. 24# 25# @rx: since 5.0 26# 27# @avr: since 5.1 28# 29# @loongarch64: since 7.1 30# 31# .. note:: The resulting QMP strings can be appended to the 32# "qemu-system-" prefix to produce the corresponding QEMU 33# executable name. This is true even for "qemu-system-x86_64". 34# 35# Since: 3.0 36## 37{ 'enum' : 'SysEmuTarget', 38 'data' : [ 'aarch64', 'alpha', 'arm', 'avr', 'hppa', 'i386', 39 'loongarch64', 'm68k', 'microblaze', 'microblazeel', 'mips', 'mips64', 40 'mips64el', 'mipsel', 'or1k', 'ppc', 41 'ppc64', 'riscv32', 'riscv64', 'rx', 's390x', 'sh4', 42 'sh4eb', 'sparc', 'sparc64', 'tricore', 43 'x86_64', 'xtensa', 'xtensaeb' ] } 44 45## 46# @S390CpuState: 47# 48# An enumeration of cpu states that can be assumed by a virtual S390 49# CPU 50# 51# Since: 2.12 52## 53{ 'enum': 'S390CpuState', 54 'data': [ 'uninitialized', 'stopped', 'check-stop', 'operating', 'load' ] } 55 56## 57# @CpuInfoS390: 58# 59# Additional information about a virtual S390 CPU 60# 61# @cpu-state: the virtual CPU's state 62# 63# @dedicated: the virtual CPU's dedication (since 8.2) 64# 65# @entitlement: the virtual CPU's entitlement (since 8.2) 66# 67# Since: 2.12 68## 69{ 'struct': 'CpuInfoS390', 70 'data': { 'cpu-state': 'S390CpuState', 71 '*dedicated': 'bool', 72 '*entitlement': 'S390CpuEntitlement' } } 73 74## 75# @CpuInfoFast: 76# 77# Information about a virtual CPU 78# 79# @cpu-index: index of the virtual CPU 80# 81# @qom-type: QOM type name of the CPU (since 10.1) 82# 83# @qom-path: path to the CPU object in the QOM tree 84# 85# @thread-id: ID of the underlying host thread 86# 87# @props: properties associated with a virtual CPU, e.g. the socket id 88# 89# @target: the QEMU system emulation target, which determines which 90# additional fields will be listed (since 3.0) 91# 92# Since: 2.12 93## 94{ 'union' : 'CpuInfoFast', 95 'base' : { 'cpu-index' : 'int', 96 'qom-type' : 'str', 97 'qom-path' : 'str', 98 'thread-id' : 'int', 99 '*props' : 'CpuInstanceProperties', 100 'target' : 'SysEmuTarget' }, 101 'discriminator' : 'target', 102 'data' : { 's390x' : 'CpuInfoS390' } } 103 104## 105# @query-cpus-fast: 106# 107# Return information about all virtual CPUs. 108# 109# Since: 2.12 110# 111# .. qmp-example:: 112# 113# -> { "execute": "query-cpus-fast" } 114# <- { "return": [ 115# { 116# "thread-id": 25627, 117# "props": { 118# "core-id": 0, 119# "thread-id": 0, 120# "socket-id": 0 121# }, 122# "qom-path": "/machine/unattached/device[0]", 123# "target":"x86_64", 124# "cpu-index": 0 125# }, 126# { 127# "thread-id": 25628, 128# "props": { 129# "core-id": 0, 130# "thread-id": 0, 131# "socket-id": 1 132# }, 133# "qom-path": "/machine/unattached/device[2]", 134# "target":"x86_64", 135# "cpu-index": 1 136# } 137# ] 138# } 139## 140{ 'command': 'query-cpus-fast', 'returns': [ 'CpuInfoFast' ] } 141 142## 143# @CompatProperty: 144# 145# Property default values specific to a machine type, for use by 146# scripts/compare-machine-types. 147# 148# @qom-type: name of the QOM type to which the default applies 149# 150# @property: name of its property to which the default applies 151# 152# @value: the default value (machine-specific default can overwrite 153# the "default" default, to avoid this use -machine none) 154# 155# Since: 9.1 156## 157{ 'struct': 'CompatProperty', 158 'data': { 'qom-type': 'str', 159 'property': 'str', 160 'value': 'str' } } 161 162## 163# @MachineInfo: 164# 165# Information describing a machine. 166# 167# @name: the name of the machine 168# 169# @alias: an alias for the machine name 170# 171# @is-default: whether the machine is default 172# 173# @cpu-max: maximum number of CPUs supported by the machine type 174# (since 1.5) 175# 176# @hotpluggable-cpus: cpu hotplug via -device is supported (since 2.7) 177# 178# @numa-mem-supported: true if '-numa node,mem' option is supported by 179# the machine type and false otherwise (since 4.1) 180# 181# @deprecated: if true, the machine type is deprecated and may be 182# removed in future versions of QEMU according to the QEMU 183# deprecation policy (since 4.1) 184# 185# @default-cpu-type: default CPU model typename if none is requested 186# via the -cpu argument. (since 4.2) 187# 188# @default-ram-id: the default ID of initial RAM memory backend 189# (since 5.2) 190# 191# @acpi: machine type supports ACPI (since 8.0) 192# 193# @compat-props: The machine type's compatibility properties. Only 194# present when `query-machines` argument @compat-props is true. 195# (since 9.1) 196# 197# Features: 198# 199# @unstable: Member @compat-props is experimental. 200# 201# Since: 1.2 202## 203{ 'struct': 'MachineInfo', 204 'data': { 'name': 'str', '*alias': 'str', 205 '*is-default': 'bool', 'cpu-max': 'int', 206 'hotpluggable-cpus': 'bool', 'numa-mem-supported': 'bool', 207 'deprecated': 'bool', '*default-cpu-type': 'str', 208 '*default-ram-id': 'str', 'acpi': 'bool', 209 '*compat-props': { 'type': ['CompatProperty'], 210 'features': ['unstable'] } } } 211 212## 213# @query-machines: 214# 215# Return a list of supported machines 216# 217# @compat-props: if true, also return compatibility properties. 218# (default: false) (since 9.1) 219# 220# Features: 221# 222# @unstable: Argument @compat-props is experimental. 223# 224# Since: 1.2 225# 226# .. qmp-example:: 227# 228# -> { "execute": "query-machines", "arguments": { "compat-props": true } } 229# <- { "return": [ 230# { 231# "hotpluggable-cpus": true, 232# "name": "pc-q35-6.2", 233# "compat-props": [ 234# { 235# "qom-type": "virtio-mem", 236# "property": "unplugged-inaccessible", 237# "value": "off" 238# } 239# ], 240# "numa-mem-supported": false, 241# "default-cpu-type": "qemu64-x86_64-cpu", 242# "cpu-max": 288, 243# "deprecated": false, 244# "default-ram-id": "pc.ram" 245# }, 246# ... 247# } 248## 249{ 'command': 'query-machines', 250 'data': { '*compat-props': { 'type': 'bool', 251 'features': [ 'unstable' ] } }, 252 'returns': ['MachineInfo'] } 253 254## 255# @CurrentMachineParams: 256# 257# Information describing the running machine parameters. 258# 259# @wakeup-suspend-support: true if the machine supports wake up from 260# suspend 261# 262# Since: 4.0 263## 264{ 'struct': 'CurrentMachineParams', 265 'data': { 'wakeup-suspend-support': 'bool'} } 266 267## 268# @query-current-machine: 269# 270# Return information on the current virtual machine. 271# 272# Since: 4.0 273## 274{ 'command': 'query-current-machine', 'returns': 'CurrentMachineParams' } 275 276## 277# @QemuTargetInfo: 278# 279# Information on the target configuration built into the QEMU binary. 280# 281# @arch: the target architecture 282# 283# Since: 1.2 284## 285{ 'struct': 'QemuTargetInfo', 286 'data': { 'arch': 'SysEmuTarget' } } 287 288## 289# @query-target: 290# 291# Return information about the target for this QEMU 292# 293# Since: 1.2 294## 295{ 'command': 'query-target', 'returns': 'QemuTargetInfo' } 296 297## 298# @UuidInfo: 299# 300# Guest UUID information (Universally Unique Identifier). 301# 302# @UUID: the UUID of the guest 303# 304# Since: 0.14 305# 306# .. note:: If no UUID was specified for the guest, the nil UUID (all 307# zeroes) is returned. 308## 309{ 'struct': 'UuidInfo', 'data': {'UUID': 'str'} } 310 311## 312# @query-uuid: 313# 314# Query the guest UUID information. 315# 316# Since: 0.14 317# 318# .. qmp-example:: 319# 320# -> { "execute": "query-uuid" } 321# <- { "return": { "UUID": "550e8400-e29b-41d4-a716-446655440000" } } 322## 323{ 'command': 'query-uuid', 'returns': 'UuidInfo', 'allow-preconfig': true } 324 325## 326# @GuidInfo: 327# 328# GUID information. 329# 330# @guid: the globally unique identifier 331# 332# Since: 2.9 333## 334{ 'struct': 'GuidInfo', 'data': {'guid': 'str'} } 335 336## 337# @query-vm-generation-id: 338# 339# Show Virtual Machine Generation ID 340# 341# Since: 2.9 342## 343{ 'command': 'query-vm-generation-id', 'returns': 'GuidInfo' } 344 345## 346# @system_reset: 347# 348# Performs a hard reset of a guest. 349# 350# Since: 0.14 351# 352# .. qmp-example:: 353# 354# -> { "execute": "system_reset" } 355# <- { "return": {} } 356## 357{ 'command': 'system_reset' } 358 359## 360# @system_powerdown: 361# 362# Requests that a guest perform a powerdown operation. 363# 364# Since: 0.14 365# 366# .. note:: A guest may or may not respond to this command. This 367# command returning does not indicate that a guest has accepted the 368# request or that it has shut down. Many guests will respond to 369# this command by prompting the user in some way. 370# 371# .. qmp-example:: 372# 373# -> { "execute": "system_powerdown" } 374# <- { "return": {} } 375## 376{ 'command': 'system_powerdown' } 377 378## 379# @system_wakeup: 380# 381# Wake up guest from suspend. If the guest has wake-up from suspend 382# support enabled (wakeup-suspend-support flag from 383# `query-current-machine`), wake-up guest from suspend if the guest is 384# in SUSPENDED state. Return an error otherwise. 385# 386# Since: 1.1 387# 388# .. note:: Prior to 4.0, this command does nothing in case the guest 389# isn't suspended. 390# 391# .. qmp-example:: 392# 393# -> { "execute": "system_wakeup" } 394# <- { "return": {} } 395## 396{ 'command': 'system_wakeup' } 397 398## 399# @LostTickPolicy: 400# 401# Policy for handling lost ticks in timer devices. Ticks end up 402# getting lost when, for example, the guest is paused. 403# 404# @discard: throw away the missed ticks and continue with future 405# injection normally. The guest OS will see the timer jump ahead 406# by a potentially quite significant amount all at once, as if the 407# intervening chunk of time had simply not existed; needless to 408# say, such a sudden jump can easily confuse a guest OS which is 409# not specifically prepared to deal with it. Assuming the guest 410# OS can deal correctly with the time jump, the time in the guest 411# and in the host should now match. 412# 413# @delay: continue to deliver ticks at the normal rate. The guest OS 414# will not notice anything is amiss, as from its point of view 415# time will have continued to flow normally. The time in the 416# guest should now be behind the time in the host by exactly the 417# amount of time during which ticks have been missed. 418# 419# @slew: deliver ticks at a higher rate to catch up with the missed 420# ticks. The guest OS will not notice anything is amiss, as from 421# its point of view time will have continued to flow normally. 422# Once the timer has managed to catch up with all the missing 423# ticks, the time in the guest and in the host should match. 424# 425# Since: 2.0 426## 427{ 'enum': 'LostTickPolicy', 428 'data': ['discard', 'delay', 'slew' ] } 429 430## 431# @inject-nmi: 432# 433# Injects a Non-Maskable Interrupt into the default CPU (x86/s390) or 434# all CPUs (ppc64). The command fails when the guest doesn't support 435# injecting. 436# 437# Since: 0.14 438# 439# .. note:: Prior to 2.1, this command was only supported for x86 and 440# s390 VMs. 441# 442# .. qmp-example:: 443# 444# -> { "execute": "inject-nmi" } 445# <- { "return": {} } 446## 447{ 'command': 'inject-nmi' } 448 449## 450# @NumaOptionsType: 451# 452# @node: NUMA nodes configuration 453# 454# @dist: NUMA distance configuration (since 2.10) 455# 456# @cpu: property based CPU(s) to node mapping (Since: 2.10) 457# 458# @hmat-lb: memory latency and bandwidth information (Since: 5.0) 459# 460# @hmat-cache: memory side cache information (Since: 5.0) 461# 462# Since: 2.1 463## 464{ 'enum': 'NumaOptionsType', 465 'data': [ 'node', 'dist', 'cpu', 'hmat-lb', 'hmat-cache' ] } 466 467## 468# @NumaOptions: 469# 470# A discriminated record of NUMA options. (for OptsVisitor) 471# 472# @type: NUMA option type 473# 474# Since: 2.1 475## 476{ 'union': 'NumaOptions', 477 'base': { 'type': 'NumaOptionsType' }, 478 'discriminator': 'type', 479 'data': { 480 'node': 'NumaNodeOptions', 481 'dist': 'NumaDistOptions', 482 'cpu': 'NumaCpuOptions', 483 'hmat-lb': 'NumaHmatLBOptions', 484 'hmat-cache': 'NumaHmatCacheOptions' }} 485 486## 487# @NumaNodeOptions: 488# 489# Create a guest NUMA node. (for OptsVisitor) 490# 491# @nodeid: NUMA node ID (increase by 1 from 0 if omitted) 492# 493# @cpus: VCPUs belonging to this node (assign VCPUS round-robin if 494# omitted) 495# 496# @mem: memory size of this node; mutually exclusive with @memdev. 497# Equally divide total memory among nodes if both @mem and @memdev 498# are omitted. 499# 500# @memdev: memory backend object. If specified for one node, it must 501# be specified for all nodes. 502# 503# @initiator: defined in ACPI 6.3 Chapter 5.2.27.3 Table 5-145, points 504# to the nodeid which has the memory controller responsible for 505# this NUMA node. This field provides additional information as 506# to the initiator node that is closest (as in directly attached) 507# to this node, and therefore has the best performance (since 5.0) 508# 509# Since: 2.1 510## 511{ 'struct': 'NumaNodeOptions', 512 'data': { 513 '*nodeid': 'uint16', 514 '*cpus': ['uint16'], 515 '*mem': 'size', 516 '*memdev': 'str', 517 '*initiator': 'uint16' }} 518 519## 520# @NumaDistOptions: 521# 522# Set the distance between 2 NUMA nodes. 523# 524# @src: source NUMA node. 525# 526# @dst: destination NUMA node. 527# 528# @val: NUMA distance from source node to destination node. When a 529# node is unreachable from another node, set the distance between 530# them to 255. 531# 532# Since: 2.10 533## 534{ 'struct': 'NumaDistOptions', 535 'data': { 536 'src': 'uint16', 537 'dst': 'uint16', 538 'val': 'uint8' }} 539 540## 541# @CXLFixedMemoryWindowOptions: 542# 543# Create a CXL Fixed Memory Window 544# 545# @size: Size of the Fixed Memory Window in bytes. Must be a multiple 546# of 256MiB. 547# 548# @interleave-granularity: Number of contiguous bytes for which 549# accesses will go to a given interleave target. Accepted values 550# [256, 512, 1k, 2k, 4k, 8k, 16k] 551# 552# @targets: Target root bridge IDs from -device ...,id=<ID> for each 553# root bridge. 554# 555# Since: 7.1 556## 557{ 'struct': 'CXLFixedMemoryWindowOptions', 558 'data': { 559 'size': 'size', 560 '*interleave-granularity': 'size', 561 'targets': ['str'] }} 562 563## 564# @CXLFMWProperties: 565# 566# List of CXL Fixed Memory Windows. 567# 568# @cxl-fmw: List of `CXLFixedMemoryWindowOptions` 569# 570# Since: 7.1 571## 572{ 'struct' : 'CXLFMWProperties', 573 'data': { 'cxl-fmw': ['CXLFixedMemoryWindowOptions'] } 574} 575 576## 577# @X86CPURegister32: 578# 579# A X86 32-bit register 580# 581# Since: 1.5 582## 583{ 'enum': 'X86CPURegister32', 584 'data': [ 'EAX', 'EBX', 'ECX', 'EDX', 'ESP', 'EBP', 'ESI', 'EDI' ] } 585 586## 587# @X86CPUFeatureWordInfo: 588# 589# Information about a X86 CPU feature word 590# 591# @cpuid-input-eax: Input EAX value for CPUID instruction for that 592# feature word 593# 594# @cpuid-input-ecx: Input ECX value for CPUID instruction for that 595# feature word 596# 597# @cpuid-register: Output register containing the feature bits 598# 599# @features: value of output register, containing the feature bits 600# 601# Since: 1.5 602## 603{ 'struct': 'X86CPUFeatureWordInfo', 604 'data': { 'cpuid-input-eax': 'int', 605 '*cpuid-input-ecx': 'int', 606 'cpuid-register': 'X86CPURegister32', 607 'features': 'int' } } 608 609## 610# @DummyForceArrays: 611# 612# Not used by QMP; hack to let us use X86CPUFeatureWordInfoList 613# internally 614# 615# Since: 2.5 616## 617{ 'struct': 'DummyForceArrays', 618 'data': { 'unused': ['X86CPUFeatureWordInfo'] } } 619 620## 621# @NumaCpuOptions: 622# 623# Option "-numa cpu" overrides default cpu to node mapping. It accepts 624# the same set of cpu properties as returned by 625# `query-hotpluggable-cpus[].props <query-hotpluggable-cpus>`, where 626# node-id could be used to override default node mapping. 627# 628# Since: 2.10 629## 630{ 'struct': 'NumaCpuOptions', 631 'base': 'CpuInstanceProperties', 632 'data' : {} } 633 634## 635# @HmatLBMemoryHierarchy: 636# 637# The memory hierarchy in the System Locality Latency and Bandwidth 638# Information Structure of HMAT (Heterogeneous Memory Attribute Table) 639# 640# For more information about `HmatLBMemoryHierarchy`, see chapter 641# 5.2.27.4: Table 5-146: Field "Flags" of ACPI 6.3 spec. 642# 643# @memory: the structure represents the memory performance 644# 645# @first-level: first level of memory side cache 646# 647# @second-level: second level of memory side cache 648# 649# @third-level: third level of memory side cache 650# 651# Since: 5.0 652## 653{ 'enum': 'HmatLBMemoryHierarchy', 654 'data': [ 'memory', 'first-level', 'second-level', 'third-level' ] } 655 656## 657# @HmatLBDataType: 658# 659# Data type in the System Locality Latency and Bandwidth Information 660# Structure of HMAT (Heterogeneous Memory Attribute Table) 661# 662# For more information about `HmatLBDataType`, see chapter 5.2.27.4: 663# Table 5-146: Field "Data Type" of ACPI 6.3 spec. 664# 665# @access-latency: access latency (nanoseconds) 666# 667# @read-latency: read latency (nanoseconds) 668# 669# @write-latency: write latency (nanoseconds) 670# 671# @access-bandwidth: access bandwidth (Bytes per second) 672# 673# @read-bandwidth: read bandwidth (Bytes per second) 674# 675# @write-bandwidth: write bandwidth (Bytes per second) 676# 677# Since: 5.0 678## 679{ 'enum': 'HmatLBDataType', 680 'data': [ 'access-latency', 'read-latency', 'write-latency', 681 'access-bandwidth', 'read-bandwidth', 'write-bandwidth' ] } 682 683## 684# @NumaHmatLBOptions: 685# 686# Set the system locality latency and bandwidth information between 687# Initiator and Target proximity Domains. 688# 689# For more information about `NumaHmatLBOptions`, see chapter 5.2.27.4: 690# Table 5-146 of ACPI 6.3 spec. 691# 692# @initiator: the Initiator Proximity Domain. 693# 694# @target: the Target Proximity Domain. 695# 696# @hierarchy: the Memory Hierarchy. Indicates the performance of 697# memory or side cache. 698# 699# @data-type: presents the type of data, access/read/write latency or 700# hit latency. 701# 702# @latency: the value of latency from @initiator to @target proximity 703# domain, the latency unit is "ns(nanosecond)". 704# 705# @bandwidth: the value of bandwidth between @initiator and @target 706# proximity domain, the bandwidth unit is "Bytes per second". 707# 708# Since: 5.0 709## 710{ 'struct': 'NumaHmatLBOptions', 711 'data': { 712 'initiator': 'uint16', 713 'target': 'uint16', 714 'hierarchy': 'HmatLBMemoryHierarchy', 715 'data-type': 'HmatLBDataType', 716 '*latency': 'uint64', 717 '*bandwidth': 'size' }} 718 719## 720# @HmatCacheAssociativity: 721# 722# Cache associativity in the Memory Side Cache Information Structure 723# of HMAT 724# 725# For more information of `HmatCacheAssociativity`, see chapter 726# 5.2.27.5: Table 5-147 of ACPI 6.3 spec. 727# 728# @none: None (no memory side cache in this proximity domain, or cache 729# associativity unknown) 730# 731# @direct: Direct Mapped 732# 733# @complex: Complex Cache Indexing (implementation specific) 734# 735# Since: 5.0 736## 737{ 'enum': 'HmatCacheAssociativity', 738 'data': [ 'none', 'direct', 'complex' ] } 739 740## 741# @HmatCacheWritePolicy: 742# 743# Cache write policy in the Memory Side Cache Information Structure of 744# HMAT 745# 746# For more information of `HmatCacheWritePolicy`, see chapter 5.2.27.5: 747# Table 5-147: Field "Cache Attributes" of ACPI 6.3 spec. 748# 749# @none: None (no memory side cache in this proximity domain, or cache 750# write policy unknown) 751# 752# @write-back: Write Back (WB) 753# 754# @write-through: Write Through (WT) 755# 756# Since: 5.0 757## 758{ 'enum': 'HmatCacheWritePolicy', 759 'data': [ 'none', 'write-back', 'write-through' ] } 760 761## 762# @NumaHmatCacheOptions: 763# 764# Set the memory side cache information for a given memory domain. 765# 766# For more information of `NumaHmatCacheOptions`, see chapter 5.2.27.5: 767# Table 5-147: Field "Cache Attributes" of ACPI 6.3 spec. 768# 769# @node-id: the memory proximity domain to which the memory belongs. 770# 771# @size: the size of memory side cache in bytes. 772# 773# @level: the cache level described in this structure. 774# 775# @associativity: the cache associativity, 776# none/direct-mapped/complex(complex cache indexing). 777# 778# @policy: the write policy, none/write-back/write-through. 779# 780# @line: the cache line size in bytes. 781# 782# Since: 5.0 783## 784{ 'struct': 'NumaHmatCacheOptions', 785 'data': { 786 'node-id': 'uint32', 787 'size': 'size', 788 'level': 'uint8', 789 'associativity': 'HmatCacheAssociativity', 790 'policy': 'HmatCacheWritePolicy', 791 'line': 'uint16' }} 792 793## 794# @memsave: 795# 796# Save a portion of guest memory to a file. 797# 798# @val: the virtual address of the guest to start from 799# 800# @size: the size of memory region to save 801# 802# @filename: the file to save the memory to as binary data 803# 804# @cpu-index: the index of the virtual CPU to use for translating the 805# virtual address (defaults to CPU 0) 806# 807# Since: 0.14 808# 809# .. caution:: Errors were not reliably returned until 1.1. 810# 811# .. qmp-example:: 812# 813# -> { "execute": "memsave", 814# "arguments": { "val": 10, 815# "size": 100, 816# "filename": "/tmp/virtual-mem-dump" } } 817# <- { "return": {} } 818## 819{ 'command': 'memsave', 820 'data': { 821 'val': 'uint64', 822 'size': 'size', 823 'filename': 'str', 824 '*cpu-index': 'int' } } 825 826## 827# @pmemsave: 828# 829# Save a portion of guest physical memory to a file. 830# 831# @val: the physical address of the guest to start from 832# 833# @size: the size of memory region to save 834# 835# @filename: the file to save the memory to as binary data 836# 837# Since: 0.14 838# 839# .. caution:: Errors were not reliably returned until 1.1. 840# 841# .. qmp-example:: 842# 843# -> { "execute": "pmemsave", 844# "arguments": { "val": 10, 845# "size": 100, 846# "filename": "/tmp/physical-mem-dump" } } 847# <- { "return": {} } 848## 849{ 'command': 'pmemsave', 850 'data': { 851 'val': 'uint64', 852 'size': 'size', 853 'filename': 'str' } } 854 855## 856# @Memdev: 857# 858# Information about memory backend 859# 860# @id: backend's ID if backend has 'id' property (since 2.9) 861# 862# @size: memory backend size 863# 864# @merge: whether memory merge support is enabled 865# 866# @dump: whether memory backend's memory is included in a core dump 867# 868# @prealloc: whether memory was preallocated 869# 870# @share: whether memory is private to QEMU or shared (since 6.1) 871# 872# @reserve: whether swap space (or huge pages) was reserved if 873# applicable. This corresponds to the user configuration and not 874# the actual behavior implemented in the OS to perform the 875# reservation. For example, Linux will never reserve swap space 876# for shared file mappings. (since 6.1) 877# 878# @host-nodes: host nodes for its memory policy 879# 880# @policy: memory policy of memory backend 881# 882# Since: 2.1 883## 884{ 'struct': 'Memdev', 885 'data': { 886 '*id': 'str', 887 'size': 'size', 888 'merge': 'bool', 889 'dump': 'bool', 890 'prealloc': 'bool', 891 'share': 'bool', 892 '*reserve': 'bool', 893 'host-nodes': ['uint16'], 894 'policy': 'HostMemPolicy' }} 895 896## 897# @query-memdev: 898# 899# Return information for all memory backends. 900# 901# Since: 2.1 902# 903# .. qmp-example:: 904# 905# -> { "execute": "query-memdev" } 906# <- { "return": [ 907# { 908# "id": "mem1", 909# "size": 536870912, 910# "merge": false, 911# "dump": true, 912# "prealloc": false, 913# "share": false, 914# "host-nodes": [0, 1], 915# "policy": "bind" 916# }, 917# { 918# "size": 536870912, 919# "merge": false, 920# "dump": true, 921# "prealloc": true, 922# "share": false, 923# "host-nodes": [2, 3], 924# "policy": "preferred" 925# } 926# ] 927# } 928## 929{ 'command': 'query-memdev', 'returns': ['Memdev'], 'allow-preconfig': true } 930 931## 932# @CpuInstanceProperties: 933# 934# Properties identifying a CPU. 935# 936# Which members are optional and which mandatory depends on the 937# architecture and board. 938# 939# For s390x see :ref:`cpu-topology-s390x`. 940# 941# The ids other than the node-id specify the position of the CPU 942# within the CPU topology (as defined by the machine property "smp", 943# thus see also type `SMPConfiguration`) 944# 945# @node-id: NUMA node ID the CPU belongs to 946# 947# @drawer-id: drawer number within CPU topology the CPU belongs to 948# (since 8.2) 949# 950# @book-id: book number within parent container the CPU belongs to 951# (since 8.2) 952# 953# @socket-id: socket number within parent container the CPU belongs to 954# 955# @die-id: die number within the parent container the CPU belongs to 956# (since 4.1) 957# 958# @cluster-id: cluster number within the parent container the CPU 959# belongs to (since 7.1) 960# 961# @module-id: module number within the parent container the CPU 962# belongs to (since 9.1) 963# 964# @core-id: core number within the parent container the CPU belongs to 965# 966# @thread-id: thread number within the core the CPU belongs to 967# 968# Since: 2.7 969## 970{ 'struct': 'CpuInstanceProperties', 971 # Keep these in sync with the properties `device_add` accepts 972 'data': { '*node-id': 'int', 973 '*drawer-id': 'int', 974 '*book-id': 'int', 975 '*socket-id': 'int', 976 '*die-id': 'int', 977 '*cluster-id': 'int', 978 '*module-id': 'int', 979 '*core-id': 'int', 980 '*thread-id': 'int' 981 } 982} 983 984## 985# @HotpluggableCPU: 986# 987# @type: CPU object type for usage with `device_add` command 988# 989# @props: list of properties to pass for hotplugging a CPU with 990# `device_add` 991# 992# @vcpus-count: number of logical VCPU threads `HotpluggableCPU` 993# provides 994# 995# @qom-path: link to existing CPU object if CPU is present or omitted 996# if CPU is not present. 997# 998# .. note:: Management should be prepared to pass through additional 999# properties with `device_add`. 1000# 1001# Since: 2.7 1002## 1003{ 'struct': 'HotpluggableCPU', 1004 'data': { 'type': 'str', 1005 'vcpus-count': 'int', 1006 'props': 'CpuInstanceProperties', 1007 '*qom-path': 'str' 1008 } 1009} 1010 1011## 1012# @query-hotpluggable-cpus: 1013# 1014# TODO: Better documentation; currently there is none. 1015# 1016# Since: 2.7 1017# 1018# .. qmp-example:: 1019# :annotated: 1020# 1021# For pseries machine type started with 1022# ``-smp 2,cores=2,maxcpus=4 -cpu POWER8``:: 1023# 1024# -> { "execute": "query-hotpluggable-cpus" } 1025# <- {"return": [ 1026# { "props": { "core-id": 8 }, "type": "POWER8-spapr-cpu-core", 1027# "vcpus-count": 1 }, 1028# { "props": { "core-id": 0 }, "type": "POWER8-spapr-cpu-core", 1029# "vcpus-count": 1, "qom-path": "/machine/unattached/device[0]"} 1030# ]} 1031# 1032# .. qmp-example:: 1033# :annotated: 1034# 1035# For pc machine type started with ``-smp 1,maxcpus=2``:: 1036# 1037# -> { "execute": "query-hotpluggable-cpus" } 1038# <- {"return": [ 1039# { 1040# "type": "qemu64-x86_64-cpu", "vcpus-count": 1, 1041# "props": {"core-id": 0, "socket-id": 1, "thread-id": 0} 1042# }, 1043# { 1044# "qom-path": "/machine/unattached/device[0]", 1045# "type": "qemu64-x86_64-cpu", "vcpus-count": 1, 1046# "props": {"core-id": 0, "socket-id": 0, "thread-id": 0} 1047# } 1048# ]} 1049# 1050# .. qmp-example:: 1051# :annotated: 1052# 1053# For s390x-virtio-ccw machine type started with 1054# ``-smp 1,maxcpus=2 -cpu qemu``:: 1055# 1056# -> { "execute": "query-hotpluggable-cpus" } 1057# <- {"return": [ 1058# { 1059# "type": "qemu-s390x-cpu", "vcpus-count": 1, 1060# "props": { "core-id": 1 } 1061# }, 1062# { 1063# "qom-path": "/machine/unattached/device[0]", 1064# "type": "qemu-s390x-cpu", "vcpus-count": 1, 1065# "props": { "core-id": 0 } 1066# } 1067# ]} 1068## 1069{ 'command': 'query-hotpluggable-cpus', 'returns': ['HotpluggableCPU'], 1070 'allow-preconfig': true } 1071 1072## 1073# @set-numa-node: 1074# 1075# Runtime equivalent of '-numa' CLI option, available at preconfigure 1076# stage to configure numa mapping before initializing machine. 1077# 1078# Since: 3.0 1079## 1080{ 'command': 'set-numa-node', 'boxed': true, 1081 'data': 'NumaOptions', 1082 'allow-preconfig': true 1083} 1084 1085## 1086# @balloon: 1087# 1088# Request the balloon driver to change its balloon size. 1089# 1090# @value: the target logical size of the VM in bytes. We can deduce 1091# the size of the balloon using this formula: 1092# 1093# logical_vm_size = vm_ram_size - balloon_size 1094# 1095# From it we have: balloon_size = vm_ram_size - @value 1096# 1097# Errors: 1098# - If the balloon driver is enabled but not functional because 1099# the KVM kernel module cannot support it, KVMMissingCap 1100# - If no balloon device is present, DeviceNotActive 1101# 1102# .. note:: This command just issues a request to the guest. When it 1103# returns, the balloon size may not have changed. A guest can 1104# change the balloon size independent of this command. 1105# 1106# Since: 0.14 1107# 1108# .. qmp-example:: 1109# :annotated: 1110# 1111# :: 1112# 1113# -> { "execute": "balloon", "arguments": { "value": 536870912 } } 1114# <- { "return": {} } 1115# 1116# With a 2.5GiB guest this command inflated the ballon to 3GiB. 1117## 1118{ 'command': 'balloon', 'data': {'value': 'int'} } 1119 1120## 1121# @BalloonInfo: 1122# 1123# Information about the guest balloon device. 1124# 1125# @actual: the logical size of the VM in bytes. Formula used: 1126# logical_vm_size = vm_ram_size - balloon_size 1127# 1128# Since: 0.14 1129## 1130{ 'struct': 'BalloonInfo', 'data': {'actual': 'int' } } 1131 1132## 1133# @query-balloon: 1134# 1135# Return information about the balloon device. 1136# 1137# Errors: 1138# - If the balloon driver is enabled but not functional because 1139# the KVM kernel module cannot support it, KVMMissingCap 1140# - If no balloon device is present, DeviceNotActive 1141# 1142# Since: 0.14 1143# 1144# .. qmp-example:: 1145# 1146# -> { "execute": "query-balloon" } 1147# <- { "return": { 1148# "actual": 1073741824 1149# } 1150# } 1151## 1152{ 'command': 'query-balloon', 'returns': 'BalloonInfo' } 1153 1154## 1155# @BALLOON_CHANGE: 1156# 1157# Emitted when the guest changes the actual BALLOON level. This value 1158# is equivalent to the @actual field return by the `query-balloon` 1159# command 1160# 1161# @actual: the logical size of the VM in bytes. Formula used: 1162# logical_vm_size = vm_ram_size - balloon_size 1163# 1164# .. note:: This event is rate-limited. 1165# 1166# Since: 1.2 1167# 1168# .. qmp-example:: 1169# 1170# <- { "event": "BALLOON_CHANGE", 1171# "data": { "actual": 944766976 }, 1172# "timestamp": { "seconds": 1267020223, "microseconds": 435656 } } 1173## 1174{ 'event': 'BALLOON_CHANGE', 1175 'data': { 'actual': 'int' } } 1176 1177## 1178# @HvBalloonInfo: 1179# 1180# hv-balloon guest-provided memory status information. 1181# 1182# @committed: the amount of memory in use inside the guest plus the 1183# amount of the memory unusable inside the guest (ballooned out, 1184# offline, etc.) 1185# 1186# @available: the amount of the memory inside the guest available for 1187# new allocations ("free") 1188# 1189# Since: 8.2 1190## 1191{ 'struct': 'HvBalloonInfo', 1192 'data': { 'committed': 'size', 'available': 'size' } } 1193 1194## 1195# @query-hv-balloon-status-report: 1196# 1197# Return the hv-balloon driver data contained in the last received 1198# "STATUS" message from the guest. 1199# 1200# Errors: 1201# - If no hv-balloon device is present, guest memory status 1202# reporting is not enabled or no guest memory status report 1203# received yet, GenericError 1204# 1205# Since: 8.2 1206# 1207# .. qmp-example:: 1208# 1209# -> { "execute": "query-hv-balloon-status-report" } 1210# <- { "return": { 1211# "committed": 816640000, 1212# "available": 3333054464 1213# } 1214# } 1215## 1216{ 'command': 'query-hv-balloon-status-report', 'returns': 'HvBalloonInfo' } 1217 1218## 1219# @HV_BALLOON_STATUS_REPORT: 1220# 1221# Emitted when the hv-balloon driver receives a "STATUS" message from 1222# the guest. 1223# 1224# .. note:: This event is rate-limited. 1225# 1226# Since: 8.2 1227# 1228# .. qmp-example:: 1229# 1230# <- { "event": "HV_BALLOON_STATUS_REPORT", 1231# "data": { "committed": 816640000, "available": 3333054464 }, 1232# "timestamp": { "seconds": 1600295492, "microseconds": 661044 } } 1233## 1234{ 'event': 'HV_BALLOON_STATUS_REPORT', 1235 'data': 'HvBalloonInfo' } 1236 1237## 1238# @MemoryInfo: 1239# 1240# Actual memory information in bytes. 1241# 1242# @base-memory: size of "base" memory specified with command line 1243# option -m. 1244# 1245# @plugged-memory: size of memory that can be hot-unplugged. This 1246# field is omitted if target doesn't support memory hotplug (i.e. 1247# CONFIG_MEM_DEVICE not defined at build time). 1248# 1249# Since: 2.11 1250## 1251{ 'struct': 'MemoryInfo', 1252 'data' : { 'base-memory': 'size', '*plugged-memory': 'size' } } 1253 1254## 1255# @query-memory-size-summary: 1256# 1257# Return the amount of initially allocated and present hotpluggable 1258# (if enabled) memory in bytes. 1259# 1260# TODO: This line is a hack to separate the example from the body 1261# 1262# .. qmp-example:: 1263# 1264# -> { "execute": "query-memory-size-summary" } 1265# <- { "return": { "base-memory": 4294967296, "plugged-memory": 0 } } 1266# 1267# Since: 2.11 1268## 1269{ 'command': 'query-memory-size-summary', 'returns': 'MemoryInfo' } 1270 1271## 1272# @PCDIMMDeviceInfo: 1273# 1274# PCDIMMDevice state information 1275# 1276# @id: device's ID 1277# 1278# @addr: physical address, where device is mapped 1279# 1280# @size: size of memory that the device provides 1281# 1282# @slot: slot number at which device is plugged in 1283# 1284# @node: NUMA node number where device is plugged in 1285# 1286# @memdev: memory backend linked with device 1287# 1288# @hotplugged: true if device was hotplugged 1289# 1290# @hotpluggable: true if device if could be added/removed while 1291# machine is running 1292# 1293# Since: 2.1 1294## 1295{ 'struct': 'PCDIMMDeviceInfo', 1296 'data': { '*id': 'str', 1297 'addr': 'int', 1298 'size': 'int', 1299 'slot': 'int', 1300 'node': 'int', 1301 'memdev': 'str', 1302 'hotplugged': 'bool', 1303 'hotpluggable': 'bool' 1304 } 1305} 1306 1307## 1308# @VirtioPMEMDeviceInfo: 1309# 1310# VirtioPMEM state information 1311# 1312# @id: device's ID 1313# 1314# @memaddr: physical address in memory, where device is mapped 1315# 1316# @size: size of memory that the device provides 1317# 1318# @memdev: memory backend linked with device 1319# 1320# Since: 4.1 1321## 1322{ 'struct': 'VirtioPMEMDeviceInfo', 1323 'data': { '*id': 'str', 1324 'memaddr': 'size', 1325 'size': 'size', 1326 'memdev': 'str' 1327 } 1328} 1329 1330## 1331# @VirtioMEMDeviceInfo: 1332# 1333# VirtioMEMDevice state information 1334# 1335# @id: device's ID 1336# 1337# @memaddr: physical address in memory, where device is mapped 1338# 1339# @requested-size: the user requested size of the device 1340# 1341# @size: the (current) size of memory that the device provides 1342# 1343# @max-size: the maximum size of memory that the device can provide 1344# 1345# @block-size: the block size of memory that the device provides 1346# 1347# @node: NUMA node number where device is assigned to 1348# 1349# @memdev: memory backend linked with the region 1350# 1351# Since: 5.1 1352## 1353{ 'struct': 'VirtioMEMDeviceInfo', 1354 'data': { '*id': 'str', 1355 'memaddr': 'size', 1356 'requested-size': 'size', 1357 'size': 'size', 1358 'max-size': 'size', 1359 'block-size': 'size', 1360 'node': 'int', 1361 'memdev': 'str' 1362 } 1363} 1364 1365## 1366# @SgxEPCDeviceInfo: 1367# 1368# Sgx EPC state information 1369# 1370# @id: device's ID 1371# 1372# @memaddr: physical address in memory, where device is mapped 1373# 1374# @size: size of memory that the device provides 1375# 1376# @memdev: memory backend linked with device 1377# 1378# @node: the numa node (Since: 7.0) 1379# 1380# Since: 6.2 1381## 1382{ 'struct': 'SgxEPCDeviceInfo', 1383 'data': { '*id': 'str', 1384 'memaddr': 'size', 1385 'size': 'size', 1386 'node': 'int', 1387 'memdev': 'str' 1388 } 1389} 1390 1391## 1392# @HvBalloonDeviceInfo: 1393# 1394# hv-balloon provided memory state information 1395# 1396# @id: device's ID 1397# 1398# @memaddr: physical address in memory, where device is mapped 1399# 1400# @max-size: the maximum size of memory that the device can provide 1401# 1402# @memdev: memory backend linked with device 1403# 1404# Since: 8.2 1405## 1406{ 'struct': 'HvBalloonDeviceInfo', 1407 'data': { '*id': 'str', 1408 '*memaddr': 'size', 1409 'max-size': 'size', 1410 '*memdev': 'str' 1411 } 1412} 1413 1414## 1415# @MemoryDeviceInfoKind: 1416# 1417# @nvdimm: since 2.12 1418# 1419# @virtio-pmem: since 4.1 1420# 1421# @virtio-mem: since 5.1 1422# 1423# @sgx-epc: since 6.2. 1424# 1425# @hv-balloon: since 8.2. 1426# 1427# Since: 2.1 1428## 1429{ 'enum': 'MemoryDeviceInfoKind', 1430 'data': [ 'dimm', 'nvdimm', 'virtio-pmem', 'virtio-mem', 'sgx-epc', 1431 'hv-balloon' ] } 1432 1433## 1434# @PCDIMMDeviceInfoWrapper: 1435# 1436# @data: PCDIMMDevice state information 1437# 1438# Since: 2.1 1439## 1440{ 'struct': 'PCDIMMDeviceInfoWrapper', 1441 'data': { 'data': 'PCDIMMDeviceInfo' } } 1442 1443## 1444# @VirtioPMEMDeviceInfoWrapper: 1445# 1446# @data: VirtioPMEM state information 1447# 1448# Since: 2.1 1449## 1450{ 'struct': 'VirtioPMEMDeviceInfoWrapper', 1451 'data': { 'data': 'VirtioPMEMDeviceInfo' } } 1452 1453## 1454# @VirtioMEMDeviceInfoWrapper: 1455# 1456# @data: VirtioMEMDevice state information 1457# 1458# Since: 2.1 1459## 1460{ 'struct': 'VirtioMEMDeviceInfoWrapper', 1461 'data': { 'data': 'VirtioMEMDeviceInfo' } } 1462 1463## 1464# @SgxEPCDeviceInfoWrapper: 1465# 1466# @data: Sgx EPC state information 1467# 1468# Since: 6.2 1469## 1470{ 'struct': 'SgxEPCDeviceInfoWrapper', 1471 'data': { 'data': 'SgxEPCDeviceInfo' } } 1472 1473## 1474# @HvBalloonDeviceInfoWrapper: 1475# 1476# @data: hv-balloon provided memory state information 1477# 1478# Since: 8.2 1479## 1480{ 'struct': 'HvBalloonDeviceInfoWrapper', 1481 'data': { 'data': 'HvBalloonDeviceInfo' } } 1482 1483## 1484# @MemoryDeviceInfo: 1485# 1486# Union containing information about a memory device 1487# 1488# @type: memory device type 1489# 1490# Since: 2.1 1491## 1492{ 'union': 'MemoryDeviceInfo', 1493 'base': { 'type': 'MemoryDeviceInfoKind' }, 1494 'discriminator': 'type', 1495 'data': { 'dimm': 'PCDIMMDeviceInfoWrapper', 1496 'nvdimm': 'PCDIMMDeviceInfoWrapper', 1497 'virtio-pmem': 'VirtioPMEMDeviceInfoWrapper', 1498 'virtio-mem': 'VirtioMEMDeviceInfoWrapper', 1499 'sgx-epc': 'SgxEPCDeviceInfoWrapper', 1500 'hv-balloon': 'HvBalloonDeviceInfoWrapper' 1501 } 1502} 1503 1504## 1505# @SgxEPC: 1506# 1507# Sgx EPC cmdline information 1508# 1509# @memdev: memory backend linked with device 1510# 1511# @node: the numa node (Since: 7.0) 1512# 1513# Since: 6.2 1514## 1515{ 'struct': 'SgxEPC', 1516 'data': { 'memdev': 'str', 1517 'node': 'int' 1518 } 1519} 1520 1521## 1522# @SgxEPCProperties: 1523# 1524# SGX properties of machine types. 1525# 1526# @sgx-epc: list of ids of memory-backend-epc objects. 1527# 1528# Since: 6.2 1529## 1530{ 'struct': 'SgxEPCProperties', 1531 'data': { 'sgx-epc': ['SgxEPC'] } 1532} 1533 1534## 1535# @query-memory-devices: 1536# 1537# Lists available memory devices and their state 1538# 1539# Since: 2.1 1540# 1541# .. qmp-example:: 1542# 1543# -> { "execute": "query-memory-devices" } 1544# <- { "return": [ { "data": 1545# { "addr": 5368709120, 1546# "hotpluggable": true, 1547# "hotplugged": true, 1548# "id": "d1", 1549# "memdev": "/objects/memX", 1550# "node": 0, 1551# "size": 1073741824, 1552# "slot": 0}, 1553# "type": "dimm" 1554# } ] } 1555## 1556{ 'command': 'query-memory-devices', 'returns': ['MemoryDeviceInfo'] } 1557 1558## 1559# @MEMORY_DEVICE_SIZE_CHANGE: 1560# 1561# Emitted when the size of a memory device changes. Only emitted for 1562# memory devices that can actually change the size (e.g., virtio-mem 1563# due to guest action). 1564# 1565# @id: device's ID 1566# 1567# @size: the new size of memory that the device provides 1568# 1569# @qom-path: path to the device object in the QOM tree (since 6.2) 1570# 1571# .. note:: This event is rate-limited. 1572# 1573# Since: 5.1 1574# 1575# .. qmp-example:: 1576# 1577# <- { "event": "MEMORY_DEVICE_SIZE_CHANGE", 1578# "data": { "id": "vm0", "size": 1073741824, 1579# "qom-path": "/machine/unattached/device[2]" }, 1580# "timestamp": { "seconds": 1588168529, "microseconds": 201316 } } 1581## 1582{ 'event': 'MEMORY_DEVICE_SIZE_CHANGE', 1583 'data': { '*id': 'str', 'size': 'size', 'qom-path' : 'str'} } 1584 1585## 1586# @BootConfiguration: 1587# 1588# Schema for virtual machine boot configuration. 1589# 1590# @order: Boot order (a=floppy, c=hard disk, d=CD-ROM, n=network) 1591# 1592# @once: Boot order to apply on first boot 1593# 1594# @menu: Whether to show a boot menu 1595# 1596# @splash: The name of the file to be passed to the firmware as logo 1597# picture, if @menu is true. 1598# 1599# @splash-time: How long to show the logo picture, in milliseconds 1600# 1601# @reboot-timeout: Timeout before guest reboots after boot fails 1602# 1603# @strict: Whether to attempt booting from devices not included in the 1604# boot order 1605# 1606# Since: 7.1 1607## 1608{ 'struct': 'BootConfiguration', 'data': { 1609 '*order': 'str', 1610 '*once': 'str', 1611 '*menu': 'bool', 1612 '*splash': 'str', 1613 '*splash-time': 'int', 1614 '*reboot-timeout': 'int', 1615 '*strict': 'bool' } } 1616 1617## 1618# @SMPConfiguration: 1619# 1620# Schema for CPU topology configuration. A missing value lets QEMU 1621# figure out a suitable value based on the ones that are provided. 1622# 1623# The members other than @cpus and @maxcpus define a topology of 1624# containers. 1625# 1626# The ordering from highest/coarsest to lowest/finest is: @drawers, 1627# @books, @sockets, @dies, @clusters, @cores, @threads. 1628# 1629# Different architectures support different subsets of topology 1630# containers. 1631# 1632# For example, s390x does not have clusters and dies, and the socket 1633# is the parent container of cores. 1634# 1635# @cpus: number of virtual CPUs in the virtual machine 1636# 1637# @maxcpus: maximum number of hotpluggable virtual CPUs in the virtual 1638# machine 1639# 1640# @drawers: number of drawers in the CPU topology (since 8.2) 1641# 1642# @books: number of books in the CPU topology (since 8.2) 1643# 1644# @sockets: number of sockets per parent container 1645# 1646# @dies: number of dies per parent container 1647# 1648# @clusters: number of clusters per parent container (since 7.0) 1649# 1650# @modules: number of modules per parent container (since 9.1) 1651# 1652# @cores: number of cores per parent container 1653# 1654# @threads: number of threads per core 1655# 1656# Since: 6.1 1657## 1658{ 'struct': 'SMPConfiguration', 'data': { 1659 '*cpus': 'int', 1660 '*drawers': 'int', 1661 '*books': 'int', 1662 '*sockets': 'int', 1663 '*dies': 'int', 1664 '*clusters': 'int', 1665 '*modules': 'int', 1666 '*cores': 'int', 1667 '*threads': 'int', 1668 '*maxcpus': 'int' } } 1669 1670## 1671# @x-query-irq: 1672# 1673# Query interrupt statistics 1674# 1675# Features: 1676# 1677# @unstable: This command is meant for debugging. 1678# 1679# Returns: interrupt statistics 1680# 1681# Since: 6.2 1682## 1683{ 'command': 'x-query-irq', 1684 'returns': 'HumanReadableText', 1685 'features': [ 'unstable' ] } 1686 1687## 1688# @x-query-jit: 1689# 1690# Query TCG compiler statistics 1691# 1692# Features: 1693# 1694# @unstable: This command is meant for debugging. 1695# 1696# Returns: TCG compiler statistics 1697# 1698# Since: 6.2 1699## 1700{ 'command': 'x-query-jit', 1701 'returns': 'HumanReadableText', 1702 'if': 'CONFIG_TCG', 1703 'features': [ 'unstable' ] } 1704 1705## 1706# @x-query-numa: 1707# 1708# Query NUMA topology information 1709# 1710# Features: 1711# 1712# @unstable: This command is meant for debugging. 1713# 1714# Returns: topology information 1715# 1716# Since: 6.2 1717## 1718{ 'command': 'x-query-numa', 1719 'returns': 'HumanReadableText', 1720 'features': [ 'unstable' ] } 1721 1722## 1723# @x-query-ramblock: 1724# 1725# Query system ramblock information 1726# 1727# Features: 1728# 1729# @unstable: This command is meant for debugging. 1730# 1731# Returns: system ramblock information 1732# 1733# Since: 6.2 1734## 1735{ 'command': 'x-query-ramblock', 1736 'returns': 'HumanReadableText', 1737 'features': [ 'unstable' ] } 1738 1739## 1740# @x-query-roms: 1741# 1742# Query information on the registered ROMS 1743# 1744# Features: 1745# 1746# @unstable: This command is meant for debugging. 1747# 1748# Returns: registered ROMs 1749# 1750# Since: 6.2 1751## 1752{ 'command': 'x-query-roms', 1753 'returns': 'HumanReadableText', 1754 'features': [ 'unstable' ] } 1755 1756## 1757# @x-query-usb: 1758# 1759# Query information on the USB devices 1760# 1761# Features: 1762# 1763# @unstable: This command is meant for debugging. 1764# 1765# Returns: USB device information 1766# 1767# Since: 6.2 1768## 1769{ 'command': 'x-query-usb', 1770 'returns': 'HumanReadableText', 1771 'features': [ 'unstable' ] } 1772 1773## 1774# @SmbiosEntryPointType: 1775# 1776# @32: SMBIOS version 2.1 (32-bit) Entry Point 1777# 1778# @64: SMBIOS version 3.0 (64-bit) Entry Point 1779# 1780# @auto: Either 2.x or 3.x SMBIOS version, 2.x if configuration can be 1781# described by it and 3.x otherwise (since: 9.0) 1782# 1783# Since: 7.0 1784## 1785{ 'enum': 'SmbiosEntryPointType', 1786 'data': [ '32', '64', 'auto' ] } 1787 1788## 1789# @MemorySizeConfiguration: 1790# 1791# Schema for memory size configuration. 1792# 1793# @size: memory size in bytes 1794# 1795# @max-size: maximum hotpluggable memory size in bytes 1796# 1797# @slots: number of available memory slots for hotplug 1798# 1799# Since: 7.1 1800## 1801{ 'struct': 'MemorySizeConfiguration', 'data': { 1802 '*size': 'size', 1803 '*max-size': 'size', 1804 '*slots': 'uint64' } } 1805 1806## 1807# @dumpdtb: 1808# 1809# Save the FDT in dtb format. 1810# 1811# @filename: name of the dtb file to be created 1812# 1813# Since: 7.2 1814# 1815# .. qmp-example:: 1816# 1817# -> { "execute": "dumpdtb" } 1818# "arguments": { "filename": "fdt.dtb" } } 1819# <- { "return": {} } 1820## 1821{ 'command': 'dumpdtb', 1822 'data': { 'filename': 'str' }, 1823 'if': 'CONFIG_FDT' } 1824 1825## 1826# @x-query-interrupt-controllers: 1827# 1828# Query information on interrupt controller devices 1829# 1830# Features: 1831# 1832# @unstable: This command is meant for debugging. 1833# 1834# Returns: Interrupt controller devices information 1835# 1836# Since: 9.1 1837## 1838{ 'command': 'x-query-interrupt-controllers', 1839 'returns': 'HumanReadableText', 1840 'features': [ 'unstable' ]} 1841 1842## 1843# @dump-skeys: 1844# 1845# Dump the storage keys for an s390x guest 1846# 1847# @filename: the path to the file to dump to 1848# 1849# Since: 2.5 1850# 1851# .. qmp-example:: 1852# 1853# -> { "execute": "dump-skeys", 1854# "arguments": { "filename": "/tmp/skeys" } } 1855# <- { "return": {} } 1856## 1857{ 'command': 'dump-skeys', 1858 'data': { 'filename': 'str' } } 1859 1860## 1861# @CpuModelInfo: 1862# 1863# Virtual CPU model. 1864# 1865# A CPU model consists of the name of a CPU definition, to which delta 1866# changes are applied (e.g. features added/removed). Most magic 1867# values that an architecture might require should be hidden behind 1868# the name. However, if required, architectures can expose relevant 1869# properties. 1870# 1871# @name: the name of the CPU definition the model is based on 1872# 1873# @props: a dictionary of QOM properties to be applied 1874# 1875# Since: 2.8 1876## 1877{ 'struct': 'CpuModelInfo', 1878 'data': { 'name': 'str', 1879 '*props': 'any' } } 1880 1881## 1882# @CpuModelExpansionType: 1883# 1884# An enumeration of CPU model expansion types. 1885# 1886# @static: Expand to a static CPU model, a combination of a static 1887# base model name and property delta changes. As the static base 1888# model will never change, the expanded CPU model will be the 1889# same, independent of QEMU version, machine type, machine 1890# options, and accelerator options. Therefore, the resulting 1891# model can be used by tooling without having to specify a 1892# compatibility machine - e.g. when displaying the "host" model. 1893# The @static CPU models are migration-safe. 1894# 1895# @full: Expand all properties. The produced model is not guaranteed 1896# to be migration-safe, but allows tooling to get an insight and 1897# work with model details. 1898# 1899# .. note:: When a non-migration-safe CPU model is expanded in static 1900# mode, some features enabled by the CPU model may be omitted, 1901# because they can't be implemented by a static CPU model 1902# definition (e.g. cache info passthrough and PMU passthrough in 1903# x86). If you need an accurate representation of the features 1904# enabled by a non-migration-safe CPU model, use @full. If you 1905# need a static representation that will keep ABI compatibility 1906# even when changing QEMU version or machine-type, use @static (but 1907# keep in mind that some features may be omitted). 1908# 1909# Since: 2.8 1910## 1911{ 'enum': 'CpuModelExpansionType', 1912 'data': [ 'static', 'full' ] } 1913 1914## 1915# @CpuModelCompareResult: 1916# 1917# An enumeration of CPU model comparison results. The result is 1918# usually calculated using e.g. CPU features or CPU generations. 1919# 1920# @incompatible: If model A is incompatible to model B, model A is not 1921# guaranteed to run where model B runs and the other way around. 1922# 1923# @identical: If model A is identical to model B, model A is 1924# guaranteed to run where model B runs and the other way around. 1925# 1926# @superset: If model A is a superset of model B, model B is 1927# guaranteed to run where model A runs. There are no guarantees 1928# about the other way. 1929# 1930# @subset: If model A is a subset of model B, model A is guaranteed to 1931# run where model B runs. There are no guarantees about the other 1932# way. 1933# 1934# Since: 2.8 1935## 1936{ 'enum': 'CpuModelCompareResult', 1937 'data': [ 'incompatible', 'identical', 'superset', 'subset' ] } 1938 1939## 1940# @CpuModelBaselineInfo: 1941# 1942# The result of a CPU model baseline. 1943# 1944# @model: the baselined `CpuModelInfo`. 1945# 1946# Since: 2.8 1947## 1948{ 'struct': 'CpuModelBaselineInfo', 1949 'data': { 'model': 'CpuModelInfo' } } 1950 1951## 1952# @CpuModelCompareInfo: 1953# 1954# The result of a CPU model comparison. 1955# 1956# @result: The result of the compare operation. 1957# 1958# @responsible-properties: List of properties that led to the 1959# comparison result not being identical. 1960# 1961# @responsible-properties is a list of QOM property names that led to 1962# both CPUs not being detected as identical. For identical models, 1963# this list is empty. If a QOM property is read-only, that means 1964# there's no known way to make the CPU models identical. If the 1965# special property name "type" is included, the models are by 1966# definition not identical and cannot be made identical. 1967# 1968# Since: 2.8 1969## 1970{ 'struct': 'CpuModelCompareInfo', 1971 'data': { 'result': 'CpuModelCompareResult', 1972 'responsible-properties': ['str'] } } 1973 1974## 1975# @query-cpu-model-comparison: 1976# 1977# Compares two CPU models, @modela and @modelb, returning how they 1978# compare in a specific configuration. The results indicates how 1979# both models compare regarding runnability. This result can be 1980# used by tooling to make decisions if a certain CPU model will 1981# run in a certain configuration or if a compatible CPU model has 1982# to be created by baselining. 1983# 1984# Usually, a CPU model is compared against the maximum possible CPU 1985# model of a certain configuration (e.g. the "host" model for KVM). 1986# If that CPU model is identical or a subset, it will run in that 1987# configuration. 1988# 1989# The result returned by this command may be affected by: 1990# 1991# * QEMU version: CPU models may look different depending on the QEMU 1992# version. (Except for CPU models reported as "static" in 1993# `query-cpu-definitions`.) 1994# * machine-type: CPU model may look different depending on the 1995# machine-type. (Except for CPU models reported as "static" in 1996# `query-cpu-definitions`.) 1997# * machine options (including accelerator): in some architectures, 1998# CPU models may look different depending on machine and accelerator 1999# options. (Except for CPU models reported as "static" in 2000# `query-cpu-definitions`.) 2001# * "-cpu" arguments and global properties: arguments to the -cpu 2002# option and global properties may affect expansion of CPU models. 2003# Using `query-cpu-model-expansion` while using these is not advised. 2004# 2005# Some architectures may not support comparing CPU models. s390x 2006# supports comparing CPU models. 2007# 2008# @modela: description of the first CPU model to compare, referred to 2009# as "model A" in `CpuModelCompareResult` 2010# 2011# @modelb: description of the second CPU model to compare, referred to 2012# as "model B" in `CpuModelCompareResult` 2013# 2014# Returns: a `CpuModelCompareInfo` describing how both CPU models 2015# compare 2016# 2017# Errors: 2018# - if comparing CPU models is not supported by the target 2019# - if a model cannot be used 2020# - if a model contains an unknown cpu definition name, unknown 2021# properties or properties with wrong types. 2022# 2023# Since: 2.8 2024## 2025{ 'command': 'query-cpu-model-comparison', 2026 'data': { 'modela': 'CpuModelInfo', 'modelb': 'CpuModelInfo' }, 2027 'returns': 'CpuModelCompareInfo' } 2028 2029## 2030# @query-cpu-model-baseline: 2031# 2032# Baseline two CPU models, @modela and @modelb, creating a compatible 2033# third model. The created model will always be a static, 2034# migration-safe CPU model (see "static" CPU model expansion for 2035# details). 2036# 2037# This interface can be used by tooling to create a compatible CPU 2038# model out two CPU models. The created CPU model will be identical 2039# to or a subset of both CPU models when comparing them. Therefore, 2040# the created CPU model is guaranteed to run where the given CPU 2041# models run. 2042# 2043# The result returned by this command may be affected by: 2044# 2045# * QEMU version: CPU models may look different depending on the QEMU 2046# version. (Except for CPU models reported as "static" in 2047# `query-cpu-definitions`.) 2048# * machine-type: CPU model may look different depending on the 2049# machine-type. (Except for CPU models reported as "static" in 2050# `query-cpu-definitions`.) 2051# * machine options (including accelerator): in some architectures, 2052# CPU models may look different depending on machine and accelerator 2053# options. (Except for CPU models reported as "static" in 2054# `query-cpu-definitions`.) 2055# * "-cpu" arguments and global properties: arguments to the -cpu 2056# option and global properties may affect expansion of CPU models. 2057# Using `query-cpu-model-expansion` while using these is not advised. 2058# 2059# Some architectures may not support baselining CPU models. s390x 2060# supports baselining CPU models. 2061# 2062# @modela: description of the first CPU model to baseline 2063# 2064# @modelb: description of the second CPU model to baseline 2065# 2066# Returns: a `CpuModelBaselineInfo` describing the baselined CPU model 2067# 2068# Errors: 2069# - if baselining CPU models is not supported by the target 2070# - if a model cannot be used 2071# - if a model contains an unknown cpu definition name, unknown 2072# properties or properties with wrong types. 2073# 2074# Since: 2.8 2075## 2076{ 'command': 'query-cpu-model-baseline', 2077 'data': { 'modela': 'CpuModelInfo', 2078 'modelb': 'CpuModelInfo' }, 2079 'returns': 'CpuModelBaselineInfo' } 2080 2081## 2082# @CpuModelExpansionInfo: 2083# 2084# The result of a cpu model expansion. 2085# 2086# @model: the expanded `CpuModelInfo`. 2087# 2088# @deprecated-props: an optional list of properties that are flagged as 2089# deprecated by the CPU vendor. The list depends on the 2090# CpuModelExpansionType: "static" properties are a subset of the 2091# enabled-properties for the expanded model; "full" properties are 2092# a set of properties that are deprecated across all models for 2093# the architecture. (since: 10.1 -- since 9.1 on s390x --). 2094# 2095# Since: 2.8 2096## 2097{ 'struct': 'CpuModelExpansionInfo', 2098 'data': { 'model': 'CpuModelInfo', 2099 '*deprecated-props' : ['str'] } } 2100 2101## 2102# @query-cpu-model-expansion: 2103# 2104# Expands a given CPU model, @model, (or a combination of CPU model + 2105# additional options) to different granularities, specified by @type, 2106# allowing tooling to get an understanding what a specific CPU model 2107# looks like in QEMU under a certain configuration. 2108# 2109# This interface can be used to query the "host" CPU model. 2110# 2111# The data returned by this command may be affected by: 2112# 2113# * QEMU version: CPU models may look different depending on the QEMU 2114# version. (Except for CPU models reported as "static" in 2115# `query-cpu-definitions`.) 2116# * machine-type: CPU model may look different depending on the 2117# machine-type. (Except for CPU models reported as "static" in 2118# `query-cpu-definitions`.) 2119# * machine options (including accelerator): in some architectures, 2120# CPU models may look different depending on machine and accelerator 2121# options. (Except for CPU models reported as "static" in 2122# `query-cpu-definitions`.) 2123# * "-cpu" arguments and global properties: arguments to the -cpu 2124# option and global properties may affect expansion of CPU models. 2125# Using `query-cpu-model-expansion` while using these is not advised. 2126# 2127# Some architectures may not support all expansion types. s390x 2128# supports "full" and "static". Arm only supports "full". 2129# 2130# @model: description of the CPU model to expand 2131# 2132# @type: expansion type, specifying how to expand the CPU model 2133# 2134# Returns: a `CpuModelExpansionInfo` describing the expanded CPU model 2135# 2136# Errors: 2137# - if expanding CPU models is not supported 2138# - if the model cannot be expanded 2139# - if the model contains an unknown CPU definition name, unknown 2140# properties or properties with a wrong type 2141# - if an expansion type is not supported 2142# 2143# Since: 2.8 2144## 2145{ 'command': 'query-cpu-model-expansion', 2146 'data': { 'type': 'CpuModelExpansionType', 2147 'model': 'CpuModelInfo' }, 2148 'returns': 'CpuModelExpansionInfo' } 2149 2150## 2151# @CpuDefinitionInfo: 2152# 2153# Virtual CPU definition. 2154# 2155# @name: the name of the CPU definition 2156# 2157# @migration-safe: whether a CPU definition can be safely used for 2158# migration in combination with a QEMU compatibility machine when 2159# migrating between different QEMU versions and between hosts with 2160# different sets of (hardware or software) capabilities. If not 2161# provided, information is not available and callers should not 2162# assume the CPU definition to be migration-safe. (since 2.8) 2163# 2164# @static: whether a CPU definition is static and will not change 2165# depending on QEMU version, machine type, machine options and 2166# accelerator options. A static model is always migration-safe. 2167# (since 2.8) 2168# 2169# @unavailable-features: List of properties that prevent the CPU model 2170# from running in the current host. (since 2.8) 2171# 2172# @typename: Type name that can be used as argument to 2173# `device-list-properties`, to introspect properties configurable 2174# using -cpu or -global. (since 2.9) 2175# 2176# @alias-of: Name of CPU model this model is an alias for. The target 2177# of the CPU model alias may change depending on the machine type. 2178# Management software is supposed to translate CPU model aliases 2179# in the VM configuration, because aliases may stop being 2180# migration-safe in the future (since 4.1) 2181# 2182# @deprecated: If true, this CPU model is deprecated and may be 2183# removed in some future version of QEMU according to the QEMU 2184# deprecation policy. (since 5.2) 2185# 2186# @unavailable-features is a list of QOM property names that represent 2187# CPU model attributes that prevent the CPU from running. If the QOM 2188# property is read-only, that means there's no known way to make the 2189# CPU model run in the current host. Implementations that choose not 2190# to provide specific information return the property name "type". If 2191# the property is read-write, it means that it MAY be possible to run 2192# the CPU model in the current host if that property is changed. 2193# Management software can use it as hints to suggest or choose an 2194# alternative for the user, or just to generate meaningful error 2195# messages explaining why the CPU model can't be used. If 2196# @unavailable-features is an empty list, the CPU model is runnable 2197# using the current host and machine-type. If @unavailable-features 2198# is not present, runnability information for the CPU is not 2199# available. 2200# 2201# Since: 1.2 2202## 2203{ 'struct': 'CpuDefinitionInfo', 2204 'data': { 'name': 'str', 2205 '*migration-safe': 'bool', 2206 'static': 'bool', 2207 '*unavailable-features': [ 'str' ], 2208 'typename': 'str', 2209 '*alias-of' : 'str', 2210 'deprecated' : 'bool' } } 2211 2212## 2213# @query-cpu-definitions: 2214# 2215# Return a list of supported virtual CPU definitions 2216# 2217# Since: 1.2 2218## 2219{ 'command': 'query-cpu-definitions', 'returns': ['CpuDefinitionInfo'] } 2220