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## 12# @SysEmuTarget: 13# 14# The comprehensive enumeration of QEMU system emulation ("softmmu") 15# targets. Run "./configure --help" in the project root directory, and 16# look for the *-softmmu targets near the "--target-list" option. The 17# individual target constants are not documented here, for the time 18# being. 19# 20# @rx: since 5.0 21# @avr: since 5.1 22# 23# Notes: The resulting QMP strings can be appended to the "qemu-system-" 24# prefix to produce the corresponding QEMU executable name. This 25# is true even for "qemu-system-x86_64". 26# 27# Since: 3.0 28## 29{ 'enum' : 'SysEmuTarget', 30 'data' : [ 'aarch64', 'alpha', 'arm', 'avr', 'cris', 'hppa', 'i386', 'lm32', 31 'm68k', 'microblaze', 'microblazeel', 'mips', 'mips64', 32 'mips64el', 'mipsel', 'moxie', 'nios2', 'or1k', 'ppc', 33 'ppc64', 'riscv32', 'riscv64', 'rx', 's390x', 'sh4', 34 'sh4eb', 'sparc', 'sparc64', 'tricore', 'unicore32', 35 'x86_64', 'xtensa', 'xtensaeb' ] } 36 37## 38# @CpuInfoArch: 39# 40# An enumeration of cpu types that enable additional information during 41# @query-cpus and @query-cpus-fast. 42# 43# @s390: since 2.12 44# 45# @riscv: since 2.12 46# 47# Since: 2.6 48## 49{ 'enum': 'CpuInfoArch', 50 'data': ['x86', 'sparc', 'ppc', 'mips', 'tricore', 's390', 'riscv', 'other' ] } 51 52## 53# @CpuInfo: 54# 55# Information about a virtual CPU 56# 57# @CPU: the index of the virtual CPU 58# 59# @current: this only exists for backwards compatibility and should be ignored 60# 61# @halted: true if the virtual CPU is in the halt state. Halt usually refers 62# to a processor specific low power mode. 63# 64# @qom_path: path to the CPU object in the QOM tree (since 2.4) 65# 66# @thread_id: ID of the underlying host thread 67# 68# @props: properties describing to which node/socket/core/thread 69# virtual CPU belongs to, provided if supported by board (since 2.10) 70# 71# @arch: architecture of the cpu, which determines which additional fields 72# will be listed (since 2.6) 73# 74# Since: 0.14.0 75# 76# Notes: @halted is a transient state that changes frequently. By the time the 77# data is sent to the client, the guest may no longer be halted. 78## 79{ 'union': 'CpuInfo', 80 'base': {'CPU': 'int', 'current': 'bool', 'halted': 'bool', 81 'qom_path': 'str', 'thread_id': 'int', 82 '*props': 'CpuInstanceProperties', 'arch': 'CpuInfoArch' }, 83 'discriminator': 'arch', 84 'data': { 'x86': 'CpuInfoX86', 85 'sparc': 'CpuInfoSPARC', 86 'ppc': 'CpuInfoPPC', 87 'mips': 'CpuInfoMIPS', 88 'tricore': 'CpuInfoTricore', 89 's390': 'CpuInfoS390', 90 'riscv': 'CpuInfoRISCV' } } 91 92## 93# @CpuInfoX86: 94# 95# Additional information about a virtual i386 or x86_64 CPU 96# 97# @pc: the 64-bit instruction pointer 98# 99# Since: 2.6 100## 101{ 'struct': 'CpuInfoX86', 'data': { 'pc': 'int' } } 102 103## 104# @CpuInfoSPARC: 105# 106# Additional information about a virtual SPARC CPU 107# 108# @pc: the PC component of the instruction pointer 109# 110# @npc: the NPC component of the instruction pointer 111# 112# Since: 2.6 113## 114{ 'struct': 'CpuInfoSPARC', 'data': { 'pc': 'int', 'npc': 'int' } } 115 116## 117# @CpuInfoPPC: 118# 119# Additional information about a virtual PPC CPU 120# 121# @nip: the instruction pointer 122# 123# Since: 2.6 124## 125{ 'struct': 'CpuInfoPPC', 'data': { 'nip': 'int' } } 126 127## 128# @CpuInfoMIPS: 129# 130# Additional information about a virtual MIPS CPU 131# 132# @PC: the instruction pointer 133# 134# Since: 2.6 135## 136{ 'struct': 'CpuInfoMIPS', 'data': { 'PC': 'int' } } 137 138## 139# @CpuInfoTricore: 140# 141# Additional information about a virtual Tricore CPU 142# 143# @PC: the instruction pointer 144# 145# Since: 2.6 146## 147{ 'struct': 'CpuInfoTricore', 'data': { 'PC': 'int' } } 148 149## 150# @CpuInfoRISCV: 151# 152# Additional information about a virtual RISCV CPU 153# 154# @pc: the instruction pointer 155# 156# Since 2.12 157## 158{ 'struct': 'CpuInfoRISCV', 'data': { 'pc': 'int' } } 159 160## 161# @CpuS390State: 162# 163# An enumeration of cpu states that can be assumed by a virtual 164# S390 CPU 165# 166# Since: 2.12 167## 168{ 'enum': 'CpuS390State', 169 'prefix': 'S390_CPU_STATE', 170 'data': [ 'uninitialized', 'stopped', 'check-stop', 'operating', 'load' ] } 171 172## 173# @CpuInfoS390: 174# 175# Additional information about a virtual S390 CPU 176# 177# @cpu-state: the virtual CPU's state 178# 179# Since: 2.12 180## 181{ 'struct': 'CpuInfoS390', 'data': { 'cpu-state': 'CpuS390State' } } 182 183## 184# @query-cpus: 185# 186# Returns a list of information about each virtual CPU. 187# 188# This command causes vCPU threads to exit to userspace, which causes 189# a small interruption to guest CPU execution. This will have a negative 190# impact on realtime guests and other latency sensitive guest workloads. 191# 192# Features: 193# @deprecated: This command is deprecated, because it interferes with 194# the guest. Use 'query-cpus-fast' instead to avoid the vCPU 195# interruption. 196# 197# Returns: a list of @CpuInfo for each virtual CPU 198# 199# Since: 0.14.0 200# 201# Example: 202# 203# -> { "execute": "query-cpus" } 204# <- { "return": [ 205# { 206# "CPU":0, 207# "current":true, 208# "halted":false, 209# "qom_path":"/machine/unattached/device[0]", 210# "arch":"x86", 211# "pc":3227107138, 212# "thread_id":3134 213# }, 214# { 215# "CPU":1, 216# "current":false, 217# "halted":true, 218# "qom_path":"/machine/unattached/device[2]", 219# "arch":"x86", 220# "pc":7108165, 221# "thread_id":3135 222# } 223# ] 224# } 225# 226## 227{ 'command': 'query-cpus', 'returns': ['CpuInfo'], 228 'features': [ 'deprecated' ] } 229 230## 231# @CpuInfoFast: 232# 233# Information about a virtual CPU 234# 235# @cpu-index: index of the virtual CPU 236# 237# @qom-path: path to the CPU object in the QOM tree 238# 239# @thread-id: ID of the underlying host thread 240# 241# @props: properties describing to which node/socket/core/thread 242# virtual CPU belongs to, provided if supported by board 243# 244# @arch: base architecture of the cpu 245# 246# @target: the QEMU system emulation target, which determines which 247# additional fields will be listed (since 3.0) 248# 249# Features: 250# @deprecated: Member @arch is deprecated. Use @target instead. 251# 252# Since: 2.12 253# 254## 255{ 'union' : 'CpuInfoFast', 256 'base' : { 'cpu-index' : 'int', 257 'qom-path' : 'str', 258 'thread-id' : 'int', 259 '*props' : 'CpuInstanceProperties', 260 'arch' : { 'type': 'CpuInfoArch', 261 'features': [ 'deprecated' ] }, 262 'target' : 'SysEmuTarget' }, 263 'discriminator' : 'target', 264 'data' : { 's390x' : 'CpuInfoS390' } } 265 266## 267# @query-cpus-fast: 268# 269# Returns information about all virtual CPUs. This command does not 270# incur a performance penalty and should be used in production 271# instead of query-cpus. 272# 273# Returns: list of @CpuInfoFast 274# 275# Since: 2.12 276# 277# Example: 278# 279# -> { "execute": "query-cpus-fast" } 280# <- { "return": [ 281# { 282# "thread-id": 25627, 283# "props": { 284# "core-id": 0, 285# "thread-id": 0, 286# "socket-id": 0 287# }, 288# "qom-path": "/machine/unattached/device[0]", 289# "arch":"x86", 290# "target":"x86_64", 291# "cpu-index": 0 292# }, 293# { 294# "thread-id": 25628, 295# "props": { 296# "core-id": 0, 297# "thread-id": 0, 298# "socket-id": 1 299# }, 300# "qom-path": "/machine/unattached/device[2]", 301# "arch":"x86", 302# "target":"x86_64", 303# "cpu-index": 1 304# } 305# ] 306# } 307## 308{ 'command': 'query-cpus-fast', 'returns': [ 'CpuInfoFast' ] } 309 310## 311# @MachineInfo: 312# 313# Information describing a machine. 314# 315# @name: the name of the machine 316# 317# @alias: an alias for the machine name 318# 319# @is-default: whether the machine is default 320# 321# @cpu-max: maximum number of CPUs supported by the machine type 322# (since 1.5.0) 323# 324# @hotpluggable-cpus: cpu hotplug via -device is supported (since 2.7.0) 325# 326# @numa-mem-supported: true if '-numa node,mem' option is supported by 327# the machine type and false otherwise (since 4.1) 328# 329# @deprecated: if true, the machine type is deprecated and may be removed 330# in future versions of QEMU according to the QEMU deprecation 331# policy (since 4.1.0) 332# 333# @default-cpu-type: default CPU model typename if none is requested via 334# the -cpu argument. (since 4.2) 335# 336# @default-ram-id: the default ID of initial RAM memory backend (since 5.2) 337# 338# Since: 1.2.0 339## 340{ 'struct': 'MachineInfo', 341 'data': { 'name': 'str', '*alias': 'str', 342 '*is-default': 'bool', 'cpu-max': 'int', 343 'hotpluggable-cpus': 'bool', 'numa-mem-supported': 'bool', 344 'deprecated': 'bool', '*default-cpu-type': 'str', 345 '*default-ram-id': 'str' } } 346 347## 348# @query-machines: 349# 350# Return a list of supported machines 351# 352# Returns: a list of MachineInfo 353# 354# Since: 1.2.0 355## 356{ 'command': 'query-machines', 'returns': ['MachineInfo'] } 357 358## 359# @CurrentMachineParams: 360# 361# Information describing the running machine parameters. 362# 363# @wakeup-suspend-support: true if the machine supports wake up from 364# suspend 365# 366# Since: 4.0 367## 368{ 'struct': 'CurrentMachineParams', 369 'data': { 'wakeup-suspend-support': 'bool'} } 370 371## 372# @query-current-machine: 373# 374# Return information on the current virtual machine. 375# 376# Returns: CurrentMachineParams 377# 378# Since: 4.0 379## 380{ 'command': 'query-current-machine', 'returns': 'CurrentMachineParams' } 381 382## 383# @TargetInfo: 384# 385# Information describing the QEMU target. 386# 387# @arch: the target architecture 388# 389# Since: 1.2.0 390## 391{ 'struct': 'TargetInfo', 392 'data': { 'arch': 'SysEmuTarget' } } 393 394## 395# @query-target: 396# 397# Return information about the target for this QEMU 398# 399# Returns: TargetInfo 400# 401# Since: 1.2.0 402## 403{ 'command': 'query-target', 'returns': 'TargetInfo' } 404 405## 406# @GuidInfo: 407# 408# GUID information. 409# 410# @guid: the globally unique identifier 411# 412# Since: 2.9 413## 414{ 'struct': 'GuidInfo', 'data': {'guid': 'str'} } 415 416## 417# @query-vm-generation-id: 418# 419# Show Virtual Machine Generation ID 420# 421# Since: 2.9 422## 423{ 'command': 'query-vm-generation-id', 'returns': 'GuidInfo' } 424 425## 426# @LostTickPolicy: 427# 428# Policy for handling lost ticks in timer devices. Ticks end up getting 429# lost when, for example, the guest is paused. 430# 431# @discard: throw away the missed ticks and continue with future injection 432# normally. The guest OS will see the timer jump ahead by a 433# potentially quite significant amount all at once, as if the 434# intervening chunk of time had simply not existed; needless to 435# say, such a sudden jump can easily confuse a guest OS which is 436# not specifically prepared to deal with it. Assuming the guest 437# OS can deal correctly with the time jump, the time in the guest 438# and in the host should now match. 439# 440# @delay: continue to deliver ticks at the normal rate. The guest OS will 441# not notice anything is amiss, as from its point of view time will 442# have continued to flow normally. The time in the guest should now 443# be behind the time in the host by exactly the amount of time during 444# which ticks have been missed. 445# 446# @slew: deliver ticks at a higher rate to catch up with the missed ticks. 447# The guest OS will not notice anything is amiss, as from its point 448# of view time will have continued to flow normally. Once the timer 449# has managed to catch up with all the missing ticks, the time in 450# the guest and in the host should match. 451# 452# Since: 2.0 453## 454{ 'enum': 'LostTickPolicy', 455 'data': ['discard', 'delay', 'slew' ] } 456 457## 458# @NumaOptionsType: 459# 460# @node: NUMA nodes configuration 461# 462# @dist: NUMA distance configuration (since 2.10) 463# 464# @cpu: property based CPU(s) to node mapping (Since: 2.10) 465# 466# @hmat-lb: memory latency and bandwidth information (Since: 5.0) 467# 468# @hmat-cache: memory side cache information (Since: 5.0) 469# 470# Since: 2.1 471## 472{ 'enum': 'NumaOptionsType', 473 'data': [ 'node', 'dist', 'cpu', 'hmat-lb', 'hmat-cache' ] } 474 475## 476# @NumaOptions: 477# 478# A discriminated record of NUMA options. (for OptsVisitor) 479# 480# Since: 2.1 481## 482{ 'union': 'NumaOptions', 483 'base': { 'type': 'NumaOptionsType' }, 484 'discriminator': 'type', 485 'data': { 486 'node': 'NumaNodeOptions', 487 'dist': 'NumaDistOptions', 488 'cpu': 'NumaCpuOptions', 489 'hmat-lb': 'NumaHmatLBOptions', 490 'hmat-cache': 'NumaHmatCacheOptions' }} 491 492## 493# @NumaNodeOptions: 494# 495# Create a guest NUMA node. (for OptsVisitor) 496# 497# @nodeid: NUMA node ID (increase by 1 from 0 if omitted) 498# 499# @cpus: VCPUs belonging to this node (assign VCPUS round-robin 500# if omitted) 501# 502# @mem: memory size of this node; mutually exclusive with @memdev. 503# Equally divide total memory among nodes if both @mem and @memdev are 504# omitted. 505# 506# @memdev: memory backend object. If specified for one node, 507# it must be specified for all nodes. 508# 509# @initiator: defined in ACPI 6.3 Chapter 5.2.27.3 Table 5-145, 510# points to the nodeid which has the memory controller 511# responsible for this NUMA node. This field provides 512# additional information as to the initiator node that 513# is closest (as in directly attached) to this node, and 514# therefore has the best performance (since 5.0) 515# 516# Since: 2.1 517## 518{ 'struct': 'NumaNodeOptions', 519 'data': { 520 '*nodeid': 'uint16', 521 '*cpus': ['uint16'], 522 '*mem': 'size', 523 '*memdev': 'str', 524 '*initiator': 'uint16' }} 525 526## 527# @NumaDistOptions: 528# 529# Set the distance between 2 NUMA nodes. 530# 531# @src: source NUMA node. 532# 533# @dst: destination NUMA node. 534# 535# @val: NUMA distance from source node to destination node. 536# When a node is unreachable from another node, set the distance 537# between them to 255. 538# 539# Since: 2.10 540## 541{ 'struct': 'NumaDistOptions', 542 'data': { 543 'src': 'uint16', 544 'dst': 'uint16', 545 'val': 'uint8' }} 546 547## 548# @X86CPURegister32: 549# 550# A X86 32-bit register 551# 552# Since: 1.5 553## 554{ 'enum': 'X86CPURegister32', 555 'data': [ 'EAX', 'EBX', 'ECX', 'EDX', 'ESP', 'EBP', 'ESI', 'EDI' ] } 556 557## 558# @X86CPUFeatureWordInfo: 559# 560# Information about a X86 CPU feature word 561# 562# @cpuid-input-eax: Input EAX value for CPUID instruction for that feature word 563# 564# @cpuid-input-ecx: Input ECX value for CPUID instruction for that 565# feature word 566# 567# @cpuid-register: Output register containing the feature bits 568# 569# @features: value of output register, containing the feature bits 570# 571# Since: 1.5 572## 573{ 'struct': 'X86CPUFeatureWordInfo', 574 'data': { 'cpuid-input-eax': 'int', 575 '*cpuid-input-ecx': 'int', 576 'cpuid-register': 'X86CPURegister32', 577 'features': 'int' } } 578 579## 580# @DummyForceArrays: 581# 582# Not used by QMP; hack to let us use X86CPUFeatureWordInfoList internally 583# 584# Since: 2.5 585## 586{ 'struct': 'DummyForceArrays', 587 'data': { 'unused': ['X86CPUFeatureWordInfo'] } } 588 589## 590# @NumaCpuOptions: 591# 592# Option "-numa cpu" overrides default cpu to node mapping. 593# It accepts the same set of cpu properties as returned by 594# query-hotpluggable-cpus[].props, where node-id could be used to 595# override default node mapping. 596# 597# Since: 2.10 598## 599{ 'struct': 'NumaCpuOptions', 600 'base': 'CpuInstanceProperties', 601 'data' : {} } 602 603## 604# @HmatLBMemoryHierarchy: 605# 606# The memory hierarchy in the System Locality Latency and Bandwidth 607# Information Structure of HMAT (Heterogeneous Memory Attribute Table) 608# 609# For more information about @HmatLBMemoryHierarchy, see chapter 610# 5.2.27.4: Table 5-146: Field "Flags" of ACPI 6.3 spec. 611# 612# @memory: the structure represents the memory performance 613# 614# @first-level: first level of memory side cache 615# 616# @second-level: second level of memory side cache 617# 618# @third-level: third level of memory side cache 619# 620# Since: 5.0 621## 622{ 'enum': 'HmatLBMemoryHierarchy', 623 'data': [ 'memory', 'first-level', 'second-level', 'third-level' ] } 624 625## 626# @HmatLBDataType: 627# 628# Data type in the System Locality Latency and Bandwidth 629# Information Structure of HMAT (Heterogeneous Memory Attribute Table) 630# 631# For more information about @HmatLBDataType, see chapter 632# 5.2.27.4: Table 5-146: Field "Data Type" of ACPI 6.3 spec. 633# 634# @access-latency: access latency (nanoseconds) 635# 636# @read-latency: read latency (nanoseconds) 637# 638# @write-latency: write latency (nanoseconds) 639# 640# @access-bandwidth: access bandwidth (Bytes per second) 641# 642# @read-bandwidth: read bandwidth (Bytes per second) 643# 644# @write-bandwidth: write bandwidth (Bytes per second) 645# 646# Since: 5.0 647## 648{ 'enum': 'HmatLBDataType', 649 'data': [ 'access-latency', 'read-latency', 'write-latency', 650 'access-bandwidth', 'read-bandwidth', 'write-bandwidth' ] } 651 652## 653# @NumaHmatLBOptions: 654# 655# Set the system locality latency and bandwidth information 656# between Initiator and Target proximity Domains. 657# 658# For more information about @NumaHmatLBOptions, see chapter 659# 5.2.27.4: Table 5-146 of ACPI 6.3 spec. 660# 661# @initiator: the Initiator Proximity Domain. 662# 663# @target: the Target Proximity Domain. 664# 665# @hierarchy: the Memory Hierarchy. Indicates the performance 666# of memory or side cache. 667# 668# @data-type: presents the type of data, access/read/write 669# latency or hit latency. 670# 671# @latency: the value of latency from @initiator to @target 672# proximity domain, the latency unit is "ns(nanosecond)". 673# 674# @bandwidth: the value of bandwidth between @initiator and @target 675# proximity domain, the bandwidth unit is 676# "Bytes per second". 677# 678# Since: 5.0 679## 680{ 'struct': 'NumaHmatLBOptions', 681 'data': { 682 'initiator': 'uint16', 683 'target': 'uint16', 684 'hierarchy': 'HmatLBMemoryHierarchy', 685 'data-type': 'HmatLBDataType', 686 '*latency': 'uint64', 687 '*bandwidth': 'size' }} 688 689## 690# @HmatCacheAssociativity: 691# 692# Cache associativity in the Memory Side Cache Information Structure 693# of HMAT 694# 695# For more information of @HmatCacheAssociativity, see chapter 696# 5.2.27.5: Table 5-147 of ACPI 6.3 spec. 697# 698# @none: None (no memory side cache in this proximity domain, 699# or cache associativity unknown) 700# 701# @direct: Direct Mapped 702# 703# @complex: Complex Cache Indexing (implementation specific) 704# 705# Since: 5.0 706## 707{ 'enum': 'HmatCacheAssociativity', 708 'data': [ 'none', 'direct', 'complex' ] } 709 710## 711# @HmatCacheWritePolicy: 712# 713# Cache write policy in the Memory Side Cache Information Structure 714# of HMAT 715# 716# For more information of @HmatCacheWritePolicy, see chapter 717# 5.2.27.5: Table 5-147: Field "Cache Attributes" of ACPI 6.3 spec. 718# 719# @none: None (no memory side cache in this proximity domain, 720# or cache write policy unknown) 721# 722# @write-back: Write Back (WB) 723# 724# @write-through: Write Through (WT) 725# 726# Since: 5.0 727## 728{ 'enum': 'HmatCacheWritePolicy', 729 'data': [ 'none', 'write-back', 'write-through' ] } 730 731## 732# @NumaHmatCacheOptions: 733# 734# Set the memory side cache information for a given memory domain. 735# 736# For more information of @NumaHmatCacheOptions, see chapter 737# 5.2.27.5: Table 5-147: Field "Cache Attributes" of ACPI 6.3 spec. 738# 739# @node-id: the memory proximity domain to which the memory belongs. 740# 741# @size: the size of memory side cache in bytes. 742# 743# @level: the cache level described in this structure. 744# 745# @associativity: the cache associativity, 746# none/direct-mapped/complex(complex cache indexing). 747# 748# @policy: the write policy, none/write-back/write-through. 749# 750# @line: the cache Line size in bytes. 751# 752# Since: 5.0 753## 754{ 'struct': 'NumaHmatCacheOptions', 755 'data': { 756 'node-id': 'uint32', 757 'size': 'size', 758 'level': 'uint8', 759 'associativity': 'HmatCacheAssociativity', 760 'policy': 'HmatCacheWritePolicy', 761 'line': 'uint16' }} 762 763## 764# @HostMemPolicy: 765# 766# Host memory policy types 767# 768# @default: restore default policy, remove any nondefault policy 769# 770# @preferred: set the preferred host nodes for allocation 771# 772# @bind: a strict policy that restricts memory allocation to the 773# host nodes specified 774# 775# @interleave: memory allocations are interleaved across the set 776# of host nodes specified 777# 778# Since: 2.1 779## 780{ 'enum': 'HostMemPolicy', 781 'data': [ 'default', 'preferred', 'bind', 'interleave' ] } 782 783## 784# @Memdev: 785# 786# Information about memory backend 787# 788# @id: backend's ID if backend has 'id' property (since 2.9) 789# 790# @size: memory backend size 791# 792# @merge: enables or disables memory merge support 793# 794# @dump: includes memory backend's memory in a core dump or not 795# 796# @prealloc: enables or disables memory preallocation 797# 798# @host-nodes: host nodes for its memory policy 799# 800# @policy: memory policy of memory backend 801# 802# Since: 2.1 803## 804{ 'struct': 'Memdev', 805 'data': { 806 '*id': 'str', 807 'size': 'size', 808 'merge': 'bool', 809 'dump': 'bool', 810 'prealloc': 'bool', 811 'host-nodes': ['uint16'], 812 'policy': 'HostMemPolicy' }} 813 814## 815# @query-memdev: 816# 817# Returns information for all memory backends. 818# 819# Returns: a list of @Memdev. 820# 821# Since: 2.1 822# 823# Example: 824# 825# -> { "execute": "query-memdev" } 826# <- { "return": [ 827# { 828# "id": "mem1", 829# "size": 536870912, 830# "merge": false, 831# "dump": true, 832# "prealloc": false, 833# "host-nodes": [0, 1], 834# "policy": "bind" 835# }, 836# { 837# "size": 536870912, 838# "merge": false, 839# "dump": true, 840# "prealloc": true, 841# "host-nodes": [2, 3], 842# "policy": "preferred" 843# } 844# ] 845# } 846# 847## 848{ 'command': 'query-memdev', 'returns': ['Memdev'], 'allow-preconfig': true } 849 850## 851# @CpuInstanceProperties: 852# 853# List of properties to be used for hotplugging a CPU instance, 854# it should be passed by management with device_add command when 855# a CPU is being hotplugged. 856# 857# @node-id: NUMA node ID the CPU belongs to 858# @socket-id: socket number within node/board the CPU belongs to 859# @die-id: die number within node/board the CPU belongs to (Since 4.1) 860# @core-id: core number within die the CPU belongs to 861# @thread-id: thread number within core the CPU belongs to 862# 863# Note: currently there are 5 properties that could be present 864# but management should be prepared to pass through other 865# properties with device_add command to allow for future 866# interface extension. This also requires the filed names to be kept in 867# sync with the properties passed to -device/device_add. 868# 869# Since: 2.7 870## 871{ 'struct': 'CpuInstanceProperties', 872 'data': { '*node-id': 'int', 873 '*socket-id': 'int', 874 '*die-id': 'int', 875 '*core-id': 'int', 876 '*thread-id': 'int' 877 } 878} 879 880## 881# @HotpluggableCPU: 882# 883# @type: CPU object type for usage with device_add command 884# @props: list of properties to be used for hotplugging CPU 885# @vcpus-count: number of logical VCPU threads @HotpluggableCPU provides 886# @qom-path: link to existing CPU object if CPU is present or 887# omitted if CPU is not present. 888# 889# Since: 2.7 890## 891{ 'struct': 'HotpluggableCPU', 892 'data': { 'type': 'str', 893 'vcpus-count': 'int', 894 'props': 'CpuInstanceProperties', 895 '*qom-path': 'str' 896 } 897} 898 899## 900# @query-hotpluggable-cpus: 901# 902# TODO: Better documentation; currently there is none. 903# 904# Returns: a list of HotpluggableCPU objects. 905# 906# Since: 2.7 907# 908# Example: 909# 910# For pseries machine type started with -smp 2,cores=2,maxcpus=4 -cpu POWER8: 911# 912# -> { "execute": "query-hotpluggable-cpus" } 913# <- {"return": [ 914# { "props": { "core": 8 }, "type": "POWER8-spapr-cpu-core", 915# "vcpus-count": 1 }, 916# { "props": { "core": 0 }, "type": "POWER8-spapr-cpu-core", 917# "vcpus-count": 1, "qom-path": "/machine/unattached/device[0]"} 918# ]}' 919# 920# For pc machine type started with -smp 1,maxcpus=2: 921# 922# -> { "execute": "query-hotpluggable-cpus" } 923# <- {"return": [ 924# { 925# "type": "qemu64-x86_64-cpu", "vcpus-count": 1, 926# "props": {"core-id": 0, "socket-id": 1, "thread-id": 0} 927# }, 928# { 929# "qom-path": "/machine/unattached/device[0]", 930# "type": "qemu64-x86_64-cpu", "vcpus-count": 1, 931# "props": {"core-id": 0, "socket-id": 0, "thread-id": 0} 932# } 933# ]} 934# 935# For s390x-virtio-ccw machine type started with -smp 1,maxcpus=2 -cpu qemu 936# (Since: 2.11): 937# 938# -> { "execute": "query-hotpluggable-cpus" } 939# <- {"return": [ 940# { 941# "type": "qemu-s390x-cpu", "vcpus-count": 1, 942# "props": { "core-id": 1 } 943# }, 944# { 945# "qom-path": "/machine/unattached/device[0]", 946# "type": "qemu-s390x-cpu", "vcpus-count": 1, 947# "props": { "core-id": 0 } 948# } 949# ]} 950# 951## 952{ 'command': 'query-hotpluggable-cpus', 'returns': ['HotpluggableCPU'], 953 'allow-preconfig': true } 954 955## 956# @set-numa-node: 957# 958# Runtime equivalent of '-numa' CLI option, available at 959# preconfigure stage to configure numa mapping before initializing 960# machine. 961# 962# Since 3.0 963## 964{ 'command': 'set-numa-node', 'boxed': true, 965 'data': 'NumaOptions', 966 'allow-preconfig': true 967} 968 969## 970# @balloon: 971# 972# Request the balloon driver to change its balloon size. 973# 974# @value: the target logical size of the VM in bytes 975# We can deduce the size of the balloon using this formula: 976# logical_vm_size = vm_ram_size - balloon_size 977# From it we have: balloon_size = vm_ram_size - @value 978# 979# Returns: - Nothing on success 980# - If the balloon driver is enabled but not functional because the KVM 981# kernel module cannot support it, KvmMissingCap 982# - If no balloon device is present, DeviceNotActive 983# 984# Notes: This command just issues a request to the guest. When it returns, 985# the balloon size may not have changed. A guest can change the balloon 986# size independent of this command. 987# 988# Since: 0.14.0 989# 990# Example: 991# 992# -> { "execute": "balloon", "arguments": { "value": 536870912 } } 993# <- { "return": {} } 994# 995# With a 2.5GiB guest this command inflated the ballon to 3GiB. 996# 997## 998{ 'command': 'balloon', 'data': {'value': 'int'} } 999 1000## 1001# @BalloonInfo: 1002# 1003# Information about the guest balloon device. 1004# 1005# @actual: the logical size of the VM in bytes 1006# Formula used: logical_vm_size = vm_ram_size - balloon_size 1007# 1008# Since: 0.14.0 1009# 1010## 1011{ 'struct': 'BalloonInfo', 'data': {'actual': 'int' } } 1012 1013## 1014# @query-balloon: 1015# 1016# Return information about the balloon device. 1017# 1018# Returns: - @BalloonInfo on success 1019# - If the balloon driver is enabled but not functional because the KVM 1020# kernel module cannot support it, KvmMissingCap 1021# - If no balloon device is present, DeviceNotActive 1022# 1023# Since: 0.14.0 1024# 1025# Example: 1026# 1027# -> { "execute": "query-balloon" } 1028# <- { "return": { 1029# "actual": 1073741824, 1030# } 1031# } 1032# 1033## 1034{ 'command': 'query-balloon', 'returns': 'BalloonInfo' } 1035 1036## 1037# @BALLOON_CHANGE: 1038# 1039# Emitted when the guest changes the actual BALLOON level. This value is 1040# equivalent to the @actual field return by the 'query-balloon' command 1041# 1042# @actual: the logical size of the VM in bytes 1043# Formula used: logical_vm_size = vm_ram_size - balloon_size 1044# 1045# Note: this event is rate-limited. 1046# 1047# Since: 1.2 1048# 1049# Example: 1050# 1051# <- { "event": "BALLOON_CHANGE", 1052# "data": { "actual": 944766976 }, 1053# "timestamp": { "seconds": 1267020223, "microseconds": 435656 } } 1054# 1055## 1056{ 'event': 'BALLOON_CHANGE', 1057 'data': { 'actual': 'int' } } 1058