qemu/qapi/machine.json

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

1735 lines
40 KiB
JSON
Raw Normal View History

# -*- Mode: Python -*-
# vim: filetype=python
#
# This work is licensed under the terms of the GNU GPL, version 2 or later.
# See the COPYING file in the top-level directory.
##
# = Machines
##
{ 'include': 'common.json' }
{ 'include': 'machine-common.json' }
##
# @SysEmuTarget:
#
# The comprehensive enumeration of QEMU system emulation ("softmmu")
# targets. Run "./configure --help" in the project root directory,
# and look for the \*-softmmu targets near the "--target-list" option.
# The individual target constants are not documented here, for the
# time being.
#
# @rx: since 5.0
#
# @avr: since 5.1
#
# Notes: The resulting QMP strings can be appended to the
# "qemu-system-" prefix to produce the corresponding QEMU
# executable name. This is true even for "qemu-system-x86_64".
#
# Since: 3.0
##
{ 'enum' : 'SysEmuTarget',
'data' : [ 'aarch64', 'alpha', 'arm', 'avr', 'cris', 'hppa', 'i386',
'loongarch64', 'm68k', 'microblaze', 'microblazeel', 'mips', 'mips64',
'mips64el', 'mipsel', 'nios2', 'or1k', 'ppc',
'ppc64', 'riscv32', 'riscv64', 'rx', 's390x', 'sh4',
'sh4eb', 'sparc', 'sparc64', 'tricore',
'x86_64', 'xtensa', 'xtensaeb' ] }
##
# @CpuS390State:
#
# An enumeration of cpu states that can be assumed by a virtual S390
# CPU
#
# Since: 2.12
##
{ 'enum': 'CpuS390State',
'prefix': 'S390_CPU_STATE',
'data': [ 'uninitialized', 'stopped', 'check-stop', 'operating', 'load' ] }
##
# @CpuInfoS390:
#
# Additional information about a virtual S390 CPU
#
# @cpu-state: the virtual CPU's state
#
# @dedicated: the virtual CPU's dedication (since 8.2)
#
# @entitlement: the virtual CPU's entitlement (since 8.2)
#
# Since: 2.12
##
{ 'struct': 'CpuInfoS390',
'data': { 'cpu-state': 'CpuS390State',
'*dedicated': 'bool',
'*entitlement': 'CpuS390Entitlement' } }
##
# @CpuInfoFast:
#
# Information about a virtual CPU
#
# @cpu-index: index of the virtual CPU
#
# @qom-path: path to the CPU object in the QOM tree
#
# @thread-id: ID of the underlying host thread
#
# @props: properties associated with a virtual CPU, e.g. the socket id
#
# @target: the QEMU system emulation target, which determines which
# additional fields will be listed (since 3.0)
#
# Since: 2.12
##
{ 'union' : 'CpuInfoFast',
'base' : { 'cpu-index' : 'int',
'qom-path' : 'str',
'thread-id' : 'int',
'*props' : 'CpuInstanceProperties',
'target' : 'SysEmuTarget' },
'discriminator' : 'target',
'data' : { 's390x' : 'CpuInfoS390' } }
##
# @query-cpus-fast:
#
# Returns information about all virtual CPUs.
#
# Returns: list of @CpuInfoFast
#
# Since: 2.12
#
# Example:
#
# -> { "execute": "query-cpus-fast" }
# <- { "return": [
# {
# "thread-id": 25627,
# "props": {
# "core-id": 0,
# "thread-id": 0,
# "socket-id": 0
# },
# "qom-path": "/machine/unattached/device[0]",
# "target":"x86_64",
# "cpu-index": 0
# },
# {
# "thread-id": 25628,
# "props": {
# "core-id": 0,
# "thread-id": 0,
# "socket-id": 1
# },
# "qom-path": "/machine/unattached/device[2]",
# "target":"x86_64",
# "cpu-index": 1
# }
# ]
# }
##
{ 'command': 'query-cpus-fast', 'returns': [ 'CpuInfoFast' ] }
##
# @MachineInfo:
#
# Information describing a machine.
#
# @name: the name of the machine
#
# @alias: an alias for the machine name
#
# @is-default: whether the machine is default
#
# @cpu-max: maximum number of CPUs supported by the machine type
# (since 1.5)
#
# @hotpluggable-cpus: cpu hotplug via -device is supported (since 2.7)
#
# @numa-mem-supported: true if '-numa node,mem' option is supported by
# the machine type and false otherwise (since 4.1)
#
# @deprecated: if true, the machine type is deprecated and may be
# removed in future versions of QEMU according to the QEMU
# deprecation policy (since 4.1)
#
# @default-cpu-type: default CPU model typename if none is requested
# via the -cpu argument. (since 4.2)
#
# @default-ram-id: the default ID of initial RAM memory backend (since
# 5.2)
#
# @acpi: machine type supports ACPI (since 8.0)
#
# Since: 1.2
##
{ 'struct': 'MachineInfo',
'data': { 'name': 'str', '*alias': 'str',
'*is-default': 'bool', 'cpu-max': 'int',
'hotpluggable-cpus': 'bool', 'numa-mem-supported': 'bool',
'deprecated': 'bool', '*default-cpu-type': 'str',
'*default-ram-id': 'str', 'acpi': 'bool' } }
##
# @query-machines:
#
# Return a list of supported machines
#
# Returns: a list of MachineInfo
#
# Since: 1.2
##
{ 'command': 'query-machines', 'returns': ['MachineInfo'] }
##
# @CurrentMachineParams:
#
# Information describing the running machine parameters.
#
# @wakeup-suspend-support: true if the machine supports wake up from
# suspend
#
# Since: 4.0
##
{ 'struct': 'CurrentMachineParams',
'data': { 'wakeup-suspend-support': 'bool'} }
##
# @query-current-machine:
#
# Return information on the current virtual machine.
#
# Returns: CurrentMachineParams
#
# Since: 4.0
##
{ 'command': 'query-current-machine', 'returns': 'CurrentMachineParams' }
##
# @TargetInfo:
#
# Information describing the QEMU target.
#
# @arch: the target architecture
#
# Since: 1.2
##
{ 'struct': 'TargetInfo',
'data': { 'arch': 'SysEmuTarget' } }
##
# @query-target:
#
# Return information about the target for this QEMU
#
# Returns: TargetInfo
#
# Since: 1.2
##
{ 'command': 'query-target', 'returns': 'TargetInfo' }
##
# @UuidInfo:
#
# Guest UUID information (Universally Unique Identifier).
#
# @UUID: the UUID of the guest
#
# Since: 0.14
#
# Notes: If no UUID was specified for the guest, a null UUID is
# returned.
##
{ 'struct': 'UuidInfo', 'data': {'UUID': 'str'} }
##
# @query-uuid:
#
# Query the guest UUID information.
#
# Returns: The @UuidInfo for the guest
#
# Since: 0.14
#
# Example:
#
# -> { "execute": "query-uuid" }
# <- { "return": { "UUID": "550e8400-e29b-41d4-a716-446655440000" } }
##
{ 'command': 'query-uuid', 'returns': 'UuidInfo', 'allow-preconfig': true }
##
# @GuidInfo:
#
# GUID information.
#
# @guid: the globally unique identifier
#
# Since: 2.9
##
{ 'struct': 'GuidInfo', 'data': {'guid': 'str'} }
##
# @query-vm-generation-id:
#
# Show Virtual Machine Generation ID
#
# Since: 2.9
##
{ 'command': 'query-vm-generation-id', 'returns': 'GuidInfo' }
##
# @system_reset:
#
# Performs a hard reset of a guest.
#
# Since: 0.14
#
# Example:
#
# -> { "execute": "system_reset" }
# <- { "return": {} }
##
{ 'command': 'system_reset' }
##
# @system_powerdown:
#
# Requests that a guest perform a powerdown operation.
#
# Since: 0.14
#
# Notes: A guest may or may not respond to this command. This command
# returning does not indicate that a guest has accepted the
# request or that it has shut down. Many guests will respond to
# this command by prompting the user in some way.
#
# Example:
#
# -> { "execute": "system_powerdown" }
# <- { "return": {} }
##
{ 'command': 'system_powerdown' }
##
# @system_wakeup:
#
# Wake up guest from suspend. If the guest has wake-up from suspend
# support enabled (wakeup-suspend-support flag from
# query-current-machine), wake-up guest from suspend if the guest is
# in SUSPENDED state. Return an error otherwise.
#
# Since: 1.1
#
# Returns: nothing.
#
# Note: prior to 4.0, this command does nothing in case the guest
# isn't suspended.
#
# Example:
#
# -> { "execute": "system_wakeup" }
# <- { "return": {} }
##
{ 'command': 'system_wakeup' }
##
# @LostTickPolicy:
#
# Policy for handling lost ticks in timer devices. Ticks end up
# getting lost when, for example, the guest is paused.
#
# @discard: throw away the missed ticks and continue with future
# injection normally. The guest OS will see the timer jump ahead
# by a potentially quite significant amount all at once, as if the
# intervening chunk of time had simply not existed; needless to
# say, such a sudden jump can easily confuse a guest OS which is
# not specifically prepared to deal with it. Assuming the guest
# OS can deal correctly with the time jump, the time in the guest
# and in the host should now match.
#
# @delay: continue to deliver ticks at the normal rate. The guest OS
# will not notice anything is amiss, as from its point of view
# time will have continued to flow normally. The time in the
# guest should now be behind the time in the host by exactly the
# amount of time during which ticks have been missed.
#
# @slew: deliver ticks at a higher rate to catch up with the missed
# ticks. The guest OS will not notice anything is amiss, as from
# its point of view time will have continued to flow normally.
# Once the timer has managed to catch up with all the missing
# ticks, the time in the guest and in the host should match.
#
# Since: 2.0
##
{ 'enum': 'LostTickPolicy',
'data': ['discard', 'delay', 'slew' ] }
##
# @inject-nmi:
#
# Injects a Non-Maskable Interrupt into the default CPU (x86/s390) or
# all CPUs (ppc64). The command fails when the guest doesn't support
# injecting.
#
# Returns: If successful, nothing
#
# Since: 0.14
#
# Note: prior to 2.1, this command was only supported for x86 and s390
# VMs
#
# Example:
#
# -> { "execute": "inject-nmi" }
# <- { "return": {} }
##
{ 'command': 'inject-nmi' }
##
# @KvmInfo:
#
# Information about support for KVM acceleration
#
# @enabled: true if KVM acceleration is active
#
# @present: true if KVM acceleration is built into this executable
#
# Since: 0.14
##
{ 'struct': 'KvmInfo', 'data': {'enabled': 'bool', 'present': 'bool'} }
##
# @query-kvm:
#
# Returns information about KVM acceleration
#
# Returns: @KvmInfo
#
# Since: 0.14
#
# Example:
#
# -> { "execute": "query-kvm" }
# <- { "return": { "enabled": true, "present": true } }
##
{ 'command': 'query-kvm', 'returns': 'KvmInfo' }
##
# @NumaOptionsType:
#
# @node: NUMA nodes configuration
#
# @dist: NUMA distance configuration (since 2.10)
#
# @cpu: property based CPU(s) to node mapping (Since: 2.10)
#
# @hmat-lb: memory latency and bandwidth information (Since: 5.0)
#
# @hmat-cache: memory side cache information (Since: 5.0)
#
# Since: 2.1
##
{ 'enum': 'NumaOptionsType',
'data': [ 'node', 'dist', 'cpu', 'hmat-lb', 'hmat-cache' ] }
##
# @NumaOptions:
#
# A discriminated record of NUMA options. (for OptsVisitor)
#
# Since: 2.1
##
{ 'union': 'NumaOptions',
'base': { 'type': 'NumaOptionsType' },
'discriminator': 'type',
'data': {
'node': 'NumaNodeOptions',
'dist': 'NumaDistOptions',
'cpu': 'NumaCpuOptions',
'hmat-lb': 'NumaHmatLBOptions',
'hmat-cache': 'NumaHmatCacheOptions' }}
##
# @NumaNodeOptions:
#
# Create a guest NUMA node. (for OptsVisitor)
#
# @nodeid: NUMA node ID (increase by 1 from 0 if omitted)
#
# @cpus: VCPUs belonging to this node (assign VCPUS round-robin if
# omitted)
#
# @mem: memory size of this node; mutually exclusive with @memdev.
# Equally divide total memory among nodes if both @mem and @memdev
# are omitted.
#
# @memdev: memory backend object. If specified for one node, it must
# be specified for all nodes.
#
# @initiator: defined in ACPI 6.3 Chapter 5.2.27.3 Table 5-145, points
# to the nodeid which has the memory controller responsible for
# this NUMA node. This field provides additional information as
# to the initiator node that is closest (as in directly attached)
# to this node, and therefore has the best performance (since 5.0)
#
# Since: 2.1
##
{ 'struct': 'NumaNodeOptions',
'data': {
'*nodeid': 'uint16',
'*cpus': ['uint16'],
'*mem': 'size',
'*memdev': 'str',
'*initiator': 'uint16' }}
##
# @NumaDistOptions:
#
# Set the distance between 2 NUMA nodes.
#
# @src: source NUMA node.
#
# @dst: destination NUMA node.
#
# @val: NUMA distance from source node to destination node. When a
# node is unreachable from another node, set the distance between
# them to 255.
#
# Since: 2.10
##
{ 'struct': 'NumaDistOptions',
'data': {
'src': 'uint16',
'dst': 'uint16',
'val': 'uint8' }}
hw/cxl/host: Add support for CXL Fixed Memory Windows. The concept of these is introduced in [1] in terms of the description the CEDT ACPI table. The principal is more general. Unlike once traffic hits the CXL root bridges, the host system memory address routing is implementation defined and effectively static once observable by standard / generic system software. Each CXL Fixed Memory Windows (CFMW) is a region of PA space which has fixed system dependent routing configured so that accesses can be routed to the CXL devices below a set of target root bridges. The accesses may be interleaved across multiple root bridges. For QEMU we could have fully specified these regions in terms of a base PA + size, but as the absolute address does not matter it is simpler to let individual platforms place the memory regions. ExampleS: -cxl-fixed-memory-window targets.0=cxl.0,size=128G -cxl-fixed-memory-window targets.0=cxl.1,size=128G -cxl-fixed-memory-window targets.0=cxl0,targets.1=cxl.1,size=256G,interleave-granularity=2k Specifies * 2x 128G regions not interleaved across root bridges, one for each of the root bridges with ids cxl.0 and cxl.1 * 256G region interleaved across root bridges with ids cxl.0 and cxl.1 with a 2k interleave granularity. When system software enumerates the devices below a given root bridge it can then decide which CFMW to use. If non interleave is desired (or possible) it can use the appropriate CFMW for the root bridge in question. If there are suitable devices to interleave across the two root bridges then it may use the 3rd CFMS. A number of other designs were considered but the following constraints made it hard to adapt existing QEMU approaches to this particular problem. 1) The size must be known before a specific architecture / board brings up it's PA memory map. We need to set up an appropriate region. 2) Using links to the host bridges provides a clean command line interface but these links cannot be established until command line devices have been added. Hence the two step process used here of first establishing the size, interleave-ways and granularity + caching the ids of the host bridges and then, once available finding the actual host bridges so they can be used later to support interleave decoding. [1] CXL 2.0 ECN: CEDT CFMWS & QTG DSM (computeexpresslink.org / specifications) Signed-off-by: Jonathan Cameron <jonathan.cameron@huawei.com> Acked-by: Markus Armbruster <armbru@redhat.com> # QAPI Schema Message-Id: <20220429144110.25167-28-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-04-29 14:40:52 +00:00
##
# @CXLFixedMemoryWindowOptions:
#
# Create a CXL Fixed Memory Window
#
# @size: Size of the Fixed Memory Window in bytes. Must be a multiple
# of 256MiB.
#
hw/cxl/host: Add support for CXL Fixed Memory Windows. The concept of these is introduced in [1] in terms of the description the CEDT ACPI table. The principal is more general. Unlike once traffic hits the CXL root bridges, the host system memory address routing is implementation defined and effectively static once observable by standard / generic system software. Each CXL Fixed Memory Windows (CFMW) is a region of PA space which has fixed system dependent routing configured so that accesses can be routed to the CXL devices below a set of target root bridges. The accesses may be interleaved across multiple root bridges. For QEMU we could have fully specified these regions in terms of a base PA + size, but as the absolute address does not matter it is simpler to let individual platforms place the memory regions. ExampleS: -cxl-fixed-memory-window targets.0=cxl.0,size=128G -cxl-fixed-memory-window targets.0=cxl.1,size=128G -cxl-fixed-memory-window targets.0=cxl0,targets.1=cxl.1,size=256G,interleave-granularity=2k Specifies * 2x 128G regions not interleaved across root bridges, one for each of the root bridges with ids cxl.0 and cxl.1 * 256G region interleaved across root bridges with ids cxl.0 and cxl.1 with a 2k interleave granularity. When system software enumerates the devices below a given root bridge it can then decide which CFMW to use. If non interleave is desired (or possible) it can use the appropriate CFMW for the root bridge in question. If there are suitable devices to interleave across the two root bridges then it may use the 3rd CFMS. A number of other designs were considered but the following constraints made it hard to adapt existing QEMU approaches to this particular problem. 1) The size must be known before a specific architecture / board brings up it's PA memory map. We need to set up an appropriate region. 2) Using links to the host bridges provides a clean command line interface but these links cannot be established until command line devices have been added. Hence the two step process used here of first establishing the size, interleave-ways and granularity + caching the ids of the host bridges and then, once available finding the actual host bridges so they can be used later to support interleave decoding. [1] CXL 2.0 ECN: CEDT CFMWS & QTG DSM (computeexpresslink.org / specifications) Signed-off-by: Jonathan Cameron <jonathan.cameron@huawei.com> Acked-by: Markus Armbruster <armbru@redhat.com> # QAPI Schema Message-Id: <20220429144110.25167-28-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-04-29 14:40:52 +00:00
# @interleave-granularity: Number of contiguous bytes for which
# accesses will go to a given interleave target. Accepted values
# [256, 512, 1k, 2k, 4k, 8k, 16k]
#
# @targets: Target root bridge IDs from -device ...,id=<ID> for each
# root bridge.
hw/cxl/host: Add support for CXL Fixed Memory Windows. The concept of these is introduced in [1] in terms of the description the CEDT ACPI table. The principal is more general. Unlike once traffic hits the CXL root bridges, the host system memory address routing is implementation defined and effectively static once observable by standard / generic system software. Each CXL Fixed Memory Windows (CFMW) is a region of PA space which has fixed system dependent routing configured so that accesses can be routed to the CXL devices below a set of target root bridges. The accesses may be interleaved across multiple root bridges. For QEMU we could have fully specified these regions in terms of a base PA + size, but as the absolute address does not matter it is simpler to let individual platforms place the memory regions. ExampleS: -cxl-fixed-memory-window targets.0=cxl.0,size=128G -cxl-fixed-memory-window targets.0=cxl.1,size=128G -cxl-fixed-memory-window targets.0=cxl0,targets.1=cxl.1,size=256G,interleave-granularity=2k Specifies * 2x 128G regions not interleaved across root bridges, one for each of the root bridges with ids cxl.0 and cxl.1 * 256G region interleaved across root bridges with ids cxl.0 and cxl.1 with a 2k interleave granularity. When system software enumerates the devices below a given root bridge it can then decide which CFMW to use. If non interleave is desired (or possible) it can use the appropriate CFMW for the root bridge in question. If there are suitable devices to interleave across the two root bridges then it may use the 3rd CFMS. A number of other designs were considered but the following constraints made it hard to adapt existing QEMU approaches to this particular problem. 1) The size must be known before a specific architecture / board brings up it's PA memory map. We need to set up an appropriate region. 2) Using links to the host bridges provides a clean command line interface but these links cannot be established until command line devices have been added. Hence the two step process used here of first establishing the size, interleave-ways and granularity + caching the ids of the host bridges and then, once available finding the actual host bridges so they can be used later to support interleave decoding. [1] CXL 2.0 ECN: CEDT CFMWS & QTG DSM (computeexpresslink.org / specifications) Signed-off-by: Jonathan Cameron <jonathan.cameron@huawei.com> Acked-by: Markus Armbruster <armbru@redhat.com> # QAPI Schema Message-Id: <20220429144110.25167-28-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-04-29 14:40:52 +00:00
#
# Since: 7.1
hw/cxl/host: Add support for CXL Fixed Memory Windows. The concept of these is introduced in [1] in terms of the description the CEDT ACPI table. The principal is more general. Unlike once traffic hits the CXL root bridges, the host system memory address routing is implementation defined and effectively static once observable by standard / generic system software. Each CXL Fixed Memory Windows (CFMW) is a region of PA space which has fixed system dependent routing configured so that accesses can be routed to the CXL devices below a set of target root bridges. The accesses may be interleaved across multiple root bridges. For QEMU we could have fully specified these regions in terms of a base PA + size, but as the absolute address does not matter it is simpler to let individual platforms place the memory regions. ExampleS: -cxl-fixed-memory-window targets.0=cxl.0,size=128G -cxl-fixed-memory-window targets.0=cxl.1,size=128G -cxl-fixed-memory-window targets.0=cxl0,targets.1=cxl.1,size=256G,interleave-granularity=2k Specifies * 2x 128G regions not interleaved across root bridges, one for each of the root bridges with ids cxl.0 and cxl.1 * 256G region interleaved across root bridges with ids cxl.0 and cxl.1 with a 2k interleave granularity. When system software enumerates the devices below a given root bridge it can then decide which CFMW to use. If non interleave is desired (or possible) it can use the appropriate CFMW for the root bridge in question. If there are suitable devices to interleave across the two root bridges then it may use the 3rd CFMS. A number of other designs were considered but the following constraints made it hard to adapt existing QEMU approaches to this particular problem. 1) The size must be known before a specific architecture / board brings up it's PA memory map. We need to set up an appropriate region. 2) Using links to the host bridges provides a clean command line interface but these links cannot be established until command line devices have been added. Hence the two step process used here of first establishing the size, interleave-ways and granularity + caching the ids of the host bridges and then, once available finding the actual host bridges so they can be used later to support interleave decoding. [1] CXL 2.0 ECN: CEDT CFMWS & QTG DSM (computeexpresslink.org / specifications) Signed-off-by: Jonathan Cameron <jonathan.cameron@huawei.com> Acked-by: Markus Armbruster <armbru@redhat.com> # QAPI Schema Message-Id: <20220429144110.25167-28-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-04-29 14:40:52 +00:00
##
{ 'struct': 'CXLFixedMemoryWindowOptions',
'data': {
'size': 'size',
'*interleave-granularity': 'size',
'targets': ['str'] }}
##
# @CXLFMWProperties:
#
# List of CXL Fixed Memory Windows.
#
# @cxl-fmw: List of CXLFixedMemoryWindowOptions
#
# Since: 7.1
##
{ 'struct' : 'CXLFMWProperties',
'data': { 'cxl-fmw': ['CXLFixedMemoryWindowOptions'] }
}
##
# @X86CPURegister32:
#
# A X86 32-bit register
#
# Since: 1.5
##
{ 'enum': 'X86CPURegister32',
'data': [ 'EAX', 'EBX', 'ECX', 'EDX', 'ESP', 'EBP', 'ESI', 'EDI' ] }
##
# @X86CPUFeatureWordInfo:
#
# Information about a X86 CPU feature word
#
# @cpuid-input-eax: Input EAX value for CPUID instruction for that
# feature word
#
# @cpuid-input-ecx: Input ECX value for CPUID instruction for that
# feature word
#
# @cpuid-register: Output register containing the feature bits
#
# @features: value of output register, containing the feature bits
#
# Since: 1.5
##
{ 'struct': 'X86CPUFeatureWordInfo',
'data': { 'cpuid-input-eax': 'int',
'*cpuid-input-ecx': 'int',
'cpuid-register': 'X86CPURegister32',
'features': 'int' } }
##
# @DummyForceArrays:
#
# Not used by QMP; hack to let us use X86CPUFeatureWordInfoList
# internally
#
# Since: 2.5
##
{ 'struct': 'DummyForceArrays',
'data': { 'unused': ['X86CPUFeatureWordInfo'] } }
##
# @NumaCpuOptions:
#
# Option "-numa cpu" overrides default cpu to node mapping. It
# accepts the same set of cpu properties as returned by
# query-hotpluggable-cpus[].props, where node-id could be used to
# override default node mapping.
#
# Since: 2.10
##
{ 'struct': 'NumaCpuOptions',
'base': 'CpuInstanceProperties',
'data' : {} }
##
# @HmatLBMemoryHierarchy:
#
# The memory hierarchy in the System Locality Latency and Bandwidth
# Information Structure of HMAT (Heterogeneous Memory Attribute Table)
#
# For more information about @HmatLBMemoryHierarchy, see chapter
# 5.2.27.4: Table 5-146: Field "Flags" of ACPI 6.3 spec.
#
# @memory: the structure represents the memory performance
#
# @first-level: first level of memory side cache
#
# @second-level: second level of memory side cache
#
# @third-level: third level of memory side cache
#
# Since: 5.0
##
{ 'enum': 'HmatLBMemoryHierarchy',
'data': [ 'memory', 'first-level', 'second-level', 'third-level' ] }
##
# @HmatLBDataType:
#
# Data type in the System Locality Latency and Bandwidth Information
# Structure of HMAT (Heterogeneous Memory Attribute Table)
#
# For more information about @HmatLBDataType, see chapter 5.2.27.4:
# Table 5-146: Field "Data Type" of ACPI 6.3 spec.
#
# @access-latency: access latency (nanoseconds)
#
# @read-latency: read latency (nanoseconds)
#
# @write-latency: write latency (nanoseconds)
#
# @access-bandwidth: access bandwidth (Bytes per second)
#
# @read-bandwidth: read bandwidth (Bytes per second)
#
# @write-bandwidth: write bandwidth (Bytes per second)
#
# Since: 5.0
##
{ 'enum': 'HmatLBDataType',
'data': [ 'access-latency', 'read-latency', 'write-latency',
'access-bandwidth', 'read-bandwidth', 'write-bandwidth' ] }
##
# @NumaHmatLBOptions:
#
# Set the system locality latency and bandwidth information between
# Initiator and Target proximity Domains.
#
# For more information about @NumaHmatLBOptions, see chapter 5.2.27.4:
# Table 5-146 of ACPI 6.3 spec.
#
# @initiator: the Initiator Proximity Domain.
#
# @target: the Target Proximity Domain.
#
# @hierarchy: the Memory Hierarchy. Indicates the performance of
# memory or side cache.
#
# @data-type: presents the type of data, access/read/write latency or
# hit latency.
#
# @latency: the value of latency from @initiator to @target proximity
# domain, the latency unit is "ns(nanosecond)".
#
# @bandwidth: the value of bandwidth between @initiator and @target
# proximity domain, the bandwidth unit is "Bytes per second".
#
# Since: 5.0
##
{ 'struct': 'NumaHmatLBOptions',
'data': {
'initiator': 'uint16',
'target': 'uint16',
'hierarchy': 'HmatLBMemoryHierarchy',
'data-type': 'HmatLBDataType',
'*latency': 'uint64',
'*bandwidth': 'size' }}
##
# @HmatCacheAssociativity:
#
# Cache associativity in the Memory Side Cache Information Structure
# of HMAT
#
# For more information of @HmatCacheAssociativity, see chapter
# 5.2.27.5: Table 5-147 of ACPI 6.3 spec.
#
# @none: None (no memory side cache in this proximity domain, or cache
# associativity unknown)
#
# @direct: Direct Mapped
#
# @complex: Complex Cache Indexing (implementation specific)
#
# Since: 5.0
##
{ 'enum': 'HmatCacheAssociativity',
'data': [ 'none', 'direct', 'complex' ] }
##
# @HmatCacheWritePolicy:
#
# Cache write policy in the Memory Side Cache Information Structure of
# HMAT
#
# For more information of @HmatCacheWritePolicy, see chapter 5.2.27.5:
# Table 5-147: Field "Cache Attributes" of ACPI 6.3 spec.
#
# @none: None (no memory side cache in this proximity domain, or cache
# write policy unknown)
#
# @write-back: Write Back (WB)
#
# @write-through: Write Through (WT)
#
# Since: 5.0
##
{ 'enum': 'HmatCacheWritePolicy',
'data': [ 'none', 'write-back', 'write-through' ] }
##
# @NumaHmatCacheOptions:
#
# Set the memory side cache information for a given memory domain.
#
# For more information of @NumaHmatCacheOptions, see chapter 5.2.27.5:
# Table 5-147: Field "Cache Attributes" of ACPI 6.3 spec.
#
# @node-id: the memory proximity domain to which the memory belongs.
#
# @size: the size of memory side cache in bytes.
#
# @level: the cache level described in this structure.
#
# @associativity: the cache associativity,
# none/direct-mapped/complex(complex cache indexing).
#
# @policy: the write policy, none/write-back/write-through.
#
# @line: the cache Line size in bytes.
#
# Since: 5.0
##
{ 'struct': 'NumaHmatCacheOptions',
'data': {
'node-id': 'uint32',
'size': 'size',
'level': 'uint8',
'associativity': 'HmatCacheAssociativity',
'policy': 'HmatCacheWritePolicy',
'line': 'uint16' }}
##
# @memsave:
#
# Save a portion of guest memory to a file.
#
# @val: the virtual address of the guest to start from
#
# @size: the size of memory region to save
#
# @filename: the file to save the memory to as binary data
#
# @cpu-index: the index of the virtual CPU to use for translating the
# virtual address (defaults to CPU 0)
#
# Returns: Nothing on success
#
# Since: 0.14
#
# Notes: Errors were not reliably returned until 1.1
#
# Example:
#
# -> { "execute": "memsave",
# "arguments": { "val": 10,
# "size": 100,
# "filename": "/tmp/virtual-mem-dump" } }
# <- { "return": {} }
##
{ 'command': 'memsave',
'data': {'val': 'int', 'size': 'int', 'filename': 'str', '*cpu-index': 'int'} }
##
# @pmemsave:
#
# Save a portion of guest physical memory to a file.
#
# @val: the physical address of the guest to start from
#
# @size: the size of memory region to save
#
# @filename: the file to save the memory to as binary data
#
# Returns: Nothing on success
#
# Since: 0.14
#
# Notes: Errors were not reliably returned until 1.1
#
# Example:
#
# -> { "execute": "pmemsave",
# "arguments": { "val": 10,
# "size": 100,
# "filename": "/tmp/physical-mem-dump" } }
# <- { "return": {} }
##
{ 'command': 'pmemsave',
'data': {'val': 'int', 'size': 'int', 'filename': 'str'} }
##
# @Memdev:
#
# Information about memory backend
#
# @id: backend's ID if backend has 'id' property (since 2.9)
#
# @size: memory backend size
#
# @merge: whether memory merge support is enabled
#
# @dump: whether memory backend's memory is included in a core dump
#
# @prealloc: whether memory was preallocated
#
# @share: whether memory is private to QEMU or shared (since 6.1)
#
# @reserve: whether swap space (or huge pages) was reserved if
# applicable. This corresponds to the user configuration and not
# the actual behavior implemented in the OS to perform the
# reservation. For example, Linux will never reserve swap space
# for shared file mappings. (since 6.1)
#
# @host-nodes: host nodes for its memory policy
#
# @policy: memory policy of memory backend
#
# Since: 2.1
##
{ 'struct': 'Memdev',
'data': {
'*id': 'str',
'size': 'size',
'merge': 'bool',
'dump': 'bool',
'prealloc': 'bool',
'share': 'bool',
'*reserve': 'bool',
'host-nodes': ['uint16'],
'policy': 'HostMemPolicy' }}
##
# @query-memdev:
#
# Returns information for all memory backends.
#
# Returns: a list of @Memdev.
#
# Since: 2.1
#
# Example:
#
# -> { "execute": "query-memdev" }
# <- { "return": [
# {
# "id": "mem1",
# "size": 536870912,
# "merge": false,
# "dump": true,
# "prealloc": false,
# "share": false,
# "host-nodes": [0, 1],
# "policy": "bind"
# },
# {
# "size": 536870912,
# "merge": false,
# "dump": true,
# "prealloc": true,
# "share": false,
# "host-nodes": [2, 3],
# "policy": "preferred"
# }
# ]
# }
##
{ 'command': 'query-memdev', 'returns': ['Memdev'], 'allow-preconfig': true }
##
# @CpuInstanceProperties:
#
# List of properties to be used for hotplugging a CPU instance, it
# should be passed by management with device_add command when a CPU is
# being hotplugged.
#
# Which members are optional and which mandatory depends on the
# architecture and board.
#
# For s390x see :ref:`cpu-topology-s390x`.
#
# The ids other than the node-id specify the position of the CPU
# within the CPU topology (as defined by the machine property "smp",
# thus see also type @SMPConfiguration)
#
# @node-id: NUMA node ID the CPU belongs to
#
# @drawer-id: drawer number within CPU topology the CPU belongs to
# (since 8.2)
#
# @book-id: book number within parent container the CPU belongs to
# (since 8.2)
#
# @socket-id: socket number within parent container the CPU belongs to
#
# @die-id: die number within the parent container the CPU belongs to
# (since 4.1)
#
# @cluster-id: cluster number within the parent container the CPU
# belongs to (since 7.1)
#
# @core-id: core number within the parent container the CPU
# belongs to
#
# @thread-id: thread number within the core the CPU belongs to
#
# Note: management should be prepared to pass through additional
# properties with device_add.
#
# Since: 2.7
##
{ 'struct': 'CpuInstanceProperties',
# Keep these in sync with the properties device_add accepts
'data': { '*node-id': 'int',
'*drawer-id': 'int',
'*book-id': 'int',
'*socket-id': 'int',
'*die-id': 'int',
'*cluster-id': 'int',
'*core-id': 'int',
'*thread-id': 'int'
}
}
##
# @HotpluggableCPU:
#
# @type: CPU object type for usage with device_add command
#
# @props: list of properties to be used for hotplugging CPU
#
# @vcpus-count: number of logical VCPU threads @HotpluggableCPU
# provides
#
# @qom-path: link to existing CPU object if CPU is present or omitted
# if CPU is not present.
#
# Since: 2.7
##
{ 'struct': 'HotpluggableCPU',
'data': { 'type': 'str',
'vcpus-count': 'int',
'props': 'CpuInstanceProperties',
'*qom-path': 'str'
}
}
##
# @query-hotpluggable-cpus:
#
# TODO: Better documentation; currently there is none.
#
# Returns: a list of HotpluggableCPU objects.
#
# Since: 2.7
#
# Examples:
#
# For pseries machine type started with -smp 2,cores=2,maxcpus=4 -cpu
# POWER8:
#
# -> { "execute": "query-hotpluggable-cpus" }
# <- {"return": [
# { "props": { "core-id": 8 }, "type": "POWER8-spapr-cpu-core",
# "vcpus-count": 1 },
# { "props": { "core-id": 0 }, "type": "POWER8-spapr-cpu-core",
# "vcpus-count": 1, "qom-path": "/machine/unattached/device[0]"}
# ]}'
#
# For pc machine type started with -smp 1,maxcpus=2:
#
# -> { "execute": "query-hotpluggable-cpus" }
# <- {"return": [
# {
# "type": "qemu64-x86_64-cpu", "vcpus-count": 1,
# "props": {"core-id": 0, "socket-id": 1, "thread-id": 0}
# },
# {
# "qom-path": "/machine/unattached/device[0]",
# "type": "qemu64-x86_64-cpu", "vcpus-count": 1,
# "props": {"core-id": 0, "socket-id": 0, "thread-id": 0}
# }
# ]}
#
# For s390x-virtio-ccw machine type started with -smp 1,maxcpus=2 -cpu
# qemu (Since: 2.11):
#
# -> { "execute": "query-hotpluggable-cpus" }
# <- {"return": [
# {
# "type": "qemu-s390x-cpu", "vcpus-count": 1,
# "props": { "core-id": 1 }
# },
# {
# "qom-path": "/machine/unattached/device[0]",
# "type": "qemu-s390x-cpu", "vcpus-count": 1,
# "props": { "core-id": 0 }
# }
# ]}
##
{ 'command': 'query-hotpluggable-cpus', 'returns': ['HotpluggableCPU'],
'allow-preconfig': true }
##
# @set-numa-node:
#
# Runtime equivalent of '-numa' CLI option, available at preconfigure
# stage to configure numa mapping before initializing machine.
#
# Since: 3.0
##
{ 'command': 'set-numa-node', 'boxed': true,
'data': 'NumaOptions',
'allow-preconfig': true
}
##
# @balloon:
#
# Request the balloon driver to change its balloon size.
#
# @value: the target logical size of the VM in bytes. We can deduce
# the size of the balloon using this formula:
#
# logical_vm_size = vm_ram_size - balloon_size
#
# From it we have: balloon_size = vm_ram_size - @value
#
# Returns:
# - Nothing on success
# - If the balloon driver is enabled but not functional because the
# KVM kernel module cannot support it, KVMMissingCap
# - If no balloon device is present, DeviceNotActive
#
# Notes: This command just issues a request to the guest. When it
# returns, the balloon size may not have changed. A guest can
# change the balloon size independent of this command.
#
# Since: 0.14
#
# Example:
#
# -> { "execute": "balloon", "arguments": { "value": 536870912 } }
# <- { "return": {} }
#
# With a 2.5GiB guest this command inflated the ballon to 3GiB.
##
{ 'command': 'balloon', 'data': {'value': 'int'} }
##
# @BalloonInfo:
#
# Information about the guest balloon device.
#
# @actual: the logical size of the VM in bytes Formula used:
# logical_vm_size = vm_ram_size - balloon_size
#
# Since: 0.14
##
{ 'struct': 'BalloonInfo', 'data': {'actual': 'int' } }
##
# @query-balloon:
#
# Return information about the balloon device.
#
# Returns:
# - @BalloonInfo on success
# - If the balloon driver is enabled but not functional because the
# KVM kernel module cannot support it, KVMMissingCap
# - If no balloon device is present, DeviceNotActive
#
# Since: 0.14
#
# Example:
#
# -> { "execute": "query-balloon" }
# <- { "return": {
# "actual": 1073741824
# }
# }
##
{ 'command': 'query-balloon', 'returns': 'BalloonInfo' }
##
# @BALLOON_CHANGE:
#
# Emitted when the guest changes the actual BALLOON level. This value
# is equivalent to the @actual field return by the 'query-balloon'
# command
#
# @actual: the logical size of the VM in bytes Formula used:
# logical_vm_size = vm_ram_size - balloon_size
#
# Note: this event is rate-limited.
#
# Since: 1.2
#
# Example:
#
# <- { "event": "BALLOON_CHANGE",
# "data": { "actual": 944766976 },
# "timestamp": { "seconds": 1267020223, "microseconds": 435656 } }
##
{ 'event': 'BALLOON_CHANGE',
'data': { 'actual': 'int' } }
##
# @MemoryInfo:
#
# Actual memory information in bytes.
#
# @base-memory: size of "base" memory specified with command line
# option -m.
#
# @plugged-memory: size of memory that can be hot-unplugged. This
# field is omitted if target doesn't support memory hotplug (i.e.
# CONFIG_MEM_DEVICE not defined at build time).
#
# Since: 2.11
##
{ 'struct': 'MemoryInfo',
'data' : { 'base-memory': 'size', '*plugged-memory': 'size' } }
##
# @query-memory-size-summary:
#
# Return the amount of initially allocated and present hotpluggable
# (if enabled) memory in bytes.
#
# Example:
#
# -> { "execute": "query-memory-size-summary" }
# <- { "return": { "base-memory": 4294967296, "plugged-memory": 0 } }
#
# Since: 2.11
##
{ 'command': 'query-memory-size-summary', 'returns': 'MemoryInfo' }
##
# @PCDIMMDeviceInfo:
#
# PCDIMMDevice state information
#
# @id: device's ID
#
# @addr: physical address, where device is mapped
#
# @size: size of memory that the device provides
#
# @slot: slot number at which device is plugged in
#
# @node: NUMA node number where device is plugged in
#
# @memdev: memory backend linked with device
#
# @hotplugged: true if device was hotplugged
#
# @hotpluggable: true if device if could be added/removed while
# machine is running
#
# Since: 2.1
##
{ 'struct': 'PCDIMMDeviceInfo',
'data': { '*id': 'str',
'addr': 'int',
'size': 'int',
'slot': 'int',
'node': 'int',
'memdev': 'str',
'hotplugged': 'bool',
'hotpluggable': 'bool'
}
}
##
# @VirtioPMEMDeviceInfo:
#
# VirtioPMEM state information
#
# @id: device's ID
#
# @memaddr: physical address in memory, where device is mapped
#
# @size: size of memory that the device provides
#
# @memdev: memory backend linked with device
#
# Since: 4.1
##
{ 'struct': 'VirtioPMEMDeviceInfo',
'data': { '*id': 'str',
'memaddr': 'size',
'size': 'size',
'memdev': 'str'
}
}
##
# @VirtioMEMDeviceInfo:
#
# VirtioMEMDevice state information
#
# @id: device's ID
#
# @memaddr: physical address in memory, where device is mapped
#
# @requested-size: the user requested size of the device
#
# @size: the (current) size of memory that the device provides
#
# @max-size: the maximum size of memory that the device can provide
#
# @block-size: the block size of memory that the device provides
#
# @node: NUMA node number where device is assigned to
#
# @memdev: memory backend linked with the region
#
# Since: 5.1
##
{ 'struct': 'VirtioMEMDeviceInfo',
'data': { '*id': 'str',
'memaddr': 'size',
'requested-size': 'size',
'size': 'size',
'max-size': 'size',
'block-size': 'size',
'node': 'int',
'memdev': 'str'
}
}
##
# @SgxEPCDeviceInfo:
#
# Sgx EPC state information
#
# @id: device's ID
#
# @memaddr: physical address in memory, where device is mapped
#
# @size: size of memory that the device provides
#
# @memdev: memory backend linked with device
#
# @node: the numa node (Since: 7.0)
#
# Since: 6.2
##
{ 'struct': 'SgxEPCDeviceInfo',
'data': { '*id': 'str',
'memaddr': 'size',
'size': 'size',
'node': 'int',
'memdev': 'str'
}
}
##
# @MemoryDeviceInfoKind:
#
# @nvdimm: since 2.12
#
# @virtio-pmem: since 4.1
#
# @virtio-mem: since 5.1
#
# @sgx-epc: since 6.2.
#
# Since: 2.1
##
{ 'enum': 'MemoryDeviceInfoKind',
'data': [ 'dimm', 'nvdimm', 'virtio-pmem', 'virtio-mem', 'sgx-epc' ] }
##
# @PCDIMMDeviceInfoWrapper:
#
# Since: 2.1
##
{ 'struct': 'PCDIMMDeviceInfoWrapper',
'data': { 'data': 'PCDIMMDeviceInfo' } }
##
# @VirtioPMEMDeviceInfoWrapper:
#
# Since: 2.1
##
{ 'struct': 'VirtioPMEMDeviceInfoWrapper',
'data': { 'data': 'VirtioPMEMDeviceInfo' } }
##
# @VirtioMEMDeviceInfoWrapper:
#
# Since: 2.1
##
{ 'struct': 'VirtioMEMDeviceInfoWrapper',
'data': { 'data': 'VirtioMEMDeviceInfo' } }
##
# @SgxEPCDeviceInfoWrapper:
#
# Since: 6.2
##
{ 'struct': 'SgxEPCDeviceInfoWrapper',
'data': { 'data': 'SgxEPCDeviceInfo' } }
##
# @MemoryDeviceInfo:
#
# Union containing information about a memory device
#
# Since: 2.1
##
{ 'union': 'MemoryDeviceInfo',
'base': { 'type': 'MemoryDeviceInfoKind' },
'discriminator': 'type',
'data': { 'dimm': 'PCDIMMDeviceInfoWrapper',
'nvdimm': 'PCDIMMDeviceInfoWrapper',
'virtio-pmem': 'VirtioPMEMDeviceInfoWrapper',
'virtio-mem': 'VirtioMEMDeviceInfoWrapper',
'sgx-epc': 'SgxEPCDeviceInfoWrapper'
}
}
vl: Add sgx compound properties to expose SGX EPC sections to guest Because SGX EPC is enumerated through CPUID, EPC "devices" need to be realized prior to realizing the vCPUs themselves, i.e. long before generic devices are parsed and realized. From a virtualization perspective, the CPUID aspect also means that EPC sections cannot be hotplugged without paravirtualizing the guest kernel (hardware does not support hotplugging as EPC sections must be locked down during pre-boot to provide EPC's security properties). So even though EPC sections could be realized through the generic -devices command, they need to be created much earlier for them to actually be usable by the guest. Place all EPC sections in a contiguous block, somewhat arbitrarily starting after RAM above 4g. Ensuring EPC is in a contiguous region simplifies calculations, e.g. device memory base, PCI hole, etc..., allows dynamic calculation of the total EPC size, e.g. exposing EPC to guests does not require -maxmem, and last but not least allows all of EPC to be enumerated in a single ACPI entry, which is expected by some kernels, e.g. Windows 7 and 8. The new compound properties command for sgx like below: ...... -object memory-backend-epc,id=mem1,size=28M,prealloc=on \ -object memory-backend-epc,id=mem2,size=10M \ -M sgx-epc.0.memdev=mem1,sgx-epc.1.memdev=mem2 Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210719112136.57018-6-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-28 08:40:58 +00:00
##
# @SgxEPC:
#
# Sgx EPC cmdline information
#
# @memdev: memory backend linked with device
#
# @node: the numa node (Since: 7.0)
#
vl: Add sgx compound properties to expose SGX EPC sections to guest Because SGX EPC is enumerated through CPUID, EPC "devices" need to be realized prior to realizing the vCPUs themselves, i.e. long before generic devices are parsed and realized. From a virtualization perspective, the CPUID aspect also means that EPC sections cannot be hotplugged without paravirtualizing the guest kernel (hardware does not support hotplugging as EPC sections must be locked down during pre-boot to provide EPC's security properties). So even though EPC sections could be realized through the generic -devices command, they need to be created much earlier for them to actually be usable by the guest. Place all EPC sections in a contiguous block, somewhat arbitrarily starting after RAM above 4g. Ensuring EPC is in a contiguous region simplifies calculations, e.g. device memory base, PCI hole, etc..., allows dynamic calculation of the total EPC size, e.g. exposing EPC to guests does not require -maxmem, and last but not least allows all of EPC to be enumerated in a single ACPI entry, which is expected by some kernels, e.g. Windows 7 and 8. The new compound properties command for sgx like below: ...... -object memory-backend-epc,id=mem1,size=28M,prealloc=on \ -object memory-backend-epc,id=mem2,size=10M \ -M sgx-epc.0.memdev=mem1,sgx-epc.1.memdev=mem2 Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210719112136.57018-6-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-28 08:40:58 +00:00
# Since: 6.2
##
{ 'struct': 'SgxEPC',
'data': { 'memdev': 'str',
'node': 'int'
}
}
vl: Add sgx compound properties to expose SGX EPC sections to guest Because SGX EPC is enumerated through CPUID, EPC "devices" need to be realized prior to realizing the vCPUs themselves, i.e. long before generic devices are parsed and realized. From a virtualization perspective, the CPUID aspect also means that EPC sections cannot be hotplugged without paravirtualizing the guest kernel (hardware does not support hotplugging as EPC sections must be locked down during pre-boot to provide EPC's security properties). So even though EPC sections could be realized through the generic -devices command, they need to be created much earlier for them to actually be usable by the guest. Place all EPC sections in a contiguous block, somewhat arbitrarily starting after RAM above 4g. Ensuring EPC is in a contiguous region simplifies calculations, e.g. device memory base, PCI hole, etc..., allows dynamic calculation of the total EPC size, e.g. exposing EPC to guests does not require -maxmem, and last but not least allows all of EPC to be enumerated in a single ACPI entry, which is expected by some kernels, e.g. Windows 7 and 8. The new compound properties command for sgx like below: ...... -object memory-backend-epc,id=mem1,size=28M,prealloc=on \ -object memory-backend-epc,id=mem2,size=10M \ -M sgx-epc.0.memdev=mem1,sgx-epc.1.memdev=mem2 Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210719112136.57018-6-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-28 08:40:58 +00:00
##
# @SgxEPCProperties:
#
# SGX properties of machine types.
#
# @sgx-epc: list of ids of memory-backend-epc objects.
#
# Since: 6.2
##
{ 'struct': 'SgxEPCProperties',
'data': { 'sgx-epc': ['SgxEPC'] }
}
##
# @query-memory-devices:
#
# Lists available memory devices and their state
#
# Since: 2.1
#
# Example:
#
# -> { "execute": "query-memory-devices" }
# <- { "return": [ { "data":
# { "addr": 5368709120,
# "hotpluggable": true,
# "hotplugged": true,
# "id": "d1",
# "memdev": "/objects/memX",
# "node": 0,
# "size": 1073741824,
# "slot": 0},
# "type": "dimm"
# } ] }
##
{ 'command': 'query-memory-devices', 'returns': ['MemoryDeviceInfo'] }
##
# @MEMORY_DEVICE_SIZE_CHANGE:
#
# Emitted when the size of a memory device changes. Only emitted for
# memory devices that can actually change the size (e.g., virtio-mem
# due to guest action).
#
# @id: device's ID
#
# @size: the new size of memory that the device provides
#
# @qom-path: path to the device object in the QOM tree (since 6.2)
#
# Note: this event is rate-limited.
#
# Since: 5.1
#
# Example:
#
# <- { "event": "MEMORY_DEVICE_SIZE_CHANGE",
# "data": { "id": "vm0", "size": 1073741824,
# "qom-path": "/machine/unattached/device[2]" },
# "timestamp": { "seconds": 1588168529, "microseconds": 201316 } }
##
{ 'event': 'MEMORY_DEVICE_SIZE_CHANGE',
'data': { '*id': 'str', 'size': 'size', 'qom-path' : 'str'} }
##
# @MEM_UNPLUG_ERROR:
#
# Emitted when memory hot unplug error occurs.
#
# @device: device name
#
# @msg: Informative message
#
# Features:
#
# @deprecated: This event is deprecated. Use
# @DEVICE_UNPLUG_GUEST_ERROR instead.
#
# Since: 2.4
#
# Example:
#
# <- { "event": "MEM_UNPLUG_ERROR",
# "data": { "device": "dimm1",
# "msg": "acpi: device unplug for unsupported device"
# },
# "timestamp": { "seconds": 1265044230, "microseconds": 450486 } }
##
{ 'event': 'MEM_UNPLUG_ERROR',
'data': { 'device': 'str', 'msg': 'str' },
'features': ['deprecated'] }
##
# @BootConfiguration:
#
# Schema for virtual machine boot configuration.
#
# @order: Boot order (a=floppy, c=hard disk, d=CD-ROM, n=network)
#
# @once: Boot order to apply on first boot
#
# @menu: Whether to show a boot menu
#
# @splash: The name of the file to be passed to the firmware as logo
# picture, if @menu is true.
#
# @splash-time: How long to show the logo picture, in milliseconds
#
# @reboot-timeout: Timeout before guest reboots after boot fails
#
# @strict: Whether to attempt booting from devices not included in the
# boot order
#
# Since: 7.1
##
{ 'struct': 'BootConfiguration', 'data': {
'*order': 'str',
'*once': 'str',
'*menu': 'bool',
'*splash': 'str',
'*splash-time': 'int',
'*reboot-timeout': 'int',
'*strict': 'bool' } }
##
# @SMPConfiguration:
#
# Schema for CPU topology configuration. A missing value lets QEMU
# figure out a suitable value based on the ones that are provided.
#
# The members other than @cpus and @maxcpus define a topology of
# containers.
#
# The ordering from highest/coarsest to lowest/finest is:
# @drawers, @books, @sockets, @dies, @clusters, @cores, @threads.
#
# Different architectures support different subsets of topology
# containers.
hw/core/machine: Introduce CPU cluster topology support The new Cluster-Aware Scheduling support has landed in Linux 5.16, which has been proved to benefit the scheduling performance (e.g. load balance and wake_affine strategy) on both x86_64 and AArch64. So now in Linux 5.16 we have four-level arch-neutral CPU topology definition like below and a new scheduler level for clusters. struct cpu_topology { int thread_id; int core_id; int cluster_id; int package_id; int llc_id; cpumask_t thread_sibling; cpumask_t core_sibling; cpumask_t cluster_sibling; cpumask_t llc_sibling; } A cluster generally means a group of CPU cores which share L2 cache or other mid-level resources, and it is the shared resources that is used to improve scheduler's behavior. From the point of view of the size range, it's between CPU die and CPU core. For example, on some ARM64 Kunpeng servers, we have 6 clusters in each NUMA node, and 4 CPU cores in each cluster. The 4 CPU cores share a separate L2 cache and a L3 cache tag, which brings cache affinity advantage. In virtualization, on the Hosts which have pClusters (physical clusters), if we can design a vCPU topology with cluster level for guest kernel and have a dedicated vCPU pinning. A Cluster-Aware Guest kernel can also make use of the cache affinity of CPU clusters to gain similar scheduling performance. This patch adds infrastructure for CPU cluster level topology configuration and parsing, so that the user can specify cluster parameter if their machines support it. Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Message-Id: <20211228092221.21068-3-wangyanan55@huawei.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> [PMD: Added '(since 7.0)' to @clusters in qapi/machine.json] Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2021-12-28 09:22:09 +00:00
#
# For example, s390x does not have clusters and dies, and the socket
# is the parent container of cores.
#
# @cpus: number of virtual CPUs in the virtual machine
#
# @maxcpus: maximum number of hotpluggable virtual CPUs in the virtual
# machine
#
# @drawers: number of drawers in the CPU topology (since 8.2)
#
# @books: number of books in the CPU topology (since 8.2)
#
# @sockets: number of sockets per parent container
#
# @dies: number of dies per parent container
#
# @clusters: number of clusters per parent container (since 7.0)
#
# @cores: number of cores per parent container
#
# @threads: number of threads per core
#
# Since: 6.1
##
{ 'struct': 'SMPConfiguration', 'data': {
'*cpus': 'int',
'*drawers': 'int',
'*books': 'int',
'*sockets': 'int',
'*dies': 'int',
hw/core/machine: Introduce CPU cluster topology support The new Cluster-Aware Scheduling support has landed in Linux 5.16, which has been proved to benefit the scheduling performance (e.g. load balance and wake_affine strategy) on both x86_64 and AArch64. So now in Linux 5.16 we have four-level arch-neutral CPU topology definition like below and a new scheduler level for clusters. struct cpu_topology { int thread_id; int core_id; int cluster_id; int package_id; int llc_id; cpumask_t thread_sibling; cpumask_t core_sibling; cpumask_t cluster_sibling; cpumask_t llc_sibling; } A cluster generally means a group of CPU cores which share L2 cache or other mid-level resources, and it is the shared resources that is used to improve scheduler's behavior. From the point of view of the size range, it's between CPU die and CPU core. For example, on some ARM64 Kunpeng servers, we have 6 clusters in each NUMA node, and 4 CPU cores in each cluster. The 4 CPU cores share a separate L2 cache and a L3 cache tag, which brings cache affinity advantage. In virtualization, on the Hosts which have pClusters (physical clusters), if we can design a vCPU topology with cluster level for guest kernel and have a dedicated vCPU pinning. A Cluster-Aware Guest kernel can also make use of the cache affinity of CPU clusters to gain similar scheduling performance. This patch adds infrastructure for CPU cluster level topology configuration and parsing, so that the user can specify cluster parameter if their machines support it. Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Message-Id: <20211228092221.21068-3-wangyanan55@huawei.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> [PMD: Added '(since 7.0)' to @clusters in qapi/machine.json] Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2021-12-28 09:22:09 +00:00
'*clusters': 'int',
'*cores': 'int',
'*threads': 'int',
'*maxcpus': 'int' } }
##
# @x-query-irq:
#
# Query interrupt statistics
#
# Features:
#
# @unstable: This command is meant for debugging.
#
# Returns: interrupt statistics
#
# Since: 6.2
##
{ 'command': 'x-query-irq',
'returns': 'HumanReadableText',
'features': [ 'unstable' ] }
##
# @x-query-jit:
#
# Query TCG compiler statistics
#
# Features:
#
# @unstable: This command is meant for debugging.
#
# Returns: TCG compiler statistics
#
# Since: 6.2
##
{ 'command': 'x-query-jit',
'returns': 'HumanReadableText',
'if': 'CONFIG_TCG',
'features': [ 'unstable' ] }
##
# @x-query-numa:
#
# Query NUMA topology information
#
# Features:
#
# @unstable: This command is meant for debugging.
#
# Returns: topology information
#
# Since: 6.2
##
{ 'command': 'x-query-numa',
'returns': 'HumanReadableText',
'features': [ 'unstable' ] }
##
# @x-query-opcount:
#
# Query TCG opcode counters
#
# Features:
#
# @unstable: This command is meant for debugging.
#
# Returns: TCG opcode counters
#
# Since: 6.2
##
{ 'command': 'x-query-opcount',
'returns': 'HumanReadableText',
'if': 'CONFIG_TCG',
'features': [ 'unstable' ] }
##
# @x-query-ramblock:
#
# Query system ramblock information
#
# Features:
#
# @unstable: This command is meant for debugging.
#
# Returns: system ramblock information
#
# Since: 6.2
##
{ 'command': 'x-query-ramblock',
'returns': 'HumanReadableText',
'features': [ 'unstable' ] }
##
# @x-query-rdma:
#
# Query RDMA state
#
# Features:
#
# @unstable: This command is meant for debugging.
#
# Returns: RDMA state
#
# Since: 6.2
##
{ 'command': 'x-query-rdma',
'returns': 'HumanReadableText',
'features': [ 'unstable' ] }
##
# @x-query-roms:
#
# Query information on the registered ROMS
#
# Features:
#
# @unstable: This command is meant for debugging.
#
# Returns: registered ROMs
#
# Since: 6.2
##
{ 'command': 'x-query-roms',
'returns': 'HumanReadableText',
'features': [ 'unstable' ] }
##
# @x-query-usb:
#
# Query information on the USB devices
#
# Features:
#
# @unstable: This command is meant for debugging.
#
# Returns: USB device information
#
# Since: 6.2
##
{ 'command': 'x-query-usb',
'returns': 'HumanReadableText',
'features': [ 'unstable' ] }
##
# @SmbiosEntryPointType:
#
# @32: SMBIOS version 2.1 (32-bit) Entry Point
#
# @64: SMBIOS version 3.0 (64-bit) Entry Point
#
# Since: 7.0
##
{ 'enum': 'SmbiosEntryPointType',
'data': [ '32', '64' ] }
##
# @MemorySizeConfiguration:
#
# Schema for memory size configuration.
#
# @size: memory size in bytes
#
# @max-size: maximum hotpluggable memory size in bytes
#
# @slots: number of available memory slots for hotplug
#
# Since: 7.1
##
{ 'struct': 'MemorySizeConfiguration', 'data': {
'*size': 'size',
'*max-size': 'size',
'*slots': 'uint64' } }
##
# @dumpdtb:
#
# Save the FDT in dtb format.
#
# @filename: name of the dtb file to be created
#
# Since: 7.2
#
# Example:
#
# -> { "execute": "dumpdtb" }
# "arguments": { "filename": "fdt.dtb" } }
# <- { "return": {} }
##
{ 'command': 'dumpdtb',
'data': { 'filename': 'str' },
'if': 'CONFIG_FDT' }