[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 14/14] vdpa: Add x-svq to NetdevVhostVDPAOptions
From: |
Markus Armbruster |
Subject: |
Re: [PATCH v3 14/14] vdpa: Add x-svq to NetdevVhostVDPAOptions |
Date: |
Thu, 03 Mar 2022 07:08:50 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
Eugenio Pérez <eperezma@redhat.com> writes:
> Finally offering the possibility to enable SVQ from the command line.
>
> Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
> ---
> qapi/net.json | 5 ++++-
> net/vhost-vdpa.c | 48 ++++++++++++++++++++++++++++++++++++++++--------
> 2 files changed, 44 insertions(+), 9 deletions(-)
>
> diff --git a/qapi/net.json b/qapi/net.json
> index 7fab2e7cd8..d243701527 100644
> --- a/qapi/net.json
> +++ b/qapi/net.json
> @@ -445,12 +445,15 @@
> # @queues: number of queues to be created for multiqueue vhost-vdpa
> # (default: 1)
> #
> +# @x-svq: Start device with (experimental) shadow virtqueue. (Since 7.0)
> +#
> # Since: 5.1
> ##
> { 'struct': 'NetdevVhostVDPAOptions',
> 'data': {
> '*vhostdev': 'str',
> - '*queues': 'int' } }
> + '*queues': 'int',
> + '*x-svq': 'bool' } }
Experimental members *must* be tagged with feature @unstable. Their
name *may* start with 'x-' to help human users, at the cost of renames
when the member becomes stable.
Documentation is in docs/devel/qapi-code-gen.rst:
Features
--------
Syntax::
FEATURES = [ FEATURE, ... ]
FEATURE = STRING
| { 'name': STRING, '*if': COND }
Sometimes, the behaviour of QEMU changes compatibly, but without a
change in the QMP syntax (usually by allowing values or operations
that previously resulted in an error). QMP clients may still need to
know whether the extension is available.
For this purpose, a list of features can be specified for a command or
struct type. Each list member can either be ``{ 'name': STRING, '*if':
COND }``, or STRING, which is shorthand for ``{ 'name': STRING }``.
The optional 'if' member specifies a conditional. See `Configuring
the schema`_ below for more on this.
Example::
{ 'struct': 'TestType',
'data': { 'number': 'int' },
'features': [ 'allow-negative-numbers' ] }
The feature strings are exposed to clients in introspection, as
explained in section `Client JSON Protocol introspection`_.
Intended use is to have each feature string signal that this build of
QEMU shows a certain behaviour.
Special features
~~~~~~~~~~~~~~~~
[...]
Feature "unstable" marks a command, event, enum value, or struct
member as unstable. It is not supported elsewhere so far. Interfaces
so marked may be withdrawn or changed incompatibly in future releases.
Naming rules and reserved names
-------------------------------
[...]
Names beginning with ``x-`` used to signify "experimental". This
convention has been replaced by special feature "unstable".
Rationale is in the commit message:
commit a3c45b3e62962f99338716b1347cfb0d427cea44
Author: Markus Armbruster <armbru@redhat.com>
Date: Thu Oct 28 12:25:12 2021 +0200
qapi: New special feature flag "unstable"
By convention, names starting with "x-" are experimental. The parts
of external interfaces so named may be withdrawn or changed
incompatibly in future releases.
The naming convention makes unstable interfaces easy to recognize.
Promoting something from experimental to stable involves a name
change. Client code needs to be updated. Occasionally bothersome.
Worse, the convention is not universally observed:
* QOM type "input-barrier" has properties "x-origin", "y-origin".
Looks accidental, but it's ABI since 4.2.
* QOM types "memory-backend-file", "memory-backend-memfd",
"memory-backend-ram", and "memory-backend-epc" have a property
"x-use-canonical-path-for-ramblock-id" that is documented to be
stable despite its name.
We could document these exceptions, but documentation helps only
humans. We want to recognize "unstable" in code, like "deprecated".
So support recognizing it the same way: introduce new special feature
flag "unstable". It will be treated specially by the QAPI generator,
like the existing feature flag "deprecated", and unlike regular
feature flags.
This commit updates documentation and prepares tests. The next commit
updates the QAPI schema. The remaining patches update the QAPI
generator and wire up -compat policy checking.
Management applications can then use query-qmp-schema and -compat to
manage or guard against use of unstable interfaces the same way as for
deprecated interfaces.
docs/devel/qapi-code-gen.txt no longer mandates the naming convention.
Using it anyway might help writers of programs that aren't
full-fledged management applications. Not using it can save us
bothersome renames. We'll see how that shakes out.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Message-Id: <20211028102520.747396-2-armbru@redhat.com>
>
> ##
> # @NetClientDriver:
[...]
- [PATCH v3 05/14] virtio: Add vhost_svq_get_vring_addr, (continued)
- [PATCH v3 05/14] virtio: Add vhost_svq_get_vring_addr, Eugenio Pérez, 2022/03/02
- [PATCH v3 06/14] vdpa: adapt vhost_ops callbacks to svq, Eugenio Pérez, 2022/03/02
- [PATCH v3 07/14] vhost: Shadow virtqueue buffers forwarding, Eugenio Pérez, 2022/03/02
- [PATCH v3 08/14] util: Add iova_tree_alloc_map, Eugenio Pérez, 2022/03/02
- [PATCH v3 09/14] vhost: Add VhostIOVATree, Eugenio Pérez, 2022/03/02
- [PATCH v3 10/14] vdpa: Add custom IOTLB translations to SVQ, Eugenio Pérez, 2022/03/02
- [PATCH v3 11/14] vdpa: Adapt vhost_vdpa_get_vring_base to SVQ, Eugenio Pérez, 2022/03/02
- [PATCH v3 12/14] vdpa: Never set log_base addr if SVQ is enabled, Eugenio Pérez, 2022/03/02
- [PATCH v3 13/14] vdpa: Expose VHOST_F_LOG_ALL on SVQ, Eugenio Pérez, 2022/03/02
- [PATCH v3 14/14] vdpa: Add x-svq to NetdevVhostVDPAOptions, Eugenio Pérez, 2022/03/02
- Re: [PATCH v3 14/14] vdpa: Add x-svq to NetdevVhostVDPAOptions,
Markus Armbruster <=
- Re: [PATCH v3 14/14] vdpa: Add x-svq to NetdevVhostVDPAOptions, Eugenio Perez Martin, 2022/03/03
- Re: [PATCH v3 14/14] vdpa: Add x-svq to NetdevVhostVDPAOptions, Markus Armbruster, 2022/03/03
- Re: [PATCH v3 14/14] vdpa: Add x-svq to NetdevVhostVDPAOptions, Eugenio Perez Martin, 2022/03/03
- Re: [PATCH v3 14/14] vdpa: Add x-svq to NetdevVhostVDPAOptions, Markus Armbruster, 2022/03/04
- Re: [PATCH v3 14/14] vdpa: Add x-svq to NetdevVhostVDPAOptions, Eugenio Perez Martin, 2022/03/04