qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: zhenwei pi <pizhenwei@bytedance.com>
Cc: arei.gonglei@huawei.com, mst@redhat.com, dgilbert@redhat.com,
	eblake@redhat.com, armbru@redhat.com, michael.roth@amd.com,
	pbonzini@redhat.com, qemu-devel@nongnu.org
Subject: Re: [for-8.0 v2 05/11] cryptodev: Introduce 'query-cryptodev' QMP command
Date: Mon, 16 Jan 2023 11:18:19 +0000	[thread overview]
Message-ID: <Y8UyezxcEeE+TH2p@redhat.com> (raw)
In-Reply-To: <20221122140756.686982-6-pizhenwei@bytedance.com>

On Tue, Nov 22, 2022 at 10:07:50PM +0800, zhenwei pi wrote:
> Now we have a QMP command to query crypto devices:
> virsh qemu-monitor-command vm '{"execute": "query-cryptodev"}' | jq
> {
>   "return": [
>     {
>       "service": [
>         "akcipher",
>         "mac",
>         "hash",
>         "cipher"
>       ],
>       "id": "cryptodev1",
>       "client": [
>         {
>           "queue": 0,
>           "type": "builtin",
>           "info": "cryptodev-builtin0"
>         }
>       ]
>     },
>     {
>       "service": [
>         "akcipher"
>       ],
>       "id": "cryptodev0",
>       "client": [
>         {
>           "queue": 0,
>           "type": "lkcf",
>           "info": "cryptodev-lkcf0"
>         }
>       ]
>     }
>   ],
>   "id": "libvirt-415"
> }
> 
> Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
> ---
>  backends/cryptodev.c | 49 ++++++++++++++++++++++++++++++++++++++++++++
>  qapi/cryptodev.json  | 43 ++++++++++++++++++++++++++++++++++++++
>  2 files changed, 92 insertions(+)
> 
> diff --git a/backends/cryptodev.c b/backends/cryptodev.c
> index d3caded920..bf2f3234c9 100644
> --- a/backends/cryptodev.c
> +++ b/backends/cryptodev.c
> @@ -24,6 +24,7 @@
>  #include "qemu/osdep.h"
>  #include "sysemu/cryptodev.h"
>  #include "qapi/error.h"
> +#include "qapi/qapi-commands-cryptodev.h"
>  #include "qapi/visitor.h"
>  #include "qemu/config-file.h"
>  #include "qemu/error-report.h"
> @@ -33,6 +34,54 @@
>  
>  static QTAILQ_HEAD(, CryptoDevBackendClient) crypto_clients;
>  
> +static int qmp_query_cryptodev_foreach(Object *obj, void *data)
> +{
> +    CryptoDevBackend *backend;
> +    CryptodevInfoList **infolist = data;
> +    uint32_t services;
> +
> +    if (!object_dynamic_cast(obj, TYPE_CRYPTODEV_BACKEND)) {
> +        return 0;
> +    }
> +
> +    CryptodevInfo *info = g_new0(CryptodevInfo, 1);
> +    info->id = g_strdup(object_get_canonical_path_component(obj));
> +
> +    backend = CRYPTODEV_BACKEND(obj);
> +    services = backend->conf.crypto_services;
> +    for (uint32_t i = 0; i < QCRYPTODEV_BACKEND_SERVICE__MAX; i++) {

QEMU coding style doesn't declare types inside the for() control
conditions. I'd suggest 'size_t i', and put it at top of this
function.

> +        if (services & (1 << i)) {
> +            QAPI_LIST_PREPEND(info->service, i);
> +        }
> +    }
> +
> +    for (uint32_t i = 0; i < backend->conf.peers.queues; i++) {
> +        CryptoDevBackendClient *cc = backend->conf.peers.ccs[i];
> +        CryptodevBackendClient *client = g_new0(CryptodevBackendClient, 1);
> +
> +        client->queue = cc->queue_index;
> +        client->type = cc->type;
> +        if (cc->info_str) {
> +            client->has_info = true;
> +            client->info = strdup(cc->info_str);

This will need rebasing, because the 'has_XXXX' fields have gone
away for all pointer types.

> +        }
> +        QAPI_LIST_PREPEND(info->client, client);
> +    }
> +
> +    QAPI_LIST_PREPEND(*infolist, info);
> +
> +    return 0;
> +}
> +
> +CryptodevInfoList *qmp_query_cryptodev(Error **errp)
> +{
> +    CryptodevInfoList *list = NULL;
> +    Object *objs = container_get(object_get_root(), "/objects");
> +
> +    object_child_foreach(objs, qmp_query_cryptodev_foreach, &list);
> +
> +    return list;
> +}
>  
>  CryptoDevBackendClient *cryptodev_backend_new_client(void)
>  {
> diff --git a/qapi/cryptodev.json b/qapi/cryptodev.json
> index 8732a30524..4cc4f4f0ed 100644
> --- a/qapi/cryptodev.json
> +++ b/qapi/cryptodev.json
> @@ -43,3 +43,46 @@
>  { 'enum': 'QCryptodevBackendType',
>    'prefix': 'QCRYPTODEV_BACKEND_TYPE',
>    'data': ['builtin', 'vhost-user', 'lkcf']}
> +
> +##
> +# @CryptodevBackendClient:
> +#
> +# Information about a queue of crypto device.
> +#
> +# @type: the type of the crypto device
> +#
> +# @info: the additional infomation of the crypto device
> +#
> +# Since: 8.0
> +##
> +{ 'struct': 'CryptodevBackendClient',
> +  'data': { 'queue': 'int',
> +            'type': 'QCryptodevBackendType',
> +            '*info': 'str' } }

'queue' field is not documented

I'm not too sure about the approach of exposing 'info'.

It looks like this is either a plain static string whose
value is implicitly determined by 'type', for the 'builtin'
and 'lkcf' backend types, or it is a printf() formattted
string for the 'vhost-user' type, which references the
chardev.

Exposing printf() formatted output is often an anti-pattern
for QAPI design. For example, if it is important for users
to know the chardev assocaited with the vhost-user backend,
then 'info' should be a union that is discriminated by
'type'. The 'vhost-user' branch of the enum should then
identify the chardev 'id' directly.

> +##
> +# @CryptodevInfo:
> +#
> +# Information about a crypto device.
> +#
> +# @service: supported service types of a crypto device
> +#
> +# @client: the additional infomation of the crypto device
> +#
> +# Since: 8.0
> +##
> +{ 'struct': 'CryptodevInfo',
> +  'data': { 'id': 'str',
> +            'service': ['QCryptodevBackendServiceType'],
> +            'client': ['CryptodevBackendClient'] } }

'id' field is not documented.

> +
> +##
> +# @query-cryptodev:
> +#
> +# Returns information about current crypto devices.
> +#
> +# Returns: a list of @CryptodevInfo
> +#
> +# Since: 8.0
> +##
> +{ 'command': 'query-cryptodev', 'returns': ['CryptodevInfo']}

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



  reply	other threads:[~2023-01-16 11:19 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-22 14:07 [for-8.0 v2 00/11] Refactor cryptodev zhenwei pi
2022-11-22 14:07 ` [for-8.0 v2 01/11] cryptodev: Introduce cryptodev.json zhenwei pi
2023-01-16 10:58   ` Daniel P. Berrangé
2022-11-22 14:07 ` [for-8.0 v2 02/11] cryptodev: Remove 'name' & 'model' fields zhenwei pi
2023-01-16 11:05   ` Daniel P. Berrangé
2022-11-22 14:07 ` [for-8.0 v2 03/11] cryptodev: Introduce cryptodev alg type in QAPI zhenwei pi
2023-01-16 11:08   ` Daniel P. Berrangé
2022-11-22 14:07 ` [for-8.0 v2 04/11] cryptodev: Introduce server " zhenwei pi
2023-01-16 11:09   ` Daniel P. Berrangé
2022-11-22 14:07 ` [for-8.0 v2 05/11] cryptodev: Introduce 'query-cryptodev' QMP command zhenwei pi
2023-01-16 11:18   ` Daniel P. Berrangé [this message]
2023-01-18 10:25     ` Michael S. Tsirkin
2023-01-18 10:29       ` Daniel P. Berrangé
2023-01-18 10:58         ` Thomas Huth
2023-01-18 11:01           ` Daniel P. Berrangé
2022-11-22 14:07 ` [for-8.0 v2 06/11] cryptodev: Support statistics zhenwei pi
2022-12-20 15:35   ` Michael S. Tsirkin
2023-01-16 11:22   ` Daniel P. Berrangé
2022-11-22 14:07 ` [for-8.0 v2 07/11] cryptodev-builtin: Detect akcipher capability zhenwei pi
2023-01-16 11:23   ` Daniel P. Berrangé
2022-11-22 14:07 ` [for-8.0 v2 08/11] hmp: add cryptodev info command zhenwei pi
2022-11-22 14:07 ` [for-8.0 v2 09/11] cryptodev: Use CryptoDevBackendOpInfo for operation zhenwei pi
2022-11-22 14:07 ` [for-8.0 v2 10/11] cryptodev: support QoS zhenwei pi
2022-11-22 14:07 ` [for-8.0 v2 11/11] MAINTAINERS: add myself as the maintainer for cryptodev zhenwei pi
2022-12-16  3:24 ` PING: [for-8.0 v2 00/11] Refactor cryptodev zhenwei pi
2022-12-20 15:36 ` Michael S. Tsirkin
2022-12-22  2:04   ` zhenwei pi
2023-01-03  6:14     ` PING: " zhenwei pi
2023-01-16  9:53   ` zhenwei pi
2023-01-16 11:27     ` Daniel P. Berrangé
2023-01-17  1:52       ` zhenwei pi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y8UyezxcEeE+TH2p@redhat.com \
    --to=berrange@redhat.com \
    --cc=arei.gonglei@huawei.com \
    --cc=armbru@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=eblake@redhat.com \
    --cc=michael.roth@amd.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=pizhenwei@bytedance.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).