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