kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
To: Paolo Abeni <pabeni@redhat.com>, qemu-devel@nongnu.org
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Dmitry Fleytman <dmitry.fleytman@gmail.com>,
	Jason Wang <jasowang@redhat.com>,
	Sriram Yagnaraman <sriram.yagnaraman@ericsson.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Stefano Garzarella <sgarzare@redhat.com>,
	Cornelia Huck <cohuck@redhat.com>,
	Luigi Rizzo <lrizzo@google.com>,
	Giuseppe Lettieri <g.lettieri@iet.unipi.it>,
	Vincenzo Maffione <v.maffione@gmail.com>,
	Eric Blake <eblake@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	kvm@vger.kernel.org
Subject: Re: [PATCH RFC v2 03/13] virtio: introduce extended features type
Date: Tue, 15 Jul 2025 15:57:29 +0900	[thread overview]
Message-ID: <45e600c7-90f4-4daa-a68b-8da90758b861@rsg.ci.i.u-tokyo.ac.jp> (raw)
In-Reply-To: <8c179f9cd04d6cb5e6f822203c6a057704133386.1752229731.git.pabeni@redhat.com>

On 2025/07/11 22:02, Paolo Abeni wrote:
> The virtio specifications allows for up to 128 bits for the
> device features. Soon we are going to use some of the 'extended'
> bits features (above 64) for the virtio net driver.
> 
> Represent the virtio features bitmask with a fixes size array, and
> introduce a few helpers to help manipulate them.
> 
> Most drivers will keep using only 64 bits features space: use union
> to allow them access the lower part of the extended space without any
> per driver change.
> 
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> ---
> v1 -> v2:
>    - use a fixed size array for features instead of uint128
>    - use union with u64 to reduce the needed code churn
> ---
>   include/hw/virtio/virtio-features.h | 124 ++++++++++++++++++++++++++++
>   include/hw/virtio/virtio.h          |   7 +-
>   2 files changed, 128 insertions(+), 3 deletions(-)
>   create mode 100644 include/hw/virtio/virtio-features.h
> 
> diff --git a/include/hw/virtio/virtio-features.h b/include/hw/virtio/virtio-features.h
> new file mode 100644
> index 0000000000..cc735f7f81
> --- /dev/null
> +++ b/include/hw/virtio/virtio-features.h
> @@ -0,0 +1,124 @@
> +/*
> + * Virtio features helpers
> + *
> + * Copyright 2025 Red Hat, Inc.
> + *
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + */
> +
> +#ifndef _QEMU_VIRTIO_FEATURES_H
> +#define _QEMU_VIRTIO_FEATURES_H

An identifier prefixed with an underscore and a capital letter is 
reserved and better to avoid. Let's also keep consistent with QEMU_VIRTIO_H.

> +
> +#define VIRTIO_FEATURES_FMT        "%016"PRIx64"%016"PRIx64
> +#define VIRTIO_FEATURES_PR(f)      f[1], f[0]
> +
> +#define VIRTIO_FEATURES_MAX        128
> +#define VIRTIO_BIT(b)              (1ULL << (b & 0x3f))

Let's use BIT_ULL().

I also think (b % 64) is easier to understand than (b & 0x3f); you may 
refer to BIT_MASK() and BIT_WORD() as prior examples.

> +#define VIRTIO_DWORD(b)            ((b) >> 6)

VIRTIO_FEATURES_PR() and VIRTIO_BIT() should have parentheses around 
their parameters as VIRTIO_DWORD() does.

> +#define VIRTIO_FEATURES_WORDS     (VIRTIO_FEATURES_MAX >> 5)

This macro is misaligned; personally I prefer just use one whitespace to 
delimit the macro name and value to avoid the trouble of aligning them 
and polluting "git blame".

> +#define VIRTIO_FEATURES_DWORDS      (VIRTIO_FEATURES_WORDS >> 1)
> +
> +#define VIRTIO_DECLARE_FEATURES(name)                        \
> +    union {                                                  \
> +        uint64_t name;                                       \
> +        uint64_t name##_array[VIRTIO_FEATURES_DWORDS];       \
> +    }
> +
> +static inline void virtio_features_clear(uint64_t *features)
> +{
> +    memset(features, 0, sizeof(features[0]) * VIRTIO_FEATURES_DWORDS);
> +}
> +
> +static inline void virtio_features_from_u64(uint64_t *features, uint64_t from)
> +{
> +    virtio_features_clear(features);
> +    features[0] = from;
> +}
> +
> +static inline bool virtio_has_feature_ex(const uint64_t *features,
> +                                         unsigned int fbit)
> +{
> +    assert(fbit < VIRTIO_FEATURES_MAX);
> +    return features[VIRTIO_DWORD(fbit)] & VIRTIO_BIT(fbit);
> +}
> +
> +static inline void virtio_add_feature_ex(uint64_t *features,
> +                                         unsigned int fbit)
> +{
> +    assert(fbit < VIRTIO_FEATURES_MAX);
> +    features[VIRTIO_DWORD(fbit)] |= VIRTIO_BIT(fbit);
> +}
> +
> +static inline void virtio_clear_feature_ex(uint64_t *features,
> +                                           unsigned int fbit)
> +{
> +    assert(fbit < VIRTIO_FEATURES_MAX);
> +    features[VIRTIO_DWORD(fbit)] &= ~VIRTIO_BIT(fbit);
> +}
> +
> +static inline bool virtio_features_equal(const uint64_t *f1,
> +                                         const uint64_t *f2)
> +{
> +    uint64_t diff = 0;
> +    int i;
> +
> +    for (i = 0; i < VIRTIO_FEATURES_DWORDS; ++i) {
> +        diff |= f1[i] ^ f2[i];
> +    }
> +    return !!diff;

Let's use memcmp().

> +}
> +
> +static inline bool virtio_features_use_extended(const uint64_t *features)
> +{
> +    int i;
> +
> +    for (i = 1; i < VIRTIO_FEATURES_DWORDS; ++i) {
> +        if (features[i]) {
> +            return true;
> +        }
> +    }
> +    return false;
> +}
> +
> +static inline bool virtio_features_is_empty(const uint64_t *features)

Let's follow bitmap_empty() and omit "is".

> +{
> +    return !virtio_features_use_extended(features) && !features[0];
> +}
> +
> +static inline void virtio_features_copy(uint64_t *to, const uint64_t *from)
> +{
> +    memcpy(to, from, sizeof(to[0]) * VIRTIO_FEATURES_DWORDS);
> +}
> +
> +static inline void virtio_features_andnot(uint64_t *to, const uint64_t *f1,
> +                                           const uint64_t *f2)
> +{
> +    int i;
> +
> +    for (i = 0; i < VIRTIO_FEATURES_DWORDS; i++) {
> +        to[i] = f1[i] & ~f2[i];
> +    }
> +}
> +
> +static inline void virtio_features_and(uint64_t *to, const uint64_t *f1,
> +                                       const uint64_t *f2)
> +{
> +    int i;
> +
> +    for (i = 0; i < VIRTIO_FEATURES_DWORDS; i++) {
> +        to[i] = f1[i] & f2[i];
> +    }
> +}
> +
> +static inline void virtio_features_or(uint64_t *to, const uint64_t *f1,
> +                                       const uint64_t *f2)
> +{
> +    int i;
> +
> +    for (i = 0; i < VIRTIO_FEATURES_DWORDS; i++) {
> +        to[i] = f1[i] | f2[i];
> +    }
> +}
> +
> +#endif
> +
> diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
> index 214d4a77e9..0d1eb20489 100644
> --- a/include/hw/virtio/virtio.h
> +++ b/include/hw/virtio/virtio.h
> @@ -16,6 +16,7 @@
>   
>   #include "system/memory.h"
>   #include "hw/qdev-core.h"
> +#include "hw/virtio/virtio-features.h"
>   #include "net/net.h"
>   #include "migration/vmstate.h"
>   #include "qemu/event_notifier.h"
> @@ -121,9 +122,9 @@ struct VirtIODevice
>        * backend (e.g. vhost) and could potentially be a subset of the
>        * total feature set offered by QEMU.
>        */
> -    uint64_t host_features;
> -    uint64_t guest_features;
> -    uint64_t backend_features;
> +    VIRTIO_DECLARE_FEATURES(host_features);
> +    VIRTIO_DECLARE_FEATURES(guest_features);
> +    VIRTIO_DECLARE_FEATURES(backend_features);
>   
>       size_t config_len;
>       void *config;


  reply	other threads:[~2025-07-15  6:57 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-11 13:02 [PATCH RFC v2 00/13] virtio: introduce support for GSO over UDP tunnel Paolo Abeni
2025-07-11 13:02 ` [PATCH RFC v2 01/13] net: bundle all offloads in a single struct Paolo Abeni
2025-07-15  6:36   ` Akihiko Odaki
2025-07-15 14:52     ` Paolo Abeni
2025-07-16 11:32       ` Akihiko Odaki
2025-07-11 13:02 ` [PATCH RFC v2 02/13] linux-headers: Update to Linux ~v6.16-rc5 net-next Paolo Abeni
2025-07-11 13:02 ` [PATCH RFC v2 03/13] virtio: introduce extended features type Paolo Abeni
2025-07-15  6:57   ` Akihiko Odaki [this message]
2025-07-11 13:02 ` [PATCH RFC v2 04/13] virtio: serialize extended features state Paolo Abeni
2025-07-15  7:24   ` Akihiko Odaki
2025-07-15 15:40     ` Paolo Abeni
2025-07-16 11:52       ` Akihiko Odaki
2025-07-11 13:02 ` [PATCH RFC v2 05/13] virtio: add support for negotiating extended features Paolo Abeni
2025-07-11 13:02 ` [PATCH RFC v2 06/13] virtio-pci: implement support for " Paolo Abeni
2025-07-15  7:42   ` Akihiko Odaki
2025-07-15 16:21     ` Paolo Abeni
2025-07-16  9:14       ` Paolo Abeni
2025-07-16 11:55         ` Akihiko Odaki
2025-07-11 13:02 ` [PATCH RFC v2 07/13] vhost: add support for negotiating " Paolo Abeni
2025-07-11 13:02 ` [PATCH RFC v2 08/13] qmp: update virtio features map to support " Paolo Abeni
2025-07-15  7:59   ` Akihiko Odaki
2025-07-15 15:43     ` Paolo Abeni
2025-07-16 12:00       ` Akihiko Odaki
2025-07-11 13:02 ` [PATCH RFC v2 09/13] vhost-backend: implement extended features support Paolo Abeni
2025-07-11 13:02 ` [PATCH RFC v2 10/13] vhost-net: " Paolo Abeni
2025-07-11 13:02 ` [PATCH RFC v2 11/13] virtio-net: " Paolo Abeni
2025-07-11 13:02 ` [PATCH RFC v2 12/13] net: implement tunnel probing Paolo Abeni
2025-07-15  8:05   ` Akihiko Odaki
2025-07-15 15:49     ` Paolo Abeni
2025-07-18  4:38       ` Akihiko Odaki
2025-07-11 13:02 ` [PATCH RFC v2 13/13] net: implement UDP tunnel features offloading Paolo Abeni
2025-07-15  8:07   ` Akihiko Odaki
2025-07-16 10:13     ` Paolo Abeni
2025-07-16 12:04       ` Akihiko Odaki
2025-07-14  8:43 ` [PATCH RFC v2 00/13] virtio: introduce support for GSO over UDP tunnel Lei Yang
2025-07-14  9:05   ` Paolo Abeni
2025-07-14  9:09     ` Lei Yang

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=45e600c7-90f4-4daa-a68b-8da90758b861@rsg.ci.i.u-tokyo.ac.jp \
    --to=odaki@rsg.ci.i.u-tokyo.ac.jp \
    --cc=armbru@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=dmitry.fleytman@gmail.com \
    --cc=eblake@redhat.com \
    --cc=g.lettieri@iet.unipi.it \
    --cc=jasowang@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=lrizzo@google.com \
    --cc=mst@redhat.com \
    --cc=pabeni@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=sgarzare@redhat.com \
    --cc=sriram.yagnaraman@ericsson.com \
    --cc=v.maffione@gmail.com \
    /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).