2019-06-19 23:10:37 +03:00
|
|
|
# -*- Mode: Python -*-
|
2020-07-29 21:50:24 +03:00
|
|
|
# vim: filetype=python
|
2019-06-19 23:10:37 +03:00
|
|
|
#
|
|
|
|
# This work is licensed under the terms of the GNU GPL, version 2 or later.
|
|
|
|
# See the COPYING file in the top-level directory.
|
|
|
|
|
2020-10-20 13:47:58 +03:00
|
|
|
{ 'include': 'authz.json' }
|
2020-10-20 13:47:58 +03:00
|
|
|
{ 'include': 'block-core.json' }
|
2020-10-20 13:47:58 +03:00
|
|
|
{ 'include': 'common.json' }
|
2020-10-20 13:47:58 +03:00
|
|
|
{ 'include': 'crypto.json' }
|
2020-10-20 13:47:58 +03:00
|
|
|
|
2019-06-19 23:10:37 +03:00
|
|
|
##
|
|
|
|
# = QEMU Object Model (QOM)
|
|
|
|
##
|
|
|
|
|
|
|
|
##
|
|
|
|
# @ObjectPropertyInfo:
|
|
|
|
#
|
|
|
|
# @name: the name of the property
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @type: the type of the property. This will typically come in one of
|
|
|
|
# four forms:
|
2019-06-19 23:10:37 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# 1) A primitive type such as 'u8', 'u16', 'bool', 'str', or
|
|
|
|
# 'double'. These types are mapped to the appropriate JSON
|
|
|
|
# type.
|
2019-06-19 23:10:37 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# 2) A child type in the form 'child<subtype>' where subtype is a
|
|
|
|
# qdev device type name. Child properties create the
|
|
|
|
# composition tree.
|
2019-06-19 23:10:37 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# 3) A link type in the form 'link<subtype>' where subtype is a
|
|
|
|
# qdev device type name. Link properties form the device model
|
|
|
|
# graph.
|
2019-06-19 23:10:37 +03:00
|
|
|
#
|
|
|
|
# @description: if specified, the description of the property.
|
|
|
|
#
|
2020-01-10 18:30:38 +03:00
|
|
|
# @default-value: the default value, if any (since 5.0)
|
|
|
|
#
|
2019-06-19 23:10:37 +03:00
|
|
|
# Since: 1.2
|
|
|
|
##
|
|
|
|
{ 'struct': 'ObjectPropertyInfo',
|
2020-01-10 18:30:38 +03:00
|
|
|
'data': { 'name': 'str',
|
|
|
|
'type': 'str',
|
|
|
|
'*description': 'str',
|
|
|
|
'*default-value': 'any' } }
|
2019-06-19 23:10:37 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @qom-list:
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# This command will list any properties of a object given a path in
|
|
|
|
# the object model.
|
2019-06-19 23:10:37 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @path: the path within the object model. See @qom-get for a
|
|
|
|
# description of this parameter.
|
2019-06-19 23:10:37 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# Returns: a list of @ObjectPropertyInfo that describe the properties
|
|
|
|
# of the object.
|
2019-06-19 23:10:37 +03:00
|
|
|
#
|
|
|
|
# Since: 1.2
|
|
|
|
#
|
2024-07-17 05:13:08 +03:00
|
|
|
# .. qmp-example::
|
2019-06-19 23:10:37 +03:00
|
|
|
#
|
2024-02-16 17:58:34 +03:00
|
|
|
# -> { "execute": "qom-list",
|
|
|
|
# "arguments": { "path": "/chardevs" } }
|
|
|
|
# <- { "return": [ { "name": "type", "type": "string" },
|
|
|
|
# { "name": "parallel0", "type": "child<chardev-vc>" },
|
|
|
|
# { "name": "serial0", "type": "child<chardev-vc>" },
|
|
|
|
# { "name": "mon0", "type": "child<chardev-stdio>" } ] }
|
2019-06-19 23:10:37 +03:00
|
|
|
##
|
|
|
|
{ 'command': 'qom-list',
|
|
|
|
'data': { 'path': 'str' },
|
|
|
|
'returns': [ 'ObjectPropertyInfo' ],
|
|
|
|
'allow-preconfig': true }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @qom-get:
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# This command will get a property from a object model path and return
|
|
|
|
# the value.
|
2019-06-19 23:10:37 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @path: The path within the object model. There are two forms of
|
|
|
|
# supported paths--absolute and partial paths.
|
2019-06-19 23:10:37 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# Absolute paths are derived from the root object and can follow
|
|
|
|
# child<> or link<> properties. Since they can follow link<>
|
|
|
|
# properties, they can be arbitrarily long. Absolute paths look
|
|
|
|
# like absolute filenames and are prefixed with a leading slash.
|
2019-06-19 23:10:37 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# Partial paths look like relative filenames. They do not begin
|
|
|
|
# with a prefix. The matching rules for partial paths are subtle
|
|
|
|
# but designed to make specifying objects easy. At each level of
|
|
|
|
# the composition tree, the partial path is matched as an absolute
|
|
|
|
# path. The first match is not returned. At least two matches
|
|
|
|
# are searched for. A successful result is only returned if only
|
|
|
|
# one match is found. If more than one match is found, a flag is
|
|
|
|
# return to indicate that the match was ambiguous.
|
2019-06-19 23:10:37 +03:00
|
|
|
#
|
|
|
|
# @property: The property name to read
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# Returns: The property value. The type depends on the property type.
|
|
|
|
# child<> and link<> properties are returned as #str pathnames.
|
|
|
|
# All integer property types (u8, u16, etc) are returned as #int.
|
2019-06-19 23:10:37 +03:00
|
|
|
#
|
|
|
|
# Since: 1.2
|
|
|
|
#
|
2024-07-17 05:13:09 +03:00
|
|
|
# .. qmp-example::
|
|
|
|
# :title: Use absolute path
|
2019-06-19 23:10:37 +03:00
|
|
|
#
|
2024-02-16 17:58:34 +03:00
|
|
|
# -> { "execute": "qom-get",
|
|
|
|
# "arguments": { "path": "/machine/unattached/device[0]",
|
|
|
|
# "property": "hotplugged" } }
|
|
|
|
# <- { "return": false }
|
2019-06-19 23:10:37 +03:00
|
|
|
#
|
2024-07-17 05:13:09 +03:00
|
|
|
# .. qmp-example::
|
|
|
|
# :title: Use partial path
|
2019-06-19 23:10:37 +03:00
|
|
|
#
|
2024-02-16 17:58:34 +03:00
|
|
|
# -> { "execute": "qom-get",
|
|
|
|
# "arguments": { "path": "unattached/sysbus",
|
|
|
|
# "property": "type" } }
|
|
|
|
# <- { "return": "System" }
|
2019-06-19 23:10:37 +03:00
|
|
|
##
|
|
|
|
{ 'command': 'qom-get',
|
|
|
|
'data': { 'path': 'str', 'property': 'str' },
|
|
|
|
'returns': 'any',
|
|
|
|
'allow-preconfig': true }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @qom-set:
|
|
|
|
#
|
|
|
|
# This command will set a property from a object model path.
|
|
|
|
#
|
|
|
|
# @path: see @qom-get for a description of this parameter
|
|
|
|
#
|
|
|
|
# @property: the property name to set
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @value: a value who's type is appropriate for the property type.
|
|
|
|
# See @qom-get for a description of type mapping.
|
2019-06-19 23:10:37 +03:00
|
|
|
#
|
|
|
|
# Since: 1.2
|
|
|
|
#
|
2024-07-17 05:13:08 +03:00
|
|
|
# .. qmp-example::
|
2019-06-19 23:10:37 +03:00
|
|
|
#
|
2024-02-16 17:58:34 +03:00
|
|
|
# -> { "execute": "qom-set",
|
|
|
|
# "arguments": { "path": "/machine",
|
|
|
|
# "property": "graphics",
|
|
|
|
# "value": false } }
|
|
|
|
# <- { "return": {} }
|
2019-06-19 23:10:37 +03:00
|
|
|
##
|
|
|
|
{ 'command': 'qom-set',
|
|
|
|
'data': { 'path': 'str', 'property': 'str', 'value': 'any' },
|
|
|
|
'allow-preconfig': true }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @ObjectTypeInfo:
|
|
|
|
#
|
|
|
|
# This structure describes a search result from @qom-list-types
|
|
|
|
#
|
|
|
|
# @name: the type name found in the search
|
|
|
|
#
|
|
|
|
# @abstract: the type is abstract and can't be directly instantiated.
|
2023-04-28 13:54:29 +03:00
|
|
|
# Omitted if false. (since 2.10)
|
2019-06-19 23:10:37 +03:00
|
|
|
#
|
|
|
|
# @parent: Name of parent type, if any (since 2.10)
|
|
|
|
#
|
|
|
|
# Since: 1.1
|
|
|
|
##
|
|
|
|
{ 'struct': 'ObjectTypeInfo',
|
|
|
|
'data': { 'name': 'str', '*abstract': 'bool', '*parent': 'str' } }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @qom-list-types:
|
|
|
|
#
|
|
|
|
# This command will return a list of types given search parameters
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @implements: if specified, only return types that implement this
|
|
|
|
# type name
|
2019-06-19 23:10:37 +03:00
|
|
|
#
|
|
|
|
# @abstract: if true, include abstract types in the results
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# Returns: a list of @ObjectTypeInfo or an empty list if no results
|
|
|
|
# are found
|
2019-06-19 23:10:37 +03:00
|
|
|
#
|
|
|
|
# Since: 1.1
|
|
|
|
##
|
|
|
|
{ 'command': 'qom-list-types',
|
|
|
|
'data': { '*implements': 'str', '*abstract': 'bool' },
|
|
|
|
'returns': [ 'ObjectTypeInfo' ],
|
|
|
|
'allow-preconfig': true }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @qom-list-properties:
|
|
|
|
#
|
|
|
|
# List properties associated with a QOM object.
|
|
|
|
#
|
|
|
|
# @typename: the type name of an object
|
|
|
|
#
|
qapi: convert "Note" sections to plain rST
We do not need a dedicated section for notes. By eliminating a specially
parsed section, these notes can be treated as normal rST paragraphs in
the new QMP reference manual, and can be placed and styled much more
flexibly.
Convert all existing "Note" and "Notes" sections to pure rST. As part of
the conversion, capitalize the first letter of each sentence and add
trailing punctuation where appropriate to ensure notes look sensible and
consistent in rendered HTML documentation. Markup is also re-aligned to
the de-facto standard of 3 spaces for directives.
Update docs/devel/qapi-code-gen.rst to reflect the new paradigm, and
update the QAPI parser to prohibit "Note" sections while suggesting a
new syntax. The exact formatting to use is a matter of taste, but a good
candidate is simply:
.. note:: lorem ipsum ...
... dolor sit amet ...
... consectetur adipiscing elit ...
... but there are other choices, too. The Sphinx readthedocs theme
offers theming for the following forms (capitalization unimportant); all
are adorned with a (!) symbol () in the title bar for rendered HTML
docs.
See
https://sphinx-rtd-theme.readthedocs.io/en/stable/demo/demo.html#admonitions
for examples of each directive/admonition in use.
These are rendered in orange:
.. Attention:: ...
.. Caution:: ...
.. WARNING:: ...
These are rendered in red:
.. DANGER:: ...
.. Error:: ...
These are rendered in green:
.. Hint:: ...
.. Important:: ...
.. Tip:: ...
These are rendered in blue:
.. Note:: ...
.. admonition:: custom title
admonition body text
This patch uses ".. note::" almost everywhere, with just two "caution"
directives. Several instances of "Notes:" have been converted to
merely ".. note::", or multiple ".. note::" where appropriate.
".. admonition:: notes" is used in a few places where we had an
ordered list of multiple notes that would not make sense as
standalone/separate admonitions. Two "Note:" following "Example:"
have been turned into ordinary paragraphs within the example.
NOTE: Because qapidoc.py does not attempt to preserve source ordering of
sections, the conversion of Notes from a "tagged section" to an
"untagged section" means that rendering order for some notes *may
change* as a result of this patch. The forthcoming qapidoc.py rewrite
strictly preserves source ordering in the rendered documentation, so
this issue will be rectified in the new generator.
Signed-off-by: John Snow <jsnow@redhat.com>
Acked-by: Stefan Hajnoczi <stefanha@redhat.com> [for block*.json]
Message-ID: <20240626222128.406106-11-jsnow@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
[Commit message clarified slightly, period added to one more note]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2024-06-27 01:21:16 +03:00
|
|
|
# .. note:: Objects can create properties at runtime, for example to
|
|
|
|
# describe links between different devices and/or objects. These
|
|
|
|
# properties are not included in the output of this command.
|
2019-06-19 23:10:37 +03:00
|
|
|
#
|
|
|
|
# Returns: a list of ObjectPropertyInfo describing object properties
|
|
|
|
#
|
|
|
|
# Since: 2.12
|
|
|
|
##
|
|
|
|
{ 'command': 'qom-list-properties',
|
|
|
|
'data': { 'typename': 'str'},
|
|
|
|
'returns': [ 'ObjectPropertyInfo' ],
|
|
|
|
'allow-preconfig': true }
|
|
|
|
|
2020-10-20 13:47:58 +03:00
|
|
|
##
|
|
|
|
# @CanHostSocketcanProperties:
|
|
|
|
#
|
|
|
|
# Properties for can-host-socketcan objects.
|
|
|
|
#
|
|
|
|
# @if: interface name of the host system CAN bus to connect to
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @canbus: object ID of the can-bus object to connect to the host
|
|
|
|
# interface
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
|
|
|
# Since: 2.12
|
|
|
|
##
|
|
|
|
{ 'struct': 'CanHostSocketcanProperties',
|
|
|
|
'data': { 'if': 'str',
|
2024-06-04 16:59:31 +03:00
|
|
|
'canbus': 'str' },
|
|
|
|
'if': 'CONFIG_LINUX' }
|
2020-10-20 13:47:58 +03:00
|
|
|
|
2020-10-20 13:47:58 +03:00
|
|
|
##
|
|
|
|
# @ColoCompareProperties:
|
|
|
|
#
|
|
|
|
# Properties for colo-compare objects.
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @primary_in: name of the character device backend to use for the
|
|
|
|
# primary input (incoming packets are redirected to @outdev)
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @secondary_in: name of the character device backend to use for
|
|
|
|
# secondary input (incoming packets are only compared to the input
|
|
|
|
# on @primary_in and then dropped)
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
|
|
|
# @outdev: name of the character device backend to use for output
|
|
|
|
#
|
|
|
|
# @iothread: name of the iothread to run in
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @notify_dev: name of the character device backend to be used to
|
|
|
|
# communicate with the remote colo-frame (only for Xen COLO)
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @compare_timeout: the maximum time to hold a packet from @primary_in
|
|
|
|
# for comparison with an incoming packet on @secondary_in in
|
|
|
|
# milliseconds (default: 3000)
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @expired_scan_cycle: the interval at which colo-compare checks
|
|
|
|
# whether packets from @primary have timed out, in milliseconds
|
|
|
|
# (default: 3000)
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @max_queue_size: the maximum number of packets to keep in the queue
|
|
|
|
# for comparing with incoming packets from @secondary_in. If the
|
|
|
|
# queue is full and additional packets are received, the
|
|
|
|
# additional packets are dropped. (default: 1024)
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @vnet_hdr_support: if true, vnet header support is enabled
|
|
|
|
# (default: false)
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
|
|
|
# Since: 2.8
|
|
|
|
##
|
|
|
|
{ 'struct': 'ColoCompareProperties',
|
|
|
|
'data': { 'primary_in': 'str',
|
|
|
|
'secondary_in': 'str',
|
|
|
|
'outdev': 'str',
|
|
|
|
'iothread': 'str',
|
|
|
|
'*notify_dev': 'str',
|
|
|
|
'*compare_timeout': 'uint64',
|
|
|
|
'*expired_scan_cycle': 'uint32',
|
|
|
|
'*max_queue_size': 'uint32',
|
|
|
|
'*vnet_hdr_support': 'bool' } }
|
|
|
|
|
2020-10-20 13:47:58 +03:00
|
|
|
##
|
|
|
|
# @CryptodevBackendProperties:
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# Properties for cryptodev-backend and cryptodev-backend-builtin
|
|
|
|
# objects.
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @queues: the number of queues for the cryptodev backend. Ignored
|
|
|
|
# for cryptodev-backend and must be 1 for
|
|
|
|
# cryptodev-backend-builtin. (default: 1)
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
2023-03-01 13:58:45 +03:00
|
|
|
# @throttle-bps: limit total bytes per second (Since 8.0)
|
|
|
|
#
|
|
|
|
# @throttle-ops: limit total operations per second (Since 8.0)
|
|
|
|
#
|
2020-10-20 13:47:58 +03:00
|
|
|
# Since: 2.8
|
|
|
|
##
|
|
|
|
{ 'struct': 'CryptodevBackendProperties',
|
2023-03-01 13:58:45 +03:00
|
|
|
'data': { '*queues': 'uint32',
|
|
|
|
'*throttle-bps': 'uint64',
|
|
|
|
'*throttle-ops': 'uint64' } }
|
2020-10-20 13:47:58 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @CryptodevVhostUserProperties:
|
|
|
|
#
|
|
|
|
# Properties for cryptodev-vhost-user objects.
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @chardev: the name of a Unix domain socket character device that
|
|
|
|
# connects to the vhost-user server
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
|
|
|
# Since: 2.12
|
|
|
|
##
|
|
|
|
{ 'struct': 'CryptodevVhostUserProperties',
|
|
|
|
'base': 'CryptodevBackendProperties',
|
2024-06-04 16:59:31 +03:00
|
|
|
'data': { 'chardev': 'str' },
|
|
|
|
'if': 'CONFIG_VHOST_CRYPTO' }
|
2020-10-20 13:47:58 +03:00
|
|
|
|
2020-10-20 13:47:58 +03:00
|
|
|
##
|
|
|
|
# @DBusVMStateProperties:
|
|
|
|
#
|
|
|
|
# Properties for dbus-vmstate objects.
|
|
|
|
#
|
|
|
|
# @addr: the name of the DBus bus to connect to
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @id-list: a comma separated list of DBus IDs of helpers whose data
|
|
|
|
# should be included in the VM state on migration
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
|
|
|
# Since: 5.0
|
|
|
|
##
|
|
|
|
{ 'struct': 'DBusVMStateProperties',
|
|
|
|
'data': { 'addr': 'str' ,
|
|
|
|
'*id-list': 'str' } }
|
|
|
|
|
2020-10-20 13:47:58 +03:00
|
|
|
##
|
|
|
|
# @NetfilterInsert:
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# Indicates where to insert a netfilter relative to a given other
|
|
|
|
# filter.
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
|
|
|
# @before: insert before the specified filter
|
|
|
|
#
|
|
|
|
# @behind: insert behind the specified filter
|
|
|
|
#
|
|
|
|
# Since: 5.0
|
|
|
|
##
|
|
|
|
{ 'enum': 'NetfilterInsert',
|
|
|
|
'data': [ 'before', 'behind' ] }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @NetfilterProperties:
|
|
|
|
#
|
|
|
|
# Properties for objects of classes derived from netfilter.
|
|
|
|
#
|
|
|
|
# @netdev: id of the network device backend to filter
|
|
|
|
#
|
|
|
|
# @queue: indicates which queue(s) to filter (default: all)
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @status: indicates whether the filter is enabled ("on") or disabled
|
|
|
|
# ("off") (default: "on")
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @position: specifies where the filter should be inserted in the
|
|
|
|
# filter list. "head" means the filter is inserted at the head of
|
|
|
|
# the filter list, before any existing filters. "tail" means the
|
|
|
|
# filter is inserted at the tail of the filter list, behind any
|
2024-07-29 09:52:20 +03:00
|
|
|
# existing filters (default). "id=<id>" means the filter is
|
2023-04-28 13:54:29 +03:00
|
|
|
# inserted before or behind the filter specified by <id>,
|
|
|
|
# depending on the @insert property. (default: "tail")
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @insert: where to insert the filter relative to the filter given in
|
|
|
|
# @position. Ignored if @position is "head" or "tail".
|
|
|
|
# (default: behind)
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
|
|
|
# Since: 2.5
|
|
|
|
##
|
|
|
|
{ 'struct': 'NetfilterProperties',
|
|
|
|
'data': { 'netdev': 'str',
|
|
|
|
'*queue': 'NetFilterDirection',
|
|
|
|
'*status': 'str',
|
|
|
|
'*position': 'str',
|
|
|
|
'*insert': 'NetfilterInsert' } }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @FilterBufferProperties:
|
|
|
|
#
|
|
|
|
# Properties for filter-buffer objects.
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @interval: a non-zero interval in microseconds. All packets
|
|
|
|
# arriving in the given interval are delayed until the end of the
|
|
|
|
# interval.
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
|
|
|
# Since: 2.5
|
|
|
|
##
|
|
|
|
{ 'struct': 'FilterBufferProperties',
|
|
|
|
'base': 'NetfilterProperties',
|
|
|
|
'data': { 'interval': 'uint32' } }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @FilterDumpProperties:
|
|
|
|
#
|
|
|
|
# Properties for filter-dump objects.
|
|
|
|
#
|
|
|
|
# @file: the filename where the dumped packets should be stored
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @maxlen: maximum number of bytes in a packet that are stored
|
|
|
|
# (default: 65536)
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
|
|
|
# Since: 2.5
|
|
|
|
##
|
|
|
|
{ 'struct': 'FilterDumpProperties',
|
|
|
|
'base': 'NetfilterProperties',
|
|
|
|
'data': { 'file': 'str',
|
|
|
|
'*maxlen': 'uint32' } }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @FilterMirrorProperties:
|
|
|
|
#
|
|
|
|
# Properties for filter-mirror objects.
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @outdev: the name of a character device backend to which all
|
|
|
|
# incoming packets are mirrored
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @vnet_hdr_support: if true, vnet header support is enabled
|
|
|
|
# (default: false)
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
|
|
|
# Since: 2.6
|
|
|
|
##
|
|
|
|
{ 'struct': 'FilterMirrorProperties',
|
|
|
|
'base': 'NetfilterProperties',
|
|
|
|
'data': { 'outdev': 'str',
|
|
|
|
'*vnet_hdr_support': 'bool' } }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @FilterRedirectorProperties:
|
|
|
|
#
|
|
|
|
# Properties for filter-redirector objects.
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# At least one of @indev or @outdev must be present. If both are
|
|
|
|
# present, they must not refer to the same character device backend.
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @indev: the name of a character device backend from which packets
|
|
|
|
# are received and redirected to the filtered network device
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @outdev: the name of a character device backend to which all
|
|
|
|
# incoming packets are redirected
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @vnet_hdr_support: if true, vnet header support is enabled
|
|
|
|
# (default: false)
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
|
|
|
# Since: 2.6
|
|
|
|
##
|
|
|
|
{ 'struct': 'FilterRedirectorProperties',
|
|
|
|
'base': 'NetfilterProperties',
|
|
|
|
'data': { '*indev': 'str',
|
|
|
|
'*outdev': 'str',
|
|
|
|
'*vnet_hdr_support': 'bool' } }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @FilterRewriterProperties:
|
|
|
|
#
|
|
|
|
# Properties for filter-rewriter objects.
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @vnet_hdr_support: if true, vnet header support is enabled
|
|
|
|
# (default: false)
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
|
|
|
# Since: 2.8
|
|
|
|
##
|
|
|
|
{ 'struct': 'FilterRewriterProperties',
|
|
|
|
'base': 'NetfilterProperties',
|
|
|
|
'data': { '*vnet_hdr_support': 'bool' } }
|
|
|
|
|
2020-10-20 13:47:58 +03:00
|
|
|
##
|
|
|
|
# @InputBarrierProperties:
|
|
|
|
#
|
|
|
|
# Properties for input-barrier objects.
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @name: the screen name as declared in the screens section of
|
|
|
|
# barrier.conf
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
|
|
|
# @server: hostname of the Barrier server (default: "localhost")
|
|
|
|
#
|
|
|
|
# @port: TCP port of the Barrier server (default: "24800")
|
|
|
|
#
|
|
|
|
# @x-origin: x coordinate of the leftmost pixel on the guest screen
|
2023-04-28 13:54:29 +03:00
|
|
|
# (default: "0")
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
|
|
|
# @y-origin: y coordinate of the topmost pixel on the guest screen
|
2023-04-28 13:54:29 +03:00
|
|
|
# (default: "0")
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
|
|
|
# @width: the width of secondary screen in pixels (default: "1920")
|
|
|
|
#
|
|
|
|
# @height: the height of secondary screen in pixels (default: "1080")
|
|
|
|
#
|
|
|
|
# Since: 4.2
|
|
|
|
##
|
|
|
|
{ 'struct': 'InputBarrierProperties',
|
|
|
|
'data': { 'name': 'str',
|
|
|
|
'*server': 'str',
|
|
|
|
'*port': 'str',
|
|
|
|
'*x-origin': 'str',
|
|
|
|
'*y-origin': 'str',
|
|
|
|
'*width': 'str',
|
|
|
|
'*height': 'str' } }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @InputLinuxProperties:
|
|
|
|
#
|
|
|
|
# Properties for input-linux objects.
|
|
|
|
#
|
|
|
|
# @evdev: the path of the host evdev device to use
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @grab_all: if true, grab is toggled for all devices (e.g. both
|
|
|
|
# keyboard and mouse) instead of just one device (default: false)
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
|
|
|
# @repeat: enables auto-repeat events (default: false)
|
|
|
|
#
|
|
|
|
# @grab-toggle: the key or key combination that toggles device grab
|
2023-04-28 13:54:29 +03:00
|
|
|
# (default: ctrl-ctrl)
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
|
|
|
# Since: 2.6
|
|
|
|
##
|
|
|
|
{ 'struct': 'InputLinuxProperties',
|
|
|
|
'data': { 'evdev': 'str',
|
|
|
|
'*grab_all': 'bool',
|
|
|
|
'*repeat': 'bool',
|
2024-06-04 16:59:31 +03:00
|
|
|
'*grab-toggle': 'GrabToggleKeys' },
|
|
|
|
'if': 'CONFIG_LINUX' }
|
2020-10-20 13:47:58 +03:00
|
|
|
|
2022-04-25 10:57:21 +03:00
|
|
|
##
|
|
|
|
# @EventLoopBaseProperties:
|
|
|
|
#
|
|
|
|
# Common properties for event loops
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @aio-max-batch: maximum number of requests in a batch for the AIO
|
|
|
|
# engine, 0 means that the engine will use its default.
|
|
|
|
# (default: 0)
|
2022-04-25 10:57:21 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @thread-pool-min: minimum number of threads reserved in the thread
|
|
|
|
# pool (default:0)
|
2022-04-25 10:57:23 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @thread-pool-max: maximum number of threads the thread pool can
|
|
|
|
# contain (default:64)
|
2022-04-25 10:57:23 +03:00
|
|
|
#
|
2022-04-25 10:57:21 +03:00
|
|
|
# Since: 7.1
|
|
|
|
##
|
|
|
|
{ 'struct': 'EventLoopBaseProperties',
|
2022-04-25 10:57:23 +03:00
|
|
|
'data': { '*aio-max-batch': 'int',
|
|
|
|
'*thread-pool-min': 'int',
|
|
|
|
'*thread-pool-max': 'int' } }
|
2022-04-25 10:57:21 +03:00
|
|
|
|
2020-10-20 13:47:58 +03:00
|
|
|
##
|
|
|
|
# @IothreadProperties:
|
|
|
|
#
|
|
|
|
# Properties for iothread objects.
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @poll-max-ns: the maximum number of nanoseconds to busy wait for
|
|
|
|
# events. 0 means polling is disabled (default: 32768 on POSIX
|
|
|
|
# hosts, 0 otherwise)
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @poll-grow: the multiplier used to increase the polling time when
|
|
|
|
# the algorithm detects it is missing events due to not polling
|
|
|
|
# long enough. 0 selects a default behaviour (default: 0)
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
|
|
|
# @poll-shrink: the divisor used to decrease the polling time when the
|
2023-04-28 13:54:29 +03:00
|
|
|
# algorithm detects it is spending too long polling without
|
|
|
|
# encountering events. 0 selects a default behaviour (default: 0)
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
2022-04-25 10:57:21 +03:00
|
|
|
# The @aio-max-batch option is available since 6.1.
|
2021-07-21 12:42:10 +03:00
|
|
|
#
|
2020-10-20 13:47:58 +03:00
|
|
|
# Since: 2.0
|
|
|
|
##
|
|
|
|
{ 'struct': 'IothreadProperties',
|
2022-04-25 10:57:21 +03:00
|
|
|
'base': 'EventLoopBaseProperties',
|
2020-10-20 13:47:58 +03:00
|
|
|
'data': { '*poll-max-ns': 'int',
|
|
|
|
'*poll-grow': 'int',
|
2022-04-25 10:57:21 +03:00
|
|
|
'*poll-shrink': 'int' } }
|
2020-10-20 13:47:58 +03:00
|
|
|
|
2022-04-25 10:57:22 +03:00
|
|
|
##
|
|
|
|
# @MainLoopProperties:
|
|
|
|
#
|
|
|
|
# Properties for the main-loop object.
|
|
|
|
#
|
|
|
|
# Since: 7.1
|
|
|
|
##
|
|
|
|
{ 'struct': 'MainLoopProperties',
|
|
|
|
'base': 'EventLoopBaseProperties',
|
|
|
|
'data': {} }
|
|
|
|
|
2020-10-20 13:47:58 +03:00
|
|
|
##
|
|
|
|
# @MemoryBackendProperties:
|
|
|
|
#
|
|
|
|
# Properties for objects of classes derived from memory-backend.
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @merge: if true, mark the memory as mergeable (default depends on
|
|
|
|
# the machine type)
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @dump: if true, include the memory in core dumps (default depends on
|
|
|
|
# the machine type)
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
|
|
|
# @host-nodes: the list of NUMA host nodes to bind the memory to
|
|
|
|
#
|
|
|
|
# @policy: the NUMA policy (default: 'default')
|
|
|
|
#
|
|
|
|
# @prealloc: if true, preallocate memory (default: false)
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @prealloc-threads: number of CPU threads to use for prealloc
|
|
|
|
# (default: 1)
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @prealloc-context: thread context to use for creation of
|
|
|
|
# preallocation threads (default: none) (since 7.2)
|
2022-10-14 16:47:19 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @share: if false, the memory is private to QEMU; if true, it is
|
2024-06-18 13:00:31 +03:00
|
|
|
# shared (default false for backends memory-backend-file and
|
2024-06-18 13:05:19 +03:00
|
|
|
# memory-backend-ram, true for backends memory-backend-epc,
|
|
|
|
# memory-backend-memfd, and memory-backend-shm)
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
2021-05-10 14:43:23 +03:00
|
|
|
# @reserve: if true, reserve swap space (or huge pages) if applicable
|
2023-04-28 13:54:29 +03:00
|
|
|
# (default: true) (since 6.1)
|
2021-05-10 14:43:23 +03:00
|
|
|
#
|
2020-10-20 13:47:58 +03:00
|
|
|
# @size: size of the memory region in bytes
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @x-use-canonical-path-for-ramblock-id: if true, the canonical path
|
|
|
|
# is used for ramblock-id. Disable this for 4.0 machine types or
|
|
|
|
# older to allow migration with newer QEMU versions.
|
|
|
|
# (default: false generally, but true for machine types <= 4.0)
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
qapi: convert "Note" sections to plain rST
We do not need a dedicated section for notes. By eliminating a specially
parsed section, these notes can be treated as normal rST paragraphs in
the new QMP reference manual, and can be placed and styled much more
flexibly.
Convert all existing "Note" and "Notes" sections to pure rST. As part of
the conversion, capitalize the first letter of each sentence and add
trailing punctuation where appropriate to ensure notes look sensible and
consistent in rendered HTML documentation. Markup is also re-aligned to
the de-facto standard of 3 spaces for directives.
Update docs/devel/qapi-code-gen.rst to reflect the new paradigm, and
update the QAPI parser to prohibit "Note" sections while suggesting a
new syntax. The exact formatting to use is a matter of taste, but a good
candidate is simply:
.. note:: lorem ipsum ...
... dolor sit amet ...
... consectetur adipiscing elit ...
... but there are other choices, too. The Sphinx readthedocs theme
offers theming for the following forms (capitalization unimportant); all
are adorned with a (!) symbol () in the title bar for rendered HTML
docs.
See
https://sphinx-rtd-theme.readthedocs.io/en/stable/demo/demo.html#admonitions
for examples of each directive/admonition in use.
These are rendered in orange:
.. Attention:: ...
.. Caution:: ...
.. WARNING:: ...
These are rendered in red:
.. DANGER:: ...
.. Error:: ...
These are rendered in green:
.. Hint:: ...
.. Important:: ...
.. Tip:: ...
These are rendered in blue:
.. Note:: ...
.. admonition:: custom title
admonition body text
This patch uses ".. note::" almost everywhere, with just two "caution"
directives. Several instances of "Notes:" have been converted to
merely ".. note::", or multiple ".. note::" where appropriate.
".. admonition:: notes" is used in a few places where we had an
ordered list of multiple notes that would not make sense as
standalone/separate admonitions. Two "Note:" following "Example:"
have been turned into ordinary paragraphs within the example.
NOTE: Because qapidoc.py does not attempt to preserve source ordering of
sections, the conversion of Notes from a "tagged section" to an
"untagged section" means that rendering order for some notes *may
change* as a result of this patch. The forthcoming qapidoc.py rewrite
strictly preserves source ordering in the rendered documentation, so
this issue will be rectified in the new generator.
Signed-off-by: John Snow <jsnow@redhat.com>
Acked-by: Stefan Hajnoczi <stefanha@redhat.com> [for block*.json]
Message-ID: <20240626222128.406106-11-jsnow@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
[Commit message clarified slightly, period added to one more note]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2024-06-27 01:21:16 +03:00
|
|
|
# .. note:: prealloc=true and reserve=false cannot be set at the same
|
|
|
|
# time. With reserve=true, the behavior depends on the operating
|
|
|
|
# system: for example, Linux will not reserve swap space for shared
|
2024-07-29 09:52:20 +03:00
|
|
|
# file mappings -- "not applicable". In contrast, reserve=false
|
|
|
|
# will bail out if it cannot be configured accordingly.
|
2021-05-10 14:43:23 +03:00
|
|
|
#
|
2020-10-20 13:47:58 +03:00
|
|
|
# Since: 2.1
|
|
|
|
##
|
|
|
|
{ 'struct': 'MemoryBackendProperties',
|
|
|
|
'data': { '*dump': 'bool',
|
|
|
|
'*host-nodes': ['uint16'],
|
|
|
|
'*merge': 'bool',
|
|
|
|
'*policy': 'HostMemPolicy',
|
|
|
|
'*prealloc': 'bool',
|
|
|
|
'*prealloc-threads': 'uint32',
|
2022-10-14 16:47:19 +03:00
|
|
|
'*prealloc-context': 'str',
|
2020-10-20 13:47:58 +03:00
|
|
|
'*share': 'bool',
|
2021-05-10 14:43:23 +03:00
|
|
|
'*reserve': 'bool',
|
2020-10-20 13:47:58 +03:00
|
|
|
'size': 'size',
|
|
|
|
'*x-use-canonical-path-for-ramblock-id': 'bool' } }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @MemoryBackendFileProperties:
|
|
|
|
#
|
|
|
|
# Properties for memory-backend-file objects.
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @align: the base address alignment when QEMU mmap(2)s @mem-path.
|
|
|
|
# Some backend stores specified by @mem-path require an alignment
|
|
|
|
# different than the default one used by QEMU, e.g. the device DAX
|
2024-07-29 09:52:20 +03:00
|
|
|
# /dev/dax0.0 requires 2M alignment rather than 4K. In such
|
|
|
|
# cases, users can specify the required alignment via this option.
|
|
|
|
# 0 selects a default alignment (currently the page size).
|
2023-04-28 13:54:29 +03:00
|
|
|
# (default: 0)
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
2023-07-20 10:16:09 +03:00
|
|
|
# @offset: the offset into the target file that the region starts at.
|
|
|
|
# You can use this option to back multiple regions with a single
|
2024-03-22 17:09:09 +03:00
|
|
|
# file. Must be a multiple of the page size.
|
2023-07-20 10:16:09 +03:00
|
|
|
# (default: 0) (since 8.1)
|
2023-04-04 01:14:21 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @discard-data: if true, the file contents can be destroyed when QEMU
|
|
|
|
# exits, to avoid unnecessarily flushing data to the backing file.
|
|
|
|
# Note that @discard-data is only an optimization, and QEMU might
|
|
|
|
# not discard file contents if it aborts unexpectedly or is
|
2024-03-22 17:09:09 +03:00
|
|
|
# terminated using SIGKILL. (default: false)
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @mem-path: the path to either a shared memory or huge page
|
|
|
|
# filesystem mount
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @pmem: specifies whether the backing file specified by @mem-path is
|
|
|
|
# in host persistent memory that can be accessed using the SNIA
|
2023-07-20 10:16:09 +03:00
|
|
|
# NVM programming model (e.g. Intel NVDIMM).
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @readonly: if true, the backing file is opened read-only; if false,
|
|
|
|
# it is opened read-write. (default: false)
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
2024-03-22 17:09:08 +03:00
|
|
|
# @rom: whether to create Read Only Memory (ROM) that cannot be
|
|
|
|
# modified by the VM. Any write attempts to such ROM will be
|
|
|
|
# denied. Most use cases want writable RAM instead of ROM.
|
|
|
|
# However, selected use cases, like R/O NVDIMMs, can benefit from
|
|
|
|
# ROM. If set to 'on', create ROM; if set to 'off', create
|
|
|
|
# writable RAM; if set to 'auto', the value of the @readonly
|
|
|
|
# property is used. This property is primarily helpful when we
|
|
|
|
# want to have proper RAM in configurations that would
|
|
|
|
# traditionally create ROM before this property was introduced: VM
|
|
|
|
# templating, where we want to open a file readonly (@readonly set
|
|
|
|
# to true) and mark the memory to be private for QEMU (@share set
|
|
|
|
# to false). For this use case, we need writable RAM instead of
|
|
|
|
# ROM, and want to set this property to 'off'. (default: auto,
|
|
|
|
# since 8.2)
|
backends/hostmem-file: Add "rom" property to support VM templating with R/O files
For now, "share=off,readonly=on" would always result in us opening the
file R/O and mmap'ing the opened file MAP_PRIVATE R/O -- effectively
turning it into ROM.
Especially for VM templating, "share=off" is a common use case. However,
that use case is impossible with files that lack write permissions,
because "share=off,readonly=on" will not give us writable RAM.
The sole user of ROM via memory-backend-file are R/O NVDIMMs, but as we
have users (Kata Containers) that rely on the existing behavior --
malicious VMs should not be able to consume COW memory for R/O NVDIMMs --
we cannot change the semantics of "share=off,readonly=on"
So let's add a new "rom" property with on/off/auto values. "auto" is
the default and what most people will use: for historical reasons, to not
change the old semantics, it defaults to the value of the "readonly"
property.
For VM templating, one can now use:
-object memory-backend-file,share=off,readonly=on,rom=off,...
But we'll disallow:
-object memory-backend-file,share=on,readonly=on,rom=off,...
because we would otherwise get an error when trying to mmap the R/O file
shared and writable. An explicit error message is cleaner.
We will also disallow for now:
-object memory-backend-file,share=off,readonly=off,rom=on,...
-object memory-backend-file,share=on,readonly=off,rom=on,...
It's not harmful, but also not really required for now.
Alternatives that were abandoned:
* Make "unarmed=on" for the NVDIMM set the memory region container
readonly. We would still see a change of ROM->RAM and possibly run
into memslot limits with vhost-user. Further, there might be use cases
for "unarmed=on" that should still allow writing to that memory
(temporary files, system RAM, ...).
* Add a new "readonly=on/off/auto" parameter for NVDIMMs. Similar issues
as with "unarmed=on".
* Make "readonly" consume "on/off/file" instead of being a 'bool' type.
This would slightly changes the behavior of the "readonly" parameter:
values like true/false (as accepted by a 'bool'type) would no longer be
accepted.
Message-ID: <20230906120503.359863-4-david@redhat.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
2023-09-06 15:04:55 +03:00
|
|
|
#
|
2020-10-20 13:47:58 +03:00
|
|
|
# Since: 2.1
|
|
|
|
##
|
|
|
|
{ 'struct': 'MemoryBackendFileProperties',
|
|
|
|
'base': 'MemoryBackendProperties',
|
|
|
|
'data': { '*align': 'size',
|
2023-04-04 01:14:21 +03:00
|
|
|
'*offset': 'size',
|
2020-10-20 13:47:58 +03:00
|
|
|
'*discard-data': 'bool',
|
|
|
|
'mem-path': 'str',
|
2021-08-04 11:31:05 +03:00
|
|
|
'*pmem': { 'type': 'bool', 'if': 'CONFIG_LIBPMEM' },
|
backends/hostmem-file: Add "rom" property to support VM templating with R/O files
For now, "share=off,readonly=on" would always result in us opening the
file R/O and mmap'ing the opened file MAP_PRIVATE R/O -- effectively
turning it into ROM.
Especially for VM templating, "share=off" is a common use case. However,
that use case is impossible with files that lack write permissions,
because "share=off,readonly=on" will not give us writable RAM.
The sole user of ROM via memory-backend-file are R/O NVDIMMs, but as we
have users (Kata Containers) that rely on the existing behavior --
malicious VMs should not be able to consume COW memory for R/O NVDIMMs --
we cannot change the semantics of "share=off,readonly=on"
So let's add a new "rom" property with on/off/auto values. "auto" is
the default and what most people will use: for historical reasons, to not
change the old semantics, it defaults to the value of the "readonly"
property.
For VM templating, one can now use:
-object memory-backend-file,share=off,readonly=on,rom=off,...
But we'll disallow:
-object memory-backend-file,share=on,readonly=on,rom=off,...
because we would otherwise get an error when trying to mmap the R/O file
shared and writable. An explicit error message is cleaner.
We will also disallow for now:
-object memory-backend-file,share=off,readonly=off,rom=on,...
-object memory-backend-file,share=on,readonly=off,rom=on,...
It's not harmful, but also not really required for now.
Alternatives that were abandoned:
* Make "unarmed=on" for the NVDIMM set the memory region container
readonly. We would still see a change of ROM->RAM and possibly run
into memslot limits with vhost-user. Further, there might be use cases
for "unarmed=on" that should still allow writing to that memory
(temporary files, system RAM, ...).
* Add a new "readonly=on/off/auto" parameter for NVDIMMs. Similar issues
as with "unarmed=on".
* Make "readonly" consume "on/off/file" instead of being a 'bool' type.
This would slightly changes the behavior of the "readonly" parameter:
values like true/false (as accepted by a 'bool'type) would no longer be
accepted.
Message-ID: <20230906120503.359863-4-david@redhat.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
2023-09-06 15:04:55 +03:00
|
|
|
'*readonly': 'bool',
|
|
|
|
'*rom': 'OnOffAuto' } }
|
2020-10-20 13:47:58 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @MemoryBackendMemfdProperties:
|
|
|
|
#
|
|
|
|
# Properties for memory-backend-memfd objects.
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @hugetlb: if true, the file to be created resides in the hugetlbfs
|
|
|
|
# filesystem (default: false)
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @hugetlbsize: the hugetlb page size on systems that support multiple
|
|
|
|
# hugetlb page sizes (it must be a power of 2 value supported by
|
2024-07-29 09:52:20 +03:00
|
|
|
# the system). 0 selects a default page size. This option is
|
2023-04-28 13:54:29 +03:00
|
|
|
# ignored if @hugetlb is false. (default: 0)
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @seal: if true, create a sealed-file, which will block further
|
|
|
|
# resizing of the memory (default: true)
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
|
|
|
# Since: 2.12
|
|
|
|
##
|
|
|
|
{ 'struct': 'MemoryBackendMemfdProperties',
|
|
|
|
'base': 'MemoryBackendProperties',
|
|
|
|
'data': { '*hugetlb': 'bool',
|
|
|
|
'*hugetlbsize': 'size',
|
2024-06-04 16:59:31 +03:00
|
|
|
'*seal': 'bool' },
|
|
|
|
'if': 'CONFIG_LINUX' }
|
2020-10-20 13:47:58 +03:00
|
|
|
|
2024-06-18 13:05:19 +03:00
|
|
|
##
|
|
|
|
# @MemoryBackendShmProperties:
|
|
|
|
#
|
|
|
|
# Properties for memory-backend-shm objects.
|
|
|
|
#
|
|
|
|
# This memory backend supports only shared memory, which is the
|
|
|
|
# default.
|
|
|
|
#
|
|
|
|
# Since: 9.1
|
|
|
|
##
|
|
|
|
{ 'struct': 'MemoryBackendShmProperties',
|
|
|
|
'base': 'MemoryBackendProperties',
|
|
|
|
'data': { },
|
|
|
|
'if': 'CONFIG_POSIX' }
|
|
|
|
|
2021-07-19 14:21:06 +03:00
|
|
|
##
|
|
|
|
# @MemoryBackendEpcProperties:
|
|
|
|
#
|
|
|
|
# Properties for memory-backend-epc objects.
|
|
|
|
#
|
|
|
|
# The @merge boolean option is false by default with epc
|
|
|
|
#
|
|
|
|
# The @dump boolean option is false by default with epc
|
|
|
|
#
|
|
|
|
# Since: 6.2
|
|
|
|
##
|
|
|
|
{ 'struct': 'MemoryBackendEpcProperties',
|
|
|
|
'base': 'MemoryBackendProperties',
|
2024-06-04 16:59:31 +03:00
|
|
|
'data': {},
|
|
|
|
'if': 'CONFIG_LINUX' }
|
2021-07-19 14:21:06 +03:00
|
|
|
|
2020-10-20 13:47:58 +03:00
|
|
|
##
|
|
|
|
# @PrManagerHelperProperties:
|
|
|
|
#
|
|
|
|
# Properties for pr-manager-helper objects.
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @path: the path to a Unix domain socket for connecting to the
|
|
|
|
# external helper
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
|
|
|
# Since: 2.11
|
|
|
|
##
|
|
|
|
{ 'struct': 'PrManagerHelperProperties',
|
2024-06-04 16:59:31 +03:00
|
|
|
'data': { 'path': 'str' },
|
|
|
|
'if': 'CONFIG_LINUX' }
|
2020-10-20 13:47:58 +03:00
|
|
|
|
2020-11-09 18:13:30 +03:00
|
|
|
##
|
|
|
|
# @QtestProperties:
|
|
|
|
#
|
|
|
|
# Properties for qtest objects.
|
|
|
|
#
|
|
|
|
# @chardev: the chardev to be used to receive qtest commands on.
|
|
|
|
#
|
|
|
|
# @log: the path to a log file
|
|
|
|
#
|
|
|
|
# Since: 6.0
|
|
|
|
##
|
|
|
|
{ 'struct': 'QtestProperties',
|
|
|
|
'data': { 'chardev': 'str',
|
|
|
|
'*log': 'str' } }
|
|
|
|
|
2021-02-24 15:21:48 +03:00
|
|
|
##
|
|
|
|
# @RemoteObjectProperties:
|
|
|
|
#
|
|
|
|
# Properties for x-remote-object objects.
|
|
|
|
#
|
|
|
|
# @fd: file descriptor name previously passed via 'getfd' command
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @devid: the id of the device to be associated with the file
|
|
|
|
# descriptor
|
2021-02-24 15:21:48 +03:00
|
|
|
#
|
|
|
|
# Since: 6.0
|
|
|
|
##
|
|
|
|
{ 'struct': 'RemoteObjectProperties',
|
|
|
|
'data': { 'fd': 'str', 'devid': 'str' } }
|
|
|
|
|
2022-06-13 23:26:25 +03:00
|
|
|
##
|
|
|
|
# @VfioUserServerProperties:
|
|
|
|
#
|
|
|
|
# Properties for x-vfio-user-server objects.
|
|
|
|
#
|
|
|
|
# @socket: socket to be used by the libvfio-user library
|
|
|
|
#
|
|
|
|
# @device: the ID of the device to be emulated at the server
|
|
|
|
#
|
|
|
|
# Since: 7.1
|
|
|
|
##
|
|
|
|
{ 'struct': 'VfioUserServerProperties',
|
|
|
|
'data': { 'socket': 'SocketAddress', 'device': 'str' } }
|
|
|
|
|
2023-11-21 11:44:00 +03:00
|
|
|
##
|
|
|
|
# @IOMMUFDProperties:
|
|
|
|
#
|
|
|
|
# Properties for iommufd objects.
|
|
|
|
#
|
|
|
|
# @fd: file descriptor name previously passed via 'getfd' command,
|
|
|
|
# which represents a pre-opened /dev/iommu. This allows the
|
2024-03-31 19:15:26 +03:00
|
|
|
# iommufd object to be shared across several subsystems (VFIO,
|
2024-03-22 17:09:08 +03:00
|
|
|
# VDPA, ...), and the file descriptor to be shared with other
|
|
|
|
# process, e.g. DPDK. (default: QEMU opens /dev/iommu by itself)
|
2023-11-21 11:44:00 +03:00
|
|
|
#
|
|
|
|
# Since: 9.0
|
|
|
|
##
|
|
|
|
{ 'struct': 'IOMMUFDProperties',
|
|
|
|
'data': { '*fd': 'str' } }
|
|
|
|
|
qom: new object to associate device to NUMA node
NVIDIA GPU's support MIG (Mult-Instance GPUs) feature [1], which allows
partitioning of the GPU device resources (including device memory) into
several (upto 8) isolated instances. Each of the partitioned memory needs
a dedicated NUMA node to operate. The partitions are not fixed and they
can be created/deleted at runtime.
Unfortunately Linux OS does not provide a means to dynamically create/destroy
NUMA nodes and such feature implementation is not expected to be trivial. The
nodes that OS discovers at the boot time while parsing SRAT remains fixed. So
we utilize the Generic Initiator (GI) Affinity structures that allows
association between nodes and devices. Multiple GI structures per BDF is
possible, allowing creation of multiple nodes by exposing unique PXM in each
of these structures.
Implement the mechanism to build the GI affinity structures as Qemu currently
does not. Introduce a new acpi-generic-initiator object to allow host admin
link a device with an associated NUMA node. Qemu maintains this association
and use this object to build the requisite GI Affinity Structure.
When multiple NUMA nodes are associated with a device, it is required to
create those many number of acpi-generic-initiator objects, each representing
a unique device:node association.
Following is one of a decoded GI affinity structure in VM ACPI SRAT.
[0C8h 0200 1] Subtable Type : 05 [Generic Initiator Affinity]
[0C9h 0201 1] Length : 20
[0CAh 0202 1] Reserved1 : 00
[0CBh 0203 1] Device Handle Type : 01
[0CCh 0204 4] Proximity Domain : 00000007
[0D0h 0208 16] Device Handle : 00 00 20 00 00 00 00 00 00 00 00
00 00 00 00 00
[0E0h 0224 4] Flags (decoded below) : 00000001
Enabled : 1
[0E4h 0228 4] Reserved2 : 00000000
[0E8h 0232 1] Subtable Type : 05 [Generic Initiator Affinity]
[0E9h 0233 1] Length : 20
An admin can provide a range of acpi-generic-initiator objects, each
associating a device (by providing the id through pci-dev argument)
to the desired NUMA node (using the node argument). Currently, only PCI
device is supported.
For the grace hopper system, create a range of 8 nodes and associate that
with the device using the acpi-generic-initiator object. While a configuration
of less than 8 nodes per device is allowed, such configuration will prevent
utilization of the feature to the fullest. The following sample creates 8
nodes per PCI device for a VM with 2 PCI devices and link them to the
respecitve PCI device using acpi-generic-initiator objects:
-numa node,nodeid=2 -numa node,nodeid=3 -numa node,nodeid=4 \
-numa node,nodeid=5 -numa node,nodeid=6 -numa node,nodeid=7 \
-numa node,nodeid=8 -numa node,nodeid=9 \
-device vfio-pci-nohotplug,host=0009:01:00.0,bus=pcie.0,addr=04.0,rombar=0,id=dev0 \
-object acpi-generic-initiator,id=gi0,pci-dev=dev0,node=2 \
-object acpi-generic-initiator,id=gi1,pci-dev=dev0,node=3 \
-object acpi-generic-initiator,id=gi2,pci-dev=dev0,node=4 \
-object acpi-generic-initiator,id=gi3,pci-dev=dev0,node=5 \
-object acpi-generic-initiator,id=gi4,pci-dev=dev0,node=6 \
-object acpi-generic-initiator,id=gi5,pci-dev=dev0,node=7 \
-object acpi-generic-initiator,id=gi6,pci-dev=dev0,node=8 \
-object acpi-generic-initiator,id=gi7,pci-dev=dev0,node=9 \
-numa node,nodeid=10 -numa node,nodeid=11 -numa node,nodeid=12 \
-numa node,nodeid=13 -numa node,nodeid=14 -numa node,nodeid=15 \
-numa node,nodeid=16 -numa node,nodeid=17 \
-device vfio-pci-nohotplug,host=0009:01:01.0,bus=pcie.0,addr=05.0,rombar=0,id=dev1 \
-object acpi-generic-initiator,id=gi8,pci-dev=dev1,node=10 \
-object acpi-generic-initiator,id=gi9,pci-dev=dev1,node=11 \
-object acpi-generic-initiator,id=gi10,pci-dev=dev1,node=12 \
-object acpi-generic-initiator,id=gi11,pci-dev=dev1,node=13 \
-object acpi-generic-initiator,id=gi12,pci-dev=dev1,node=14 \
-object acpi-generic-initiator,id=gi13,pci-dev=dev1,node=15 \
-object acpi-generic-initiator,id=gi14,pci-dev=dev1,node=16 \
-object acpi-generic-initiator,id=gi15,pci-dev=dev1,node=17 \
Link: https://www.nvidia.com/en-in/technologies/multi-instance-gpu [1]
Cc: Jonathan Cameron <qemu-devel@nongnu.org>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Ankit Agrawal <ankita@nvidia.com>
Message-Id: <20240308145525.10886-2-ankita@nvidia.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-08 17:55:23 +03:00
|
|
|
##
|
|
|
|
# @AcpiGenericInitiatorProperties:
|
|
|
|
#
|
|
|
|
# Properties for acpi-generic-initiator objects.
|
|
|
|
#
|
|
|
|
# @pci-dev: PCI device ID to be associated with the node
|
|
|
|
#
|
|
|
|
# @node: NUMA node associated with the PCI device
|
|
|
|
#
|
|
|
|
# Since: 9.0
|
|
|
|
##
|
|
|
|
{ 'struct': 'AcpiGenericInitiatorProperties',
|
|
|
|
'data': { 'pci-dev': 'str',
|
|
|
|
'node': 'uint32' } }
|
|
|
|
|
2024-09-16 20:41:22 +03:00
|
|
|
##
|
|
|
|
# @AcpiGenericPortProperties:
|
|
|
|
#
|
|
|
|
# Properties for acpi-generic-port objects.
|
|
|
|
#
|
|
|
|
# @pci-bus: QOM path of the PCI bus of the hostbridge associated with
|
|
|
|
# this SRAT Generic Port Affinity Structure. This is the same as
|
|
|
|
# the bus parameter for the root ports attached to this host
|
|
|
|
# bridge. The resulting SRAT Generic Port Affinity Structure will
|
|
|
|
# refer to the ACPI object in DSDT that represents the host bridge
|
|
|
|
# (e.g. ACPI0016 for CXL host bridges). See ACPI 6.5 Section
|
|
|
|
# 5.2.16.7 for more information.
|
|
|
|
#
|
|
|
|
# @node: Similar to a NUMA node ID, but instead of providing a
|
|
|
|
# reference point used for defining NUMA distances and access
|
|
|
|
# characteristics to memory or from an initiator (e.g. CPU), this
|
|
|
|
# node defines the boundary point between non-discoverable system
|
|
|
|
# buses which must be described by firmware, and a discoverable
|
|
|
|
# bus. NUMA distances and access characteristics are defined to
|
|
|
|
# and from that point. For system software to establish full
|
|
|
|
# initiator to target characteristics this information must be
|
|
|
|
# combined with information retrieved from the discoverable part
|
|
|
|
# of the path. An example would use CDAT (see UEFI.org)
|
|
|
|
# information read from devices and switches in conjunction with
|
|
|
|
# link characteristics read from PCIe Configuration space.
|
|
|
|
# To get the full path latency from CPU to CXL attached DRAM
|
|
|
|
# CXL device: Add the latency from CPU to Generic Port (from
|
|
|
|
# HMAT indexed via the the node ID in this SRAT structure) to
|
|
|
|
# that for CXL bus links, the latency across intermediate switches
|
|
|
|
# and from the EP port to the actual memory. Bandwidth is more
|
|
|
|
# complex as there may be interleaving across multiple devices
|
|
|
|
# and shared links in the path.
|
|
|
|
#
|
|
|
|
# Since: 9.1
|
|
|
|
##
|
|
|
|
{ 'struct': 'AcpiGenericPortProperties',
|
|
|
|
'data': { 'pci-bus': 'str',
|
|
|
|
'node': 'uint32' } }
|
|
|
|
|
2020-10-20 13:47:58 +03:00
|
|
|
##
|
|
|
|
# @RngProperties:
|
|
|
|
#
|
|
|
|
# Properties for objects of classes derived from rng.
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @opened: if true, the device is opened immediately when applying
|
|
|
|
# this option and will probably fail when processing the next
|
|
|
|
# option. Don't use; only provided for compatibility.
|
|
|
|
# (default: false)
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
|
|
|
# Features:
|
2023-04-28 13:54:29 +03:00
|
|
|
#
|
|
|
|
# @deprecated: Member @opened is deprecated. Setting true doesn't
|
|
|
|
# make sense, and false is already the default.
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
|
|
|
# Since: 1.3
|
|
|
|
##
|
|
|
|
{ 'struct': 'RngProperties',
|
|
|
|
'data': { '*opened': { 'type': 'bool', 'features': ['deprecated'] } } }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @RngEgdProperties:
|
|
|
|
#
|
|
|
|
# Properties for rng-egd objects.
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @chardev: the name of a character device backend that provides the
|
|
|
|
# connection to the RNG daemon
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
|
|
|
# Since: 1.3
|
|
|
|
##
|
|
|
|
{ 'struct': 'RngEgdProperties',
|
|
|
|
'base': 'RngProperties',
|
|
|
|
'data': { 'chardev': 'str' } }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @RngRandomProperties:
|
|
|
|
#
|
|
|
|
# Properties for rng-random objects.
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @filename: the filename of the device on the host to obtain entropy
|
|
|
|
# from (default: "/dev/urandom")
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
|
|
|
# Since: 1.3
|
|
|
|
##
|
|
|
|
{ 'struct': 'RngRandomProperties',
|
|
|
|
'base': 'RngProperties',
|
2024-06-04 16:59:31 +03:00
|
|
|
'data': { '*filename': 'str' },
|
|
|
|
'if': 'CONFIG_POSIX' }
|
2020-10-20 13:47:58 +03:00
|
|
|
|
2020-10-20 13:47:58 +03:00
|
|
|
##
|
i386/sev: Introduce "sev-common" type to encapsulate common SEV state
Currently all SEV/SEV-ES functionality is managed through a single
'sev-guest' QOM type. With upcoming support for SEV-SNP, taking this
same approach won't work well since some of the properties/state
managed by 'sev-guest' is not applicable to SEV-SNP, which will instead
rely on a new QOM type with its own set of properties/state.
To prepare for this, this patch moves common state into an abstract
'sev-common' parent type to encapsulate properties/state that are
common to both SEV/SEV-ES and SEV-SNP, leaving only SEV/SEV-ES-specific
properties/state in the current 'sev-guest' type. This should not
affect current behavior or command-line options.
As part of this patch, some related changes are also made:
- a static 'sev_guest' variable is currently used to keep track of
the 'sev-guest' instance. SEV-SNP would similarly introduce an
'sev_snp_guest' static variable. But these instances are now
available via qdev_get_machine()->cgs, so switch to using that
instead and drop the static variable.
- 'sev_guest' is currently used as the name for the static variable
holding a pointer to the 'sev-guest' instance. Re-purpose the name
as a local variable referring the 'sev-guest' instance, and use
that consistently throughout the code so it can be easily
distinguished from sev-common/sev-snp-guest instances.
- 'sev' is generally used as the name for local variables holding a
pointer to the 'sev-guest' instance. In cases where that now points
to common state, use the name 'sev_common'; in cases where that now
points to state specific to 'sev-guest' instance, use the name
'sev_guest'
In order to enable kernel-hashes for SNP, pull it from
SevGuestProperties to its parent SevCommonProperties so
it will be available for both SEV and SNP.
Signed-off-by: Michael Roth <michael.roth@amd.com>
Co-developed-by: Dov Murik <dovmurik@linux.ibm.com>
Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
Acked-by: Markus Armbruster <armbru@redhat.com> (QAPI schema)
Co-developed-by: Pankaj Gupta <pankaj.gupta@amd.com>
Signed-off-by: Pankaj Gupta <pankaj.gupta@amd.com>
Message-ID: <20240530111643.1091816-5-pankaj.gupta@amd.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-05-30 14:16:16 +03:00
|
|
|
# @SevCommonProperties:
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
i386/sev: Introduce "sev-common" type to encapsulate common SEV state
Currently all SEV/SEV-ES functionality is managed through a single
'sev-guest' QOM type. With upcoming support for SEV-SNP, taking this
same approach won't work well since some of the properties/state
managed by 'sev-guest' is not applicable to SEV-SNP, which will instead
rely on a new QOM type with its own set of properties/state.
To prepare for this, this patch moves common state into an abstract
'sev-common' parent type to encapsulate properties/state that are
common to both SEV/SEV-ES and SEV-SNP, leaving only SEV/SEV-ES-specific
properties/state in the current 'sev-guest' type. This should not
affect current behavior or command-line options.
As part of this patch, some related changes are also made:
- a static 'sev_guest' variable is currently used to keep track of
the 'sev-guest' instance. SEV-SNP would similarly introduce an
'sev_snp_guest' static variable. But these instances are now
available via qdev_get_machine()->cgs, so switch to using that
instead and drop the static variable.
- 'sev_guest' is currently used as the name for the static variable
holding a pointer to the 'sev-guest' instance. Re-purpose the name
as a local variable referring the 'sev-guest' instance, and use
that consistently throughout the code so it can be easily
distinguished from sev-common/sev-snp-guest instances.
- 'sev' is generally used as the name for local variables holding a
pointer to the 'sev-guest' instance. In cases where that now points
to common state, use the name 'sev_common'; in cases where that now
points to state specific to 'sev-guest' instance, use the name
'sev_guest'
In order to enable kernel-hashes for SNP, pull it from
SevGuestProperties to its parent SevCommonProperties so
it will be available for both SEV and SNP.
Signed-off-by: Michael Roth <michael.roth@amd.com>
Co-developed-by: Dov Murik <dovmurik@linux.ibm.com>
Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
Acked-by: Markus Armbruster <armbru@redhat.com> (QAPI schema)
Co-developed-by: Pankaj Gupta <pankaj.gupta@amd.com>
Signed-off-by: Pankaj Gupta <pankaj.gupta@amd.com>
Message-ID: <20240530111643.1091816-5-pankaj.gupta@amd.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-05-30 14:16:16 +03:00
|
|
|
# Properties common to objects that are derivatives of sev-common.
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
|
|
|
# @sev-device: SEV device to use (default: "/dev/sev")
|
|
|
|
#
|
|
|
|
# @cbitpos: C-bit location in page table entry (default: 0)
|
|
|
|
#
|
|
|
|
# @reduced-phys-bits: number of bits in physical addresses that become
|
2023-04-28 13:54:29 +03:00
|
|
|
# unavailable when SEV is enabled
|
2020-10-20 13:47:58 +03:00
|
|
|
#
|
2021-11-11 13:00:43 +03:00
|
|
|
# @kernel-hashes: if true, add hashes of kernel/initrd/cmdline to a
|
2023-04-28 13:54:29 +03:00
|
|
|
# designated guest firmware page for measured boot with -kernel
|
|
|
|
# (default: false) (since 6.2)
|
2021-11-11 13:00:43 +03:00
|
|
|
#
|
i386/sev: Introduce "sev-common" type to encapsulate common SEV state
Currently all SEV/SEV-ES functionality is managed through a single
'sev-guest' QOM type. With upcoming support for SEV-SNP, taking this
same approach won't work well since some of the properties/state
managed by 'sev-guest' is not applicable to SEV-SNP, which will instead
rely on a new QOM type with its own set of properties/state.
To prepare for this, this patch moves common state into an abstract
'sev-common' parent type to encapsulate properties/state that are
common to both SEV/SEV-ES and SEV-SNP, leaving only SEV/SEV-ES-specific
properties/state in the current 'sev-guest' type. This should not
affect current behavior or command-line options.
As part of this patch, some related changes are also made:
- a static 'sev_guest' variable is currently used to keep track of
the 'sev-guest' instance. SEV-SNP would similarly introduce an
'sev_snp_guest' static variable. But these instances are now
available via qdev_get_machine()->cgs, so switch to using that
instead and drop the static variable.
- 'sev_guest' is currently used as the name for the static variable
holding a pointer to the 'sev-guest' instance. Re-purpose the name
as a local variable referring the 'sev-guest' instance, and use
that consistently throughout the code so it can be easily
distinguished from sev-common/sev-snp-guest instances.
- 'sev' is generally used as the name for local variables holding a
pointer to the 'sev-guest' instance. In cases where that now points
to common state, use the name 'sev_common'; in cases where that now
points to state specific to 'sev-guest' instance, use the name
'sev_guest'
In order to enable kernel-hashes for SNP, pull it from
SevGuestProperties to its parent SevCommonProperties so
it will be available for both SEV and SNP.
Signed-off-by: Michael Roth <michael.roth@amd.com>
Co-developed-by: Dov Murik <dovmurik@linux.ibm.com>
Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
Acked-by: Markus Armbruster <armbru@redhat.com> (QAPI schema)
Co-developed-by: Pankaj Gupta <pankaj.gupta@amd.com>
Signed-off-by: Pankaj Gupta <pankaj.gupta@amd.com>
Message-ID: <20240530111643.1091816-5-pankaj.gupta@amd.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-05-30 14:16:16 +03:00
|
|
|
# Since: 9.1
|
|
|
|
##
|
|
|
|
{ 'struct': 'SevCommonProperties',
|
|
|
|
'data': { '*sev-device': 'str',
|
|
|
|
'*cbitpos': 'uint32',
|
|
|
|
'reduced-phys-bits': 'uint32',
|
|
|
|
'*kernel-hashes': 'bool' } }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @SevGuestProperties:
|
|
|
|
#
|
|
|
|
# Properties for sev-guest objects.
|
|
|
|
#
|
|
|
|
# @dh-cert-file: guest owners DH certificate (encoded with base64)
|
|
|
|
#
|
|
|
|
# @session-file: guest owners session parameters (encoded with base64)
|
|
|
|
#
|
|
|
|
# @policy: SEV policy value (default: 0x1)
|
|
|
|
#
|
|
|
|
# @handle: SEV firmware handle (default: 0)
|
|
|
|
#
|
2024-07-29 09:52:20 +03:00
|
|
|
# @legacy-vm-type: Use legacy KVM_SEV_INIT KVM interface for creating
|
|
|
|
# the VM. The newer KVM_SEV_INIT2 interface, from Linux >= 6.10,
|
|
|
|
# syncs additional vCPU state when initializing the VMSA
|
|
|
|
# structures, which will result in a different guest measurement.
|
|
|
|
# Set this to 'on' to force compatibility with older QEMU or kernel
|
|
|
|
# versions that rely on legacy KVM_SEV_INIT behavior. 'auto' will
|
|
|
|
# behave identically to 'on', but will automatically switch to
|
|
|
|
# using KVM_SEV_INIT2 if the user specifies any additional options
|
|
|
|
# that require it. If set to 'off', QEMU will require
|
|
|
|
# KVM_SEV_INIT2 unconditionally.
|
|
|
|
# (default: off) (since 9.1)
|
i386/sev: Add 'legacy-vm-type' parameter for SEV guest objects
QEMU will currently automatically make use of the KVM_SEV_INIT2 API for
initializing SEV and SEV-ES guests verses the older
KVM_SEV_INIT/KVM_SEV_ES_INIT interfaces.
However, the older interfaces will silently avoid sync'ing FPU/XSAVE
state to the VMSA prior to encryption, thus relying on behavior and
measurements that assume the related fields to be allow zero.
With KVM_SEV_INIT2, this state is now synced into the VMSA, resulting in
measurements changes and, theoretically, behaviorial changes, though the
latter are unlikely to be seen in practice.
To allow a smooth transition to the newer interface, while still
providing a mechanism to maintain backward compatibility with VMs
created using the older interfaces, provide a new command-line
parameter:
-object sev-guest,legacy-vm-type=true,...
and have it default to false.
Signed-off-by: Michael Roth <michael.roth@amd.com>
Message-ID: <20240409230743.962513-2-michael.roth@amd.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-04-10 02:07:41 +03:00
|
|
|
#
|
2020-10-20 13:47:58 +03:00
|
|
|
# Since: 2.12
|
|
|
|
##
|
|
|
|
{ 'struct': 'SevGuestProperties',
|
i386/sev: Introduce "sev-common" type to encapsulate common SEV state
Currently all SEV/SEV-ES functionality is managed through a single
'sev-guest' QOM type. With upcoming support for SEV-SNP, taking this
same approach won't work well since some of the properties/state
managed by 'sev-guest' is not applicable to SEV-SNP, which will instead
rely on a new QOM type with its own set of properties/state.
To prepare for this, this patch moves common state into an abstract
'sev-common' parent type to encapsulate properties/state that are
common to both SEV/SEV-ES and SEV-SNP, leaving only SEV/SEV-ES-specific
properties/state in the current 'sev-guest' type. This should not
affect current behavior or command-line options.
As part of this patch, some related changes are also made:
- a static 'sev_guest' variable is currently used to keep track of
the 'sev-guest' instance. SEV-SNP would similarly introduce an
'sev_snp_guest' static variable. But these instances are now
available via qdev_get_machine()->cgs, so switch to using that
instead and drop the static variable.
- 'sev_guest' is currently used as the name for the static variable
holding a pointer to the 'sev-guest' instance. Re-purpose the name
as a local variable referring the 'sev-guest' instance, and use
that consistently throughout the code so it can be easily
distinguished from sev-common/sev-snp-guest instances.
- 'sev' is generally used as the name for local variables holding a
pointer to the 'sev-guest' instance. In cases where that now points
to common state, use the name 'sev_common'; in cases where that now
points to state specific to 'sev-guest' instance, use the name
'sev_guest'
In order to enable kernel-hashes for SNP, pull it from
SevGuestProperties to its parent SevCommonProperties so
it will be available for both SEV and SNP.
Signed-off-by: Michael Roth <michael.roth@amd.com>
Co-developed-by: Dov Murik <dovmurik@linux.ibm.com>
Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
Acked-by: Markus Armbruster <armbru@redhat.com> (QAPI schema)
Co-developed-by: Pankaj Gupta <pankaj.gupta@amd.com>
Signed-off-by: Pankaj Gupta <pankaj.gupta@amd.com>
Message-ID: <20240530111643.1091816-5-pankaj.gupta@amd.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-05-30 14:16:16 +03:00
|
|
|
'base': 'SevCommonProperties',
|
|
|
|
'data': { '*dh-cert-file': 'str',
|
2020-10-20 13:47:58 +03:00
|
|
|
'*session-file': 'str',
|
|
|
|
'*policy': 'uint32',
|
|
|
|
'*handle': 'uint32',
|
i386/sev: Don't allow automatic fallback to legacy KVM_SEV*_INIT
Currently if the 'legacy-vm-type' property of the sev-guest object is
'on', QEMU will attempt to use the newer KVM_SEV_INIT2 kernel
interface in conjunction with the newer KVM_X86_SEV_VM and
KVM_X86_SEV_ES_VM KVM VM types.
This can lead to measurement changes if, for instance, an SEV guest was
created on a host that originally had an older kernel that didn't
support KVM_SEV_INIT2, but is booted on the same host later on after the
host kernel was upgraded.
Instead, if legacy-vm-type is 'off', QEMU should fail if the
KVM_SEV_INIT2 interface is not provided by the current host kernel.
Modify the fallback handling accordingly.
In the future, VMSA features and other flags might be added to QEMU
which will require legacy-vm-type to be 'off' because they will rely
on the newer KVM_SEV_INIT2 interface. It may be difficult to convey to
users what values of legacy-vm-type are compatible with which
features/options, so as part of this rework, switch legacy-vm-type to a
tri-state OnOffAuto option. 'auto' in this case will automatically
switch to using the newer KVM_SEV_INIT2, but only if it is required to
make use of new VMSA features or other options only available via
KVM_SEV_INIT2.
Defining 'auto' in this way would avoid inadvertantly breaking
compatibility with older kernels since it would only be used in cases
where users opt into newer features that are only available via
KVM_SEV_INIT2 and newer kernels, and provide better default behavior
than the legacy-vm-type=off behavior that was previously in place, so
make it the default for 9.1+ machine types.
Cc: Daniel P. Berrangé <berrange@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
cc: kvm@vger.kernel.org
Signed-off-by: Michael Roth <michael.roth@amd.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Link: https://lore.kernel.org/r/20240710041005.83720-1-michael.roth@amd.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-07-10 07:10:05 +03:00
|
|
|
'*legacy-vm-type': 'OnOffAuto' } }
|
2020-10-20 13:47:58 +03:00
|
|
|
|
i386/sev: Introduce 'sev-snp-guest' object
SEV-SNP support relies on a different set of properties/state than the
existing 'sev-guest' object. This patch introduces the 'sev-snp-guest'
object, which can be used to configure an SEV-SNP guest. For example,
a default-configured SEV-SNP guest with no additional information
passed in for use with attestation:
-object sev-snp-guest,id=sev0
or a fully-specified SEV-SNP guest where all spec-defined binary
blobs are passed in as base64-encoded strings:
-object sev-snp-guest,id=sev0, \
policy=0x30000, \
init-flags=0, \
id-block=YWFhYWFhYWFhYWFhYWFhCg==, \
id-auth=CxHK/OKLkXGn/KpAC7Wl1FSiisWDbGTEKz..., \
author-key-enabled=on, \
host-data=LNkCWBRC5CcdGXirbNUV1OrsR28s..., \
guest-visible-workarounds=AA==, \
See the QAPI schema updates included in this patch for more usage
details.
In some cases these blobs may be up to 4096 characters, but this is
generally well below the default limit for linux hosts where
command-line sizes are defined by the sysconf-configurable ARG_MAX
value, which defaults to 2097152 characters for Ubuntu hosts, for
example.
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Co-developed-by: Michael Roth <michael.roth@amd.com>
Acked-by: Markus Armbruster <armbru@redhat.com> (for QAPI schema)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Co-developed-by: Pankaj Gupta <pankaj.gupta@amd.com>
Signed-off-by: Pankaj Gupta <pankaj.gupta@amd.com>
Message-ID: <20240530111643.1091816-8-pankaj.gupta@amd.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-05-30 14:16:19 +03:00
|
|
|
##
|
|
|
|
# @SevSnpGuestProperties:
|
|
|
|
#
|
|
|
|
# Properties for sev-snp-guest objects. Most of these are direct
|
|
|
|
# arguments for the KVM_SNP_* interfaces documented in the Linux
|
|
|
|
# kernel source under
|
|
|
|
# Documentation/arch/x86/amd-memory-encryption.rst, which are in turn
|
|
|
|
# closely coupled with the SNP_INIT/SNP_LAUNCH_* firmware commands
|
|
|
|
# documented in the SEV-SNP Firmware ABI Specification (Rev 0.9).
|
|
|
|
#
|
|
|
|
# More usage information is also available in the QEMU source tree
|
|
|
|
# under docs/amd-memory-encryption.
|
|
|
|
#
|
|
|
|
# @policy: the 'POLICY' parameter to the SNP_LAUNCH_START command, as
|
|
|
|
# defined in the SEV-SNP firmware ABI (default: 0x30000)
|
|
|
|
#
|
|
|
|
# @guest-visible-workarounds: 16-byte, base64-encoded blob to report
|
|
|
|
# hypervisor-defined workarounds, corresponding to the 'GOSVW'
|
|
|
|
# parameter of the SNP_LAUNCH_START command defined in the SEV-SNP
|
|
|
|
# firmware ABI (default: all-zero)
|
|
|
|
#
|
|
|
|
# @id-block: 96-byte, base64-encoded blob to provide the 'ID Block'
|
|
|
|
# structure for the SNP_LAUNCH_FINISH command defined in the
|
|
|
|
# SEV-SNP firmware ABI (default: all-zero)
|
|
|
|
#
|
|
|
|
# @id-auth: 4096-byte, base64-encoded blob to provide the 'ID
|
|
|
|
# Authentication Information Structure' for the SNP_LAUNCH_FINISH
|
|
|
|
# command defined in the SEV-SNP firmware ABI (default: all-zero)
|
|
|
|
#
|
|
|
|
# @author-key-enabled: true if 'id-auth' blob contains the 'AUTHOR_KEY'
|
|
|
|
# field defined SEV-SNP firmware ABI (default: false)
|
|
|
|
#
|
|
|
|
# @host-data: 32-byte, base64-encoded, user-defined blob to provide to
|
|
|
|
# the guest, as documented for the 'HOST_DATA' parameter of the
|
|
|
|
# SNP_LAUNCH_FINISH command in the SEV-SNP firmware ABI (default:
|
|
|
|
# all-zero)
|
|
|
|
#
|
|
|
|
# @vcek-disabled: Guests are by default allowed to choose between VLEK
|
|
|
|
# (Versioned Loaded Endorsement Key) or VCEK (Versioned Chip
|
|
|
|
# Endorsement Key) when requesting attestation reports from
|
2024-07-29 09:52:20 +03:00
|
|
|
# firmware. Set this to true to disable the use of VCEK.
|
i386/sev: Introduce 'sev-snp-guest' object
SEV-SNP support relies on a different set of properties/state than the
existing 'sev-guest' object. This patch introduces the 'sev-snp-guest'
object, which can be used to configure an SEV-SNP guest. For example,
a default-configured SEV-SNP guest with no additional information
passed in for use with attestation:
-object sev-snp-guest,id=sev0
or a fully-specified SEV-SNP guest where all spec-defined binary
blobs are passed in as base64-encoded strings:
-object sev-snp-guest,id=sev0, \
policy=0x30000, \
init-flags=0, \
id-block=YWFhYWFhYWFhYWFhYWFhCg==, \
id-auth=CxHK/OKLkXGn/KpAC7Wl1FSiisWDbGTEKz..., \
author-key-enabled=on, \
host-data=LNkCWBRC5CcdGXirbNUV1OrsR28s..., \
guest-visible-workarounds=AA==, \
See the QAPI schema updates included in this patch for more usage
details.
In some cases these blobs may be up to 4096 characters, but this is
generally well below the default limit for linux hosts where
command-line sizes are defined by the sysconf-configurable ARG_MAX
value, which defaults to 2097152 characters for Ubuntu hosts, for
example.
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Co-developed-by: Michael Roth <michael.roth@amd.com>
Acked-by: Markus Armbruster <armbru@redhat.com> (for QAPI schema)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Co-developed-by: Pankaj Gupta <pankaj.gupta@amd.com>
Signed-off-by: Pankaj Gupta <pankaj.gupta@amd.com>
Message-ID: <20240530111643.1091816-8-pankaj.gupta@amd.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-05-30 14:16:19 +03:00
|
|
|
# (default: false) (since: 9.1)
|
|
|
|
#
|
|
|
|
# Since: 9.1
|
|
|
|
##
|
|
|
|
{ 'struct': 'SevSnpGuestProperties',
|
|
|
|
'base': 'SevCommonProperties',
|
|
|
|
'data': {
|
|
|
|
'*policy': 'uint64',
|
|
|
|
'*guest-visible-workarounds': 'str',
|
|
|
|
'*id-block': 'str',
|
|
|
|
'*id-auth': 'str',
|
|
|
|
'*author-key-enabled': 'bool',
|
|
|
|
'*host-data': 'str',
|
|
|
|
'*vcek-disabled': 'bool' } }
|
|
|
|
|
util: Introduce ThreadContext user-creatable object
Setting the CPU affinity of QEMU threads is a bit problematic, because
QEMU doesn't always have permissions to set the CPU affinity itself,
for example, with seccomp after initialized by QEMU:
-sandbox enable=on,resourcecontrol=deny
General information about CPU affinities can be found in the man page of
taskset:
CPU affinity is a scheduler property that "bonds" a process to a given
set of CPUs on the system. The Linux scheduler will honor the given CPU
affinity and the process will not run on any other CPUs.
While upper layers are already aware of how to handle CPU affinities for
long-lived threads like iothreads or vcpu threads, especially short-lived
threads, as used for memory-backend preallocation, are more involved to
handle. These threads are created on demand and upper layers are not even
able to identify and configure them.
Introduce the concept of a ThreadContext, that is essentially a thread
used for creating new threads. All threads created via that context
thread inherit the configured CPU affinity. Consequently, it's
sufficient to create a ThreadContext and configure it once, and have all
threads created via that ThreadContext inherit the same CPU affinity.
The CPU affinity of a ThreadContext can be configured two ways:
(1) Obtaining the thread id via the "thread-id" property and setting the
CPU affinity manually (e.g., via taskset).
(2) Setting the "cpu-affinity" property and letting QEMU try set the
CPU affinity itself. This will fail if QEMU doesn't have permissions
to do so anymore after seccomp was initialized.
A simple QEMU example to set the CPU affinity to host CPU 0,1,6,7 would be:
qemu-system-x86_64 -S \
-object thread-context,id=tc1,cpu-affinity=0-1,cpu-affinity=6-7
And we can query it via HMP/QMP:
(qemu) qom-get tc1 cpu-affinity
[
0,
1,
6,
7
]
But note that due to dynamic library loading this example will not work
before we actually make use of thread_context_create_thread() in QEMU
code, because the type will otherwise not get registered. We'll wire
this up next to make it work.
In general, the interface behaves like pthread_setaffinity_np(): host
CPU numbers that are currently not available are ignored; only host CPU
numbers that are impossible with the current kernel will fail. If the
list of host CPU numbers does not include a single CPU that is
available, setting the CPU affinity will fail.
A ThreadContext can be reused, simply by reconfiguring the CPU affinity.
Note that the CPU affinity of previously created threads will not get
adjusted.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20221014134720.168738-4-david@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
2022-10-14 16:47:16 +03:00
|
|
|
##
|
|
|
|
# @ThreadContextProperties:
|
|
|
|
#
|
|
|
|
# Properties for thread context objects.
|
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @cpu-affinity: the list of host CPU numbers used as CPU affinity for
|
|
|
|
# all threads created in the thread context (default: QEMU main
|
|
|
|
# thread CPU affinity)
|
util: Introduce ThreadContext user-creatable object
Setting the CPU affinity of QEMU threads is a bit problematic, because
QEMU doesn't always have permissions to set the CPU affinity itself,
for example, with seccomp after initialized by QEMU:
-sandbox enable=on,resourcecontrol=deny
General information about CPU affinities can be found in the man page of
taskset:
CPU affinity is a scheduler property that "bonds" a process to a given
set of CPUs on the system. The Linux scheduler will honor the given CPU
affinity and the process will not run on any other CPUs.
While upper layers are already aware of how to handle CPU affinities for
long-lived threads like iothreads or vcpu threads, especially short-lived
threads, as used for memory-backend preallocation, are more involved to
handle. These threads are created on demand and upper layers are not even
able to identify and configure them.
Introduce the concept of a ThreadContext, that is essentially a thread
used for creating new threads. All threads created via that context
thread inherit the configured CPU affinity. Consequently, it's
sufficient to create a ThreadContext and configure it once, and have all
threads created via that ThreadContext inherit the same CPU affinity.
The CPU affinity of a ThreadContext can be configured two ways:
(1) Obtaining the thread id via the "thread-id" property and setting the
CPU affinity manually (e.g., via taskset).
(2) Setting the "cpu-affinity" property and letting QEMU try set the
CPU affinity itself. This will fail if QEMU doesn't have permissions
to do so anymore after seccomp was initialized.
A simple QEMU example to set the CPU affinity to host CPU 0,1,6,7 would be:
qemu-system-x86_64 -S \
-object thread-context,id=tc1,cpu-affinity=0-1,cpu-affinity=6-7
And we can query it via HMP/QMP:
(qemu) qom-get tc1 cpu-affinity
[
0,
1,
6,
7
]
But note that due to dynamic library loading this example will not work
before we actually make use of thread_context_create_thread() in QEMU
code, because the type will otherwise not get registered. We'll wire
this up next to make it work.
In general, the interface behaves like pthread_setaffinity_np(): host
CPU numbers that are currently not available are ignored; only host CPU
numbers that are impossible with the current kernel will fail. If the
list of host CPU numbers does not include a single CPU that is
available, setting the CPU affinity will fail.
A ThreadContext can be reused, simply by reconfiguring the CPU affinity.
Note that the CPU affinity of previously created threads will not get
adjusted.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20221014134720.168738-4-david@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
2022-10-14 16:47:16 +03:00
|
|
|
#
|
2023-04-28 13:54:29 +03:00
|
|
|
# @node-affinity: the list of host node numbers that will be resolved
|
|
|
|
# to a list of host CPU numbers used as CPU affinity. This is a
|
|
|
|
# shortcut for specifying the list of host CPU numbers belonging
|
|
|
|
# to the host nodes manually by setting @cpu-affinity.
|
|
|
|
# (default: QEMU main thread affinity)
|
util: Add write-only "node-affinity" property for ThreadContext
Let's make it easier to pin threads created via a ThreadContext to
all host CPUs currently belonging to a given set of host NUMA nodes --
which is the common case.
"node-affinity" is simply a shortcut for setting "cpu-affinity" manually
to the list of host CPUs belonging to the set of host nodes. This property
can only be written.
A simple QEMU example to set the CPU affinity to host node 1 on a system
with two nodes, 24 CPUs each, whereby odd-numbered host CPUs belong to
host node 1:
qemu-system-x86_64 -S \
-object thread-context,id=tc1,node-affinity=1
And we can query the cpu-affinity via HMP/QMP:
(qemu) qom-get tc1 cpu-affinity
[
1,
3,
5,
7,
9,
11,
13,
15,
17,
19,
21,
23,
25,
27,
29,
31,
33,
35,
37,
39,
41,
43,
45,
47
]
We cannot query the node-affinity:
(qemu) qom-get tc1 node-affinity
Error: Insufficient permission to perform this operation
But note that due to dynamic library loading this example will not work
before we actually make use of thread_context_create_thread() in QEMU
code, because the type will otherwise not get registered. We'll wire
this up next to make it work.
Note that if the host CPUs for a host node change due do CPU hot(un)plug
CPU onlining/offlining (i.e., lscpu output changes) after the ThreadContext
was started, the CPU affinity will not get updated.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20221014134720.168738-5-david@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
2022-10-14 16:47:17 +03:00
|
|
|
#
|
util: Introduce ThreadContext user-creatable object
Setting the CPU affinity of QEMU threads is a bit problematic, because
QEMU doesn't always have permissions to set the CPU affinity itself,
for example, with seccomp after initialized by QEMU:
-sandbox enable=on,resourcecontrol=deny
General information about CPU affinities can be found in the man page of
taskset:
CPU affinity is a scheduler property that "bonds" a process to a given
set of CPUs on the system. The Linux scheduler will honor the given CPU
affinity and the process will not run on any other CPUs.
While upper layers are already aware of how to handle CPU affinities for
long-lived threads like iothreads or vcpu threads, especially short-lived
threads, as used for memory-backend preallocation, are more involved to
handle. These threads are created on demand and upper layers are not even
able to identify and configure them.
Introduce the concept of a ThreadContext, that is essentially a thread
used for creating new threads. All threads created via that context
thread inherit the configured CPU affinity. Consequently, it's
sufficient to create a ThreadContext and configure it once, and have all
threads created via that ThreadContext inherit the same CPU affinity.
The CPU affinity of a ThreadContext can be configured two ways:
(1) Obtaining the thread id via the "thread-id" property and setting the
CPU affinity manually (e.g., via taskset).
(2) Setting the "cpu-affinity" property and letting QEMU try set the
CPU affinity itself. This will fail if QEMU doesn't have permissions
to do so anymore after seccomp was initialized.
A simple QEMU example to set the CPU affinity to host CPU 0,1,6,7 would be:
qemu-system-x86_64 -S \
-object thread-context,id=tc1,cpu-affinity=0-1,cpu-affinity=6-7
And we can query it via HMP/QMP:
(qemu) qom-get tc1 cpu-affinity
[
0,
1,
6,
7
]
But note that due to dynamic library loading this example will not work
before we actually make use of thread_context_create_thread() in QEMU
code, because the type will otherwise not get registered. We'll wire
this up next to make it work.
In general, the interface behaves like pthread_setaffinity_np(): host
CPU numbers that are currently not available are ignored; only host CPU
numbers that are impossible with the current kernel will fail. If the
list of host CPU numbers does not include a single CPU that is
available, setting the CPU affinity will fail.
A ThreadContext can be reused, simply by reconfiguring the CPU affinity.
Note that the CPU affinity of previously created threads will not get
adjusted.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20221014134720.168738-4-david@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
2022-10-14 16:47:16 +03:00
|
|
|
# Since: 7.2
|
|
|
|
##
|
|
|
|
{ 'struct': 'ThreadContextProperties',
|
util: Add write-only "node-affinity" property for ThreadContext
Let's make it easier to pin threads created via a ThreadContext to
all host CPUs currently belonging to a given set of host NUMA nodes --
which is the common case.
"node-affinity" is simply a shortcut for setting "cpu-affinity" manually
to the list of host CPUs belonging to the set of host nodes. This property
can only be written.
A simple QEMU example to set the CPU affinity to host node 1 on a system
with two nodes, 24 CPUs each, whereby odd-numbered host CPUs belong to
host node 1:
qemu-system-x86_64 -S \
-object thread-context,id=tc1,node-affinity=1
And we can query the cpu-affinity via HMP/QMP:
(qemu) qom-get tc1 cpu-affinity
[
1,
3,
5,
7,
9,
11,
13,
15,
17,
19,
21,
23,
25,
27,
29,
31,
33,
35,
37,
39,
41,
43,
45,
47
]
We cannot query the node-affinity:
(qemu) qom-get tc1 node-affinity
Error: Insufficient permission to perform this operation
But note that due to dynamic library loading this example will not work
before we actually make use of thread_context_create_thread() in QEMU
code, because the type will otherwise not get registered. We'll wire
this up next to make it work.
Note that if the host CPUs for a host node change due do CPU hot(un)plug
CPU onlining/offlining (i.e., lscpu output changes) after the ThreadContext
was started, the CPU affinity will not get updated.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20221014134720.168738-5-david@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
2022-10-14 16:47:17 +03:00
|
|
|
'data': { '*cpu-affinity': ['uint16'],
|
|
|
|
'*node-affinity': ['uint16'] } }
|
util: Introduce ThreadContext user-creatable object
Setting the CPU affinity of QEMU threads is a bit problematic, because
QEMU doesn't always have permissions to set the CPU affinity itself,
for example, with seccomp after initialized by QEMU:
-sandbox enable=on,resourcecontrol=deny
General information about CPU affinities can be found in the man page of
taskset:
CPU affinity is a scheduler property that "bonds" a process to a given
set of CPUs on the system. The Linux scheduler will honor the given CPU
affinity and the process will not run on any other CPUs.
While upper layers are already aware of how to handle CPU affinities for
long-lived threads like iothreads or vcpu threads, especially short-lived
threads, as used for memory-backend preallocation, are more involved to
handle. These threads are created on demand and upper layers are not even
able to identify and configure them.
Introduce the concept of a ThreadContext, that is essentially a thread
used for creating new threads. All threads created via that context
thread inherit the configured CPU affinity. Consequently, it's
sufficient to create a ThreadContext and configure it once, and have all
threads created via that ThreadContext inherit the same CPU affinity.
The CPU affinity of a ThreadContext can be configured two ways:
(1) Obtaining the thread id via the "thread-id" property and setting the
CPU affinity manually (e.g., via taskset).
(2) Setting the "cpu-affinity" property and letting QEMU try set the
CPU affinity itself. This will fail if QEMU doesn't have permissions
to do so anymore after seccomp was initialized.
A simple QEMU example to set the CPU affinity to host CPU 0,1,6,7 would be:
qemu-system-x86_64 -S \
-object thread-context,id=tc1,cpu-affinity=0-1,cpu-affinity=6-7
And we can query it via HMP/QMP:
(qemu) qom-get tc1 cpu-affinity
[
0,
1,
6,
7
]
But note that due to dynamic library loading this example will not work
before we actually make use of thread_context_create_thread() in QEMU
code, because the type will otherwise not get registered. We'll wire
this up next to make it work.
In general, the interface behaves like pthread_setaffinity_np(): host
CPU numbers that are currently not available are ignored; only host CPU
numbers that are impossible with the current kernel will fail. If the
list of host CPU numbers does not include a single CPU that is
available, setting the CPU affinity will fail.
A ThreadContext can be reused, simply by reconfiguring the CPU affinity.
Note that the CPU affinity of previously created threads will not get
adjusted.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20221014134720.168738-4-david@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
2022-10-14 16:47:16 +03:00
|
|
|
|
|
|
|
|
2020-10-20 13:47:58 +03:00
|
|
|
##
|
|
|
|
# @ObjectType:
|
|
|
|
#
|
2021-10-28 13:25:13 +03:00
|
|
|
# Features:
|
2023-04-28 13:54:29 +03:00
|
|
|
#
|
2024-07-03 12:53:10 +03:00
|
|
|
# @unstable: Members @x-remote-object and @x-vfio-user-server are
|
|
|
|
# experimental.
|
2021-10-28 13:25:13 +03:00
|
|
|
#
|
2020-10-20 13:47:58 +03:00
|
|
|
# Since: 6.0
|
|
|
|
##
|
|
|
|
{ 'enum': 'ObjectType',
|
|
|
|
'data': [
|
qom: new object to associate device to NUMA node
NVIDIA GPU's support MIG (Mult-Instance GPUs) feature [1], which allows
partitioning of the GPU device resources (including device memory) into
several (upto 8) isolated instances. Each of the partitioned memory needs
a dedicated NUMA node to operate. The partitions are not fixed and they
can be created/deleted at runtime.
Unfortunately Linux OS does not provide a means to dynamically create/destroy
NUMA nodes and such feature implementation is not expected to be trivial. The
nodes that OS discovers at the boot time while parsing SRAT remains fixed. So
we utilize the Generic Initiator (GI) Affinity structures that allows
association between nodes and devices. Multiple GI structures per BDF is
possible, allowing creation of multiple nodes by exposing unique PXM in each
of these structures.
Implement the mechanism to build the GI affinity structures as Qemu currently
does not. Introduce a new acpi-generic-initiator object to allow host admin
link a device with an associated NUMA node. Qemu maintains this association
and use this object to build the requisite GI Affinity Structure.
When multiple NUMA nodes are associated with a device, it is required to
create those many number of acpi-generic-initiator objects, each representing
a unique device:node association.
Following is one of a decoded GI affinity structure in VM ACPI SRAT.
[0C8h 0200 1] Subtable Type : 05 [Generic Initiator Affinity]
[0C9h 0201 1] Length : 20
[0CAh 0202 1] Reserved1 : 00
[0CBh 0203 1] Device Handle Type : 01
[0CCh 0204 4] Proximity Domain : 00000007
[0D0h 0208 16] Device Handle : 00 00 20 00 00 00 00 00 00 00 00
00 00 00 00 00
[0E0h 0224 4] Flags (decoded below) : 00000001
Enabled : 1
[0E4h 0228 4] Reserved2 : 00000000
[0E8h 0232 1] Subtable Type : 05 [Generic Initiator Affinity]
[0E9h 0233 1] Length : 20
An admin can provide a range of acpi-generic-initiator objects, each
associating a device (by providing the id through pci-dev argument)
to the desired NUMA node (using the node argument). Currently, only PCI
device is supported.
For the grace hopper system, create a range of 8 nodes and associate that
with the device using the acpi-generic-initiator object. While a configuration
of less than 8 nodes per device is allowed, such configuration will prevent
utilization of the feature to the fullest. The following sample creates 8
nodes per PCI device for a VM with 2 PCI devices and link them to the
respecitve PCI device using acpi-generic-initiator objects:
-numa node,nodeid=2 -numa node,nodeid=3 -numa node,nodeid=4 \
-numa node,nodeid=5 -numa node,nodeid=6 -numa node,nodeid=7 \
-numa node,nodeid=8 -numa node,nodeid=9 \
-device vfio-pci-nohotplug,host=0009:01:00.0,bus=pcie.0,addr=04.0,rombar=0,id=dev0 \
-object acpi-generic-initiator,id=gi0,pci-dev=dev0,node=2 \
-object acpi-generic-initiator,id=gi1,pci-dev=dev0,node=3 \
-object acpi-generic-initiator,id=gi2,pci-dev=dev0,node=4 \
-object acpi-generic-initiator,id=gi3,pci-dev=dev0,node=5 \
-object acpi-generic-initiator,id=gi4,pci-dev=dev0,node=6 \
-object acpi-generic-initiator,id=gi5,pci-dev=dev0,node=7 \
-object acpi-generic-initiator,id=gi6,pci-dev=dev0,node=8 \
-object acpi-generic-initiator,id=gi7,pci-dev=dev0,node=9 \
-numa node,nodeid=10 -numa node,nodeid=11 -numa node,nodeid=12 \
-numa node,nodeid=13 -numa node,nodeid=14 -numa node,nodeid=15 \
-numa node,nodeid=16 -numa node,nodeid=17 \
-device vfio-pci-nohotplug,host=0009:01:01.0,bus=pcie.0,addr=05.0,rombar=0,id=dev1 \
-object acpi-generic-initiator,id=gi8,pci-dev=dev1,node=10 \
-object acpi-generic-initiator,id=gi9,pci-dev=dev1,node=11 \
-object acpi-generic-initiator,id=gi10,pci-dev=dev1,node=12 \
-object acpi-generic-initiator,id=gi11,pci-dev=dev1,node=13 \
-object acpi-generic-initiator,id=gi12,pci-dev=dev1,node=14 \
-object acpi-generic-initiator,id=gi13,pci-dev=dev1,node=15 \
-object acpi-generic-initiator,id=gi14,pci-dev=dev1,node=16 \
-object acpi-generic-initiator,id=gi15,pci-dev=dev1,node=17 \
Link: https://www.nvidia.com/en-in/technologies/multi-instance-gpu [1]
Cc: Jonathan Cameron <qemu-devel@nongnu.org>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Ankit Agrawal <ankita@nvidia.com>
Message-Id: <20240308145525.10886-2-ankita@nvidia.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-08 17:55:23 +03:00
|
|
|
'acpi-generic-initiator',
|
2024-09-16 20:41:22 +03:00
|
|
|
'acpi-generic-port',
|
2020-10-20 13:47:58 +03:00
|
|
|
'authz-list',
|
|
|
|
'authz-listfile',
|
|
|
|
'authz-pam',
|
|
|
|
'authz-simple',
|
2020-10-20 13:47:58 +03:00
|
|
|
'can-bus',
|
2021-09-28 19:02:32 +03:00
|
|
|
{ 'name': 'can-host-socketcan',
|
|
|
|
'if': 'CONFIG_LINUX' },
|
2020-10-20 13:47:58 +03:00
|
|
|
'colo-compare',
|
2020-10-20 13:47:58 +03:00
|
|
|
'cryptodev-backend',
|
|
|
|
'cryptodev-backend-builtin',
|
2022-10-08 11:50:30 +03:00
|
|
|
'cryptodev-backend-lkcf',
|
2020-10-20 13:47:58 +03:00
|
|
|
{ 'name': 'cryptodev-vhost-user',
|
2021-08-04 11:31:05 +03:00
|
|
|
'if': 'CONFIG_VHOST_CRYPTO' },
|
2020-10-20 13:47:58 +03:00
|
|
|
'dbus-vmstate',
|
2020-10-20 13:47:58 +03:00
|
|
|
'filter-buffer',
|
|
|
|
'filter-dump',
|
|
|
|
'filter-mirror',
|
|
|
|
'filter-redirector',
|
|
|
|
'filter-replay',
|
|
|
|
'filter-rewriter',
|
2020-10-20 13:47:58 +03:00
|
|
|
'input-barrier',
|
2021-09-28 19:02:32 +03:00
|
|
|
{ 'name': 'input-linux',
|
|
|
|
'if': 'CONFIG_LINUX' },
|
2023-11-21 11:44:00 +03:00
|
|
|
'iommufd',
|
2020-10-20 13:47:58 +03:00
|
|
|
'iothread',
|
2022-04-25 10:57:22 +03:00
|
|
|
'main-loop',
|
2021-09-28 19:02:32 +03:00
|
|
|
{ 'name': 'memory-backend-epc',
|
|
|
|
'if': 'CONFIG_LINUX' },
|
2020-10-20 13:47:58 +03:00
|
|
|
'memory-backend-file',
|
|
|
|
{ 'name': 'memory-backend-memfd',
|
2021-08-04 11:31:05 +03:00
|
|
|
'if': 'CONFIG_LINUX' },
|
2020-10-20 13:47:58 +03:00
|
|
|
'memory-backend-ram',
|
2024-06-18 13:05:19 +03:00
|
|
|
{ 'name': 'memory-backend-shm',
|
|
|
|
'if': 'CONFIG_POSIX' },
|
2021-03-26 11:48:39 +03:00
|
|
|
'pef-guest',
|
2021-09-28 19:02:32 +03:00
|
|
|
{ 'name': 'pr-manager-helper',
|
|
|
|
'if': 'CONFIG_LINUX' },
|
2020-11-09 18:13:30 +03:00
|
|
|
'qtest',
|
2020-10-20 13:47:58 +03:00
|
|
|
'rng-builtin',
|
|
|
|
'rng-egd',
|
2021-09-28 19:02:32 +03:00
|
|
|
{ 'name': 'rng-random',
|
|
|
|
'if': 'CONFIG_POSIX' },
|
2020-10-20 13:47:58 +03:00
|
|
|
'secret',
|
2021-09-28 19:02:32 +03:00
|
|
|
{ 'name': 'secret_keyring',
|
|
|
|
'if': 'CONFIG_SECRET_KEYRING' },
|
2021-03-26 11:48:39 +03:00
|
|
|
'sev-guest',
|
i386/sev: Introduce 'sev-snp-guest' object
SEV-SNP support relies on a different set of properties/state than the
existing 'sev-guest' object. This patch introduces the 'sev-snp-guest'
object, which can be used to configure an SEV-SNP guest. For example,
a default-configured SEV-SNP guest with no additional information
passed in for use with attestation:
-object sev-snp-guest,id=sev0
or a fully-specified SEV-SNP guest where all spec-defined binary
blobs are passed in as base64-encoded strings:
-object sev-snp-guest,id=sev0, \
policy=0x30000, \
init-flags=0, \
id-block=YWFhYWFhYWFhYWFhYWFhCg==, \
id-auth=CxHK/OKLkXGn/KpAC7Wl1FSiisWDbGTEKz..., \
author-key-enabled=on, \
host-data=LNkCWBRC5CcdGXirbNUV1OrsR28s..., \
guest-visible-workarounds=AA==, \
See the QAPI schema updates included in this patch for more usage
details.
In some cases these blobs may be up to 4096 characters, but this is
generally well below the default limit for linux hosts where
command-line sizes are defined by the sysconf-configurable ARG_MAX
value, which defaults to 2097152 characters for Ubuntu hosts, for
example.
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Co-developed-by: Michael Roth <michael.roth@amd.com>
Acked-by: Markus Armbruster <armbru@redhat.com> (for QAPI schema)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Co-developed-by: Pankaj Gupta <pankaj.gupta@amd.com>
Signed-off-by: Pankaj Gupta <pankaj.gupta@amd.com>
Message-ID: <20240530111643.1091816-8-pankaj.gupta@amd.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-05-30 14:16:19 +03:00
|
|
|
'sev-snp-guest',
|
util: Introduce ThreadContext user-creatable object
Setting the CPU affinity of QEMU threads is a bit problematic, because
QEMU doesn't always have permissions to set the CPU affinity itself,
for example, with seccomp after initialized by QEMU:
-sandbox enable=on,resourcecontrol=deny
General information about CPU affinities can be found in the man page of
taskset:
CPU affinity is a scheduler property that "bonds" a process to a given
set of CPUs on the system. The Linux scheduler will honor the given CPU
affinity and the process will not run on any other CPUs.
While upper layers are already aware of how to handle CPU affinities for
long-lived threads like iothreads or vcpu threads, especially short-lived
threads, as used for memory-backend preallocation, are more involved to
handle. These threads are created on demand and upper layers are not even
able to identify and configure them.
Introduce the concept of a ThreadContext, that is essentially a thread
used for creating new threads. All threads created via that context
thread inherit the configured CPU affinity. Consequently, it's
sufficient to create a ThreadContext and configure it once, and have all
threads created via that ThreadContext inherit the same CPU affinity.
The CPU affinity of a ThreadContext can be configured two ways:
(1) Obtaining the thread id via the "thread-id" property and setting the
CPU affinity manually (e.g., via taskset).
(2) Setting the "cpu-affinity" property and letting QEMU try set the
CPU affinity itself. This will fail if QEMU doesn't have permissions
to do so anymore after seccomp was initialized.
A simple QEMU example to set the CPU affinity to host CPU 0,1,6,7 would be:
qemu-system-x86_64 -S \
-object thread-context,id=tc1,cpu-affinity=0-1,cpu-affinity=6-7
And we can query it via HMP/QMP:
(qemu) qom-get tc1 cpu-affinity
[
0,
1,
6,
7
]
But note that due to dynamic library loading this example will not work
before we actually make use of thread_context_create_thread() in QEMU
code, because the type will otherwise not get registered. We'll wire
this up next to make it work.
In general, the interface behaves like pthread_setaffinity_np(): host
CPU numbers that are currently not available are ignored; only host CPU
numbers that are impossible with the current kernel will fail. If the
list of host CPU numbers does not include a single CPU that is
available, setting the CPU affinity will fail.
A ThreadContext can be reused, simply by reconfiguring the CPU affinity.
Note that the CPU affinity of previously created threads will not get
adjusted.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20221014134720.168738-4-david@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
2022-10-14 16:47:16 +03:00
|
|
|
'thread-context',
|
2020-10-20 13:47:58 +03:00
|
|
|
's390-pv-guest',
|
2020-10-20 13:47:58 +03:00
|
|
|
'throttle-group',
|
|
|
|
'tls-creds-anon',
|
|
|
|
'tls-creds-psk',
|
|
|
|
'tls-creds-x509',
|
2021-02-24 15:21:48 +03:00
|
|
|
'tls-cipher-suites',
|
2022-06-13 23:26:25 +03:00
|
|
|
{ 'name': 'x-remote-object', 'features': [ 'unstable' ] },
|
|
|
|
{ 'name': 'x-vfio-user-server', 'features': [ 'unstable' ] }
|
2020-10-20 13:47:58 +03:00
|
|
|
] }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @ObjectOptions:
|
|
|
|
#
|
|
|
|
# Describes the options of a user creatable QOM object.
|
|
|
|
#
|
|
|
|
# @qom-type: the class name for the object to be created
|
|
|
|
#
|
|
|
|
# @id: the name of the new object
|
|
|
|
#
|
|
|
|
# Since: 6.0
|
|
|
|
##
|
|
|
|
{ 'union': 'ObjectOptions',
|
|
|
|
'base': { 'qom-type': 'ObjectType',
|
|
|
|
'id': 'str' },
|
|
|
|
'discriminator': 'qom-type',
|
|
|
|
'data': {
|
qom: new object to associate device to NUMA node
NVIDIA GPU's support MIG (Mult-Instance GPUs) feature [1], which allows
partitioning of the GPU device resources (including device memory) into
several (upto 8) isolated instances. Each of the partitioned memory needs
a dedicated NUMA node to operate. The partitions are not fixed and they
can be created/deleted at runtime.
Unfortunately Linux OS does not provide a means to dynamically create/destroy
NUMA nodes and such feature implementation is not expected to be trivial. The
nodes that OS discovers at the boot time while parsing SRAT remains fixed. So
we utilize the Generic Initiator (GI) Affinity structures that allows
association between nodes and devices. Multiple GI structures per BDF is
possible, allowing creation of multiple nodes by exposing unique PXM in each
of these structures.
Implement the mechanism to build the GI affinity structures as Qemu currently
does not. Introduce a new acpi-generic-initiator object to allow host admin
link a device with an associated NUMA node. Qemu maintains this association
and use this object to build the requisite GI Affinity Structure.
When multiple NUMA nodes are associated with a device, it is required to
create those many number of acpi-generic-initiator objects, each representing
a unique device:node association.
Following is one of a decoded GI affinity structure in VM ACPI SRAT.
[0C8h 0200 1] Subtable Type : 05 [Generic Initiator Affinity]
[0C9h 0201 1] Length : 20
[0CAh 0202 1] Reserved1 : 00
[0CBh 0203 1] Device Handle Type : 01
[0CCh 0204 4] Proximity Domain : 00000007
[0D0h 0208 16] Device Handle : 00 00 20 00 00 00 00 00 00 00 00
00 00 00 00 00
[0E0h 0224 4] Flags (decoded below) : 00000001
Enabled : 1
[0E4h 0228 4] Reserved2 : 00000000
[0E8h 0232 1] Subtable Type : 05 [Generic Initiator Affinity]
[0E9h 0233 1] Length : 20
An admin can provide a range of acpi-generic-initiator objects, each
associating a device (by providing the id through pci-dev argument)
to the desired NUMA node (using the node argument). Currently, only PCI
device is supported.
For the grace hopper system, create a range of 8 nodes and associate that
with the device using the acpi-generic-initiator object. While a configuration
of less than 8 nodes per device is allowed, such configuration will prevent
utilization of the feature to the fullest. The following sample creates 8
nodes per PCI device for a VM with 2 PCI devices and link them to the
respecitve PCI device using acpi-generic-initiator objects:
-numa node,nodeid=2 -numa node,nodeid=3 -numa node,nodeid=4 \
-numa node,nodeid=5 -numa node,nodeid=6 -numa node,nodeid=7 \
-numa node,nodeid=8 -numa node,nodeid=9 \
-device vfio-pci-nohotplug,host=0009:01:00.0,bus=pcie.0,addr=04.0,rombar=0,id=dev0 \
-object acpi-generic-initiator,id=gi0,pci-dev=dev0,node=2 \
-object acpi-generic-initiator,id=gi1,pci-dev=dev0,node=3 \
-object acpi-generic-initiator,id=gi2,pci-dev=dev0,node=4 \
-object acpi-generic-initiator,id=gi3,pci-dev=dev0,node=5 \
-object acpi-generic-initiator,id=gi4,pci-dev=dev0,node=6 \
-object acpi-generic-initiator,id=gi5,pci-dev=dev0,node=7 \
-object acpi-generic-initiator,id=gi6,pci-dev=dev0,node=8 \
-object acpi-generic-initiator,id=gi7,pci-dev=dev0,node=9 \
-numa node,nodeid=10 -numa node,nodeid=11 -numa node,nodeid=12 \
-numa node,nodeid=13 -numa node,nodeid=14 -numa node,nodeid=15 \
-numa node,nodeid=16 -numa node,nodeid=17 \
-device vfio-pci-nohotplug,host=0009:01:01.0,bus=pcie.0,addr=05.0,rombar=0,id=dev1 \
-object acpi-generic-initiator,id=gi8,pci-dev=dev1,node=10 \
-object acpi-generic-initiator,id=gi9,pci-dev=dev1,node=11 \
-object acpi-generic-initiator,id=gi10,pci-dev=dev1,node=12 \
-object acpi-generic-initiator,id=gi11,pci-dev=dev1,node=13 \
-object acpi-generic-initiator,id=gi12,pci-dev=dev1,node=14 \
-object acpi-generic-initiator,id=gi13,pci-dev=dev1,node=15 \
-object acpi-generic-initiator,id=gi14,pci-dev=dev1,node=16 \
-object acpi-generic-initiator,id=gi15,pci-dev=dev1,node=17 \
Link: https://www.nvidia.com/en-in/technologies/multi-instance-gpu [1]
Cc: Jonathan Cameron <qemu-devel@nongnu.org>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Ankit Agrawal <ankita@nvidia.com>
Message-Id: <20240308145525.10886-2-ankita@nvidia.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-08 17:55:23 +03:00
|
|
|
'acpi-generic-initiator': 'AcpiGenericInitiatorProperties',
|
2024-09-16 20:41:22 +03:00
|
|
|
'acpi-generic-port': 'AcpiGenericPortProperties',
|
2020-10-20 13:47:58 +03:00
|
|
|
'authz-list': 'AuthZListProperties',
|
|
|
|
'authz-listfile': 'AuthZListFileProperties',
|
|
|
|
'authz-pam': 'AuthZPAMProperties',
|
|
|
|
'authz-simple': 'AuthZSimpleProperties',
|
2021-09-28 19:02:32 +03:00
|
|
|
'can-host-socketcan': { 'type': 'CanHostSocketcanProperties',
|
|
|
|
'if': 'CONFIG_LINUX' },
|
2020-10-20 13:47:58 +03:00
|
|
|
'colo-compare': 'ColoCompareProperties',
|
2020-10-20 13:47:58 +03:00
|
|
|
'cryptodev-backend': 'CryptodevBackendProperties',
|
|
|
|
'cryptodev-backend-builtin': 'CryptodevBackendProperties',
|
2022-10-08 11:50:30 +03:00
|
|
|
'cryptodev-backend-lkcf': 'CryptodevBackendProperties',
|
2020-10-20 13:47:58 +03:00
|
|
|
'cryptodev-vhost-user': { 'type': 'CryptodevVhostUserProperties',
|
2021-08-04 11:31:05 +03:00
|
|
|
'if': 'CONFIG_VHOST_CRYPTO' },
|
2020-10-20 13:47:58 +03:00
|
|
|
'dbus-vmstate': 'DBusVMStateProperties',
|
2020-10-20 13:47:58 +03:00
|
|
|
'filter-buffer': 'FilterBufferProperties',
|
|
|
|
'filter-dump': 'FilterDumpProperties',
|
|
|
|
'filter-mirror': 'FilterMirrorProperties',
|
|
|
|
'filter-redirector': 'FilterRedirectorProperties',
|
|
|
|
'filter-replay': 'NetfilterProperties',
|
|
|
|
'filter-rewriter': 'FilterRewriterProperties',
|
2020-10-20 13:47:58 +03:00
|
|
|
'input-barrier': 'InputBarrierProperties',
|
2021-09-28 19:02:32 +03:00
|
|
|
'input-linux': { 'type': 'InputLinuxProperties',
|
|
|
|
'if': 'CONFIG_LINUX' },
|
2023-11-21 11:44:00 +03:00
|
|
|
'iommufd': 'IOMMUFDProperties',
|
2020-10-20 13:47:58 +03:00
|
|
|
'iothread': 'IothreadProperties',
|
2022-04-25 10:57:22 +03:00
|
|
|
'main-loop': 'MainLoopProperties',
|
2021-09-28 19:02:32 +03:00
|
|
|
'memory-backend-epc': { 'type': 'MemoryBackendEpcProperties',
|
|
|
|
'if': 'CONFIG_LINUX' },
|
2020-10-20 13:47:58 +03:00
|
|
|
'memory-backend-file': 'MemoryBackendFileProperties',
|
|
|
|
'memory-backend-memfd': { 'type': 'MemoryBackendMemfdProperties',
|
2021-08-04 11:31:05 +03:00
|
|
|
'if': 'CONFIG_LINUX' },
|
2020-10-20 13:47:58 +03:00
|
|
|
'memory-backend-ram': 'MemoryBackendProperties',
|
2024-06-18 13:05:19 +03:00
|
|
|
'memory-backend-shm': { 'type': 'MemoryBackendShmProperties',
|
|
|
|
'if': 'CONFIG_POSIX' },
|
2021-09-28 19:02:32 +03:00
|
|
|
'pr-manager-helper': { 'type': 'PrManagerHelperProperties',
|
|
|
|
'if': 'CONFIG_LINUX' },
|
2020-11-09 18:13:30 +03:00
|
|
|
'qtest': 'QtestProperties',
|
2020-10-20 13:47:58 +03:00
|
|
|
'rng-builtin': 'RngProperties',
|
|
|
|
'rng-egd': 'RngEgdProperties',
|
2021-09-28 19:02:32 +03:00
|
|
|
'rng-random': { 'type': 'RngRandomProperties',
|
|
|
|
'if': 'CONFIG_POSIX' },
|
2020-10-20 13:47:58 +03:00
|
|
|
'secret': 'SecretProperties',
|
2021-09-28 19:02:32 +03:00
|
|
|
'secret_keyring': { 'type': 'SecretKeyringProperties',
|
|
|
|
'if': 'CONFIG_SECRET_KEYRING' },
|
2021-03-26 11:48:39 +03:00
|
|
|
'sev-guest': 'SevGuestProperties',
|
i386/sev: Introduce 'sev-snp-guest' object
SEV-SNP support relies on a different set of properties/state than the
existing 'sev-guest' object. This patch introduces the 'sev-snp-guest'
object, which can be used to configure an SEV-SNP guest. For example,
a default-configured SEV-SNP guest with no additional information
passed in for use with attestation:
-object sev-snp-guest,id=sev0
or a fully-specified SEV-SNP guest where all spec-defined binary
blobs are passed in as base64-encoded strings:
-object sev-snp-guest,id=sev0, \
policy=0x30000, \
init-flags=0, \
id-block=YWFhYWFhYWFhYWFhYWFhCg==, \
id-auth=CxHK/OKLkXGn/KpAC7Wl1FSiisWDbGTEKz..., \
author-key-enabled=on, \
host-data=LNkCWBRC5CcdGXirbNUV1OrsR28s..., \
guest-visible-workarounds=AA==, \
See the QAPI schema updates included in this patch for more usage
details.
In some cases these blobs may be up to 4096 characters, but this is
generally well below the default limit for linux hosts where
command-line sizes are defined by the sysconf-configurable ARG_MAX
value, which defaults to 2097152 characters for Ubuntu hosts, for
example.
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Co-developed-by: Michael Roth <michael.roth@amd.com>
Acked-by: Markus Armbruster <armbru@redhat.com> (for QAPI schema)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Co-developed-by: Pankaj Gupta <pankaj.gupta@amd.com>
Signed-off-by: Pankaj Gupta <pankaj.gupta@amd.com>
Message-ID: <20240530111643.1091816-8-pankaj.gupta@amd.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-05-30 14:16:19 +03:00
|
|
|
'sev-snp-guest': 'SevSnpGuestProperties',
|
util: Introduce ThreadContext user-creatable object
Setting the CPU affinity of QEMU threads is a bit problematic, because
QEMU doesn't always have permissions to set the CPU affinity itself,
for example, with seccomp after initialized by QEMU:
-sandbox enable=on,resourcecontrol=deny
General information about CPU affinities can be found in the man page of
taskset:
CPU affinity is a scheduler property that "bonds" a process to a given
set of CPUs on the system. The Linux scheduler will honor the given CPU
affinity and the process will not run on any other CPUs.
While upper layers are already aware of how to handle CPU affinities for
long-lived threads like iothreads or vcpu threads, especially short-lived
threads, as used for memory-backend preallocation, are more involved to
handle. These threads are created on demand and upper layers are not even
able to identify and configure them.
Introduce the concept of a ThreadContext, that is essentially a thread
used for creating new threads. All threads created via that context
thread inherit the configured CPU affinity. Consequently, it's
sufficient to create a ThreadContext and configure it once, and have all
threads created via that ThreadContext inherit the same CPU affinity.
The CPU affinity of a ThreadContext can be configured two ways:
(1) Obtaining the thread id via the "thread-id" property and setting the
CPU affinity manually (e.g., via taskset).
(2) Setting the "cpu-affinity" property and letting QEMU try set the
CPU affinity itself. This will fail if QEMU doesn't have permissions
to do so anymore after seccomp was initialized.
A simple QEMU example to set the CPU affinity to host CPU 0,1,6,7 would be:
qemu-system-x86_64 -S \
-object thread-context,id=tc1,cpu-affinity=0-1,cpu-affinity=6-7
And we can query it via HMP/QMP:
(qemu) qom-get tc1 cpu-affinity
[
0,
1,
6,
7
]
But note that due to dynamic library loading this example will not work
before we actually make use of thread_context_create_thread() in QEMU
code, because the type will otherwise not get registered. We'll wire
this up next to make it work.
In general, the interface behaves like pthread_setaffinity_np(): host
CPU numbers that are currently not available are ignored; only host CPU
numbers that are impossible with the current kernel will fail. If the
list of host CPU numbers does not include a single CPU that is
available, setting the CPU affinity will fail.
A ThreadContext can be reused, simply by reconfiguring the CPU affinity.
Note that the CPU affinity of previously created threads will not get
adjusted.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20221014134720.168738-4-david@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
2022-10-14 16:47:16 +03:00
|
|
|
'thread-context': 'ThreadContextProperties',
|
2020-10-20 13:47:58 +03:00
|
|
|
'throttle-group': 'ThrottleGroupProperties',
|
|
|
|
'tls-creds-anon': 'TlsCredsAnonProperties',
|
|
|
|
'tls-creds-psk': 'TlsCredsPskProperties',
|
|
|
|
'tls-creds-x509': 'TlsCredsX509Properties',
|
2021-02-24 15:21:48 +03:00
|
|
|
'tls-cipher-suites': 'TlsCredsProperties',
|
2022-06-13 23:26:25 +03:00
|
|
|
'x-remote-object': 'RemoteObjectProperties',
|
|
|
|
'x-vfio-user-server': 'VfioUserServerProperties'
|
2020-10-20 13:47:58 +03:00
|
|
|
} }
|
|
|
|
|
2019-06-19 23:10:37 +03:00
|
|
|
##
|
|
|
|
# @object-add:
|
|
|
|
#
|
|
|
|
# Create a QOM object.
|
|
|
|
#
|
2024-02-27 14:39:12 +03:00
|
|
|
# Errors:
|
2024-01-20 12:53:25 +03:00
|
|
|
# - Error if @qom-type is not a valid class name
|
2019-06-19 23:10:37 +03:00
|
|
|
#
|
|
|
|
# Since: 2.0
|
|
|
|
#
|
2024-07-17 05:13:08 +03:00
|
|
|
# .. qmp-example::
|
2019-06-19 23:10:37 +03:00
|
|
|
#
|
2024-02-16 17:58:34 +03:00
|
|
|
# -> { "execute": "object-add",
|
|
|
|
# "arguments": { "qom-type": "rng-random", "id": "rng1",
|
|
|
|
# "filename": "/dev/hwrng" } }
|
|
|
|
# <- { "return": {} }
|
2019-06-19 23:10:37 +03:00
|
|
|
##
|
2020-11-03 12:39:02 +03:00
|
|
|
{ 'command': 'object-add', 'data': 'ObjectOptions', 'boxed': true,
|
|
|
|
'allow-preconfig': true }
|
2019-06-19 23:10:37 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @object-del:
|
|
|
|
#
|
|
|
|
# Remove a QOM object.
|
|
|
|
#
|
|
|
|
# @id: the name of the QOM object to remove
|
|
|
|
#
|
2024-02-27 14:39:12 +03:00
|
|
|
# Errors:
|
2024-01-20 12:53:25 +03:00
|
|
|
# - Error if @id is not a valid id for a QOM object
|
2019-06-19 23:10:37 +03:00
|
|
|
#
|
|
|
|
# Since: 2.0
|
|
|
|
#
|
2024-07-17 05:13:08 +03:00
|
|
|
# .. qmp-example::
|
2019-06-19 23:10:37 +03:00
|
|
|
#
|
2024-02-16 17:58:34 +03:00
|
|
|
# -> { "execute": "object-del", "arguments": { "id": "rng1" } }
|
|
|
|
# <- { "return": {} }
|
2019-06-19 23:10:37 +03:00
|
|
|
##
|
2020-11-03 12:39:02 +03:00
|
|
|
{ 'command': 'object-del', 'data': {'id': 'str'},
|
|
|
|
'allow-preconfig': true }
|