All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: Fam Zheng <fam@euphon.net>,
	slp@redhat.com, mathieu.poirier@linaro.org,
	viresh.kumar@linaro.org, qemu-devel@nongnu.org,
	Raphael Norwitz <raphael.norwitz@nutanix.com>,
	Maxime Coquelin <maxime.coquelin@redhat.com>,
	stefanha@redhat.com, Paolo Bonzini <pbonzini@redhat.com>,
	marcandre.lureau@redhat.com
Subject: Re: [PATCH  v1 12/13] hw/virtio/vhost-user: don't suppress F_CONFIG when supported
Date: Tue, 22 Mar 2022 10:02:03 -0400	[thread overview]
Message-ID: <20220322095720-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20220321153037.3622127-13-alex.bennee@linaro.org>

On Mon, Mar 21, 2022 at 03:30:36PM +0000, Alex Bennée wrote:
> Previously we would silently suppress VHOST_USER_PROTOCOL_F_CONFIG
> during the protocol negotiation if the QEMU stub hadn't implemented
> the vhost_dev_config_notifier. However this isn't the only way we can
> handle config messages, the existing vdc->get/set_config can do this
> as well.


Could you give an example where the problem is encountered please?

> Lightly re-factor the code to check for both potential methods and
> instead of silently squashing the feature error out. It is unlikely
> that a vhost-user backend expecting to handle CONFIG messages will
> behave correctly if they never get sent.

Hmm but are you sure? Most devices work mostly fine without CONFIG
messages, there's a chance a backend set this flag just in case
without much thought ...

> Fixes: 1c3e5a2617 ("vhost-user: back SET/GET_CONFIG requests with a protocol feature")

I'm not sure whether something is broken or this is a cleanup patch.
Fixes tag means "if you have 1c3e5a2617 you should pick this patch", so
cleanups don't need a fixes: tag.


> Cc: Maxime Coquelin <maxime.coquelin@redhat.com>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Cc: Stefan Hajnoczi <stefanha@redhat.com>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> 
> ---
>   - we can't check for get_config/set_config as the stack squashed vdev
>   - use vhost-user-state to transmit this
> ---
>  include/hw/virtio/vhost-user.h |  1 +
>  hw/scsi/vhost-user-scsi.c      |  1 +
>  hw/virtio/vhost-user.c         | 46 ++++++++++++++++++++++++----------
>  3 files changed, 35 insertions(+), 13 deletions(-)
> 
> diff --git a/include/hw/virtio/vhost-user.h b/include/hw/virtio/vhost-user.h
> index e44a41bb70..6e0e8a71a3 100644
> --- a/include/hw/virtio/vhost-user.h
> +++ b/include/hw/virtio/vhost-user.h
> @@ -22,6 +22,7 @@ typedef struct VhostUserState {
>      CharBackend *chr;
>      VhostUserHostNotifier notifier[VIRTIO_QUEUE_MAX];
>      int memory_slots;
> +    bool supports_config;
>  } VhostUserState;
>  
>  bool vhost_user_init(VhostUserState *user, CharBackend *chr, Error **errp);
> diff --git a/hw/scsi/vhost-user-scsi.c b/hw/scsi/vhost-user-scsi.c
> index 1b2f7eed98..9be21d07ee 100644
> --- a/hw/scsi/vhost-user-scsi.c
> +++ b/hw/scsi/vhost-user-scsi.c
> @@ -121,6 +121,7 @@ static void vhost_user_scsi_realize(DeviceState *dev, Error **errp)
>      vsc->dev.backend_features = 0;
>      vqs = vsc->dev.vqs;
>  
> +    s->vhost_user.supports_config = true;
>      ret = vhost_dev_init(&vsc->dev, &s->vhost_user,
>                           VHOST_BACKEND_TYPE_USER, 0, errp);
>      if (ret < 0) {
> diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
> index b27b8c56e2..6ce082861b 100644
> --- a/hw/virtio/vhost-user.c
> +++ b/hw/virtio/vhost-user.c
> @@ -1949,14 +1949,15 @@ static int vhost_user_postcopy_notifier(NotifierWithReturn *notifier,
>  static int vhost_user_backend_init(struct vhost_dev *dev, void *opaque,
>                                     Error **errp)
>  {
> -    uint64_t features, protocol_features, ram_slots;
> +    uint64_t features, ram_slots;
>      struct vhost_user *u;
> +    VhostUserState *vus = (VhostUserState *) opaque;
>      int err;
>  
>      assert(dev->vhost_ops->backend_type == VHOST_BACKEND_TYPE_USER);
>  
>      u = g_new0(struct vhost_user, 1);
> -    u->user = opaque;
> +    u->user = vus;
>      u->dev = dev;
>      dev->opaque = u;
>  
> @@ -1967,6 +1968,10 @@ static int vhost_user_backend_init(struct vhost_dev *dev, void *opaque,
>      }
>  
>      if (virtio_has_feature(features, VHOST_USER_F_PROTOCOL_FEATURES)) {
> +        bool supports_f_config = vus->supports_config ||
> +            (dev->config_ops && dev->config_ops->vhost_dev_config_notifier);
> +        uint64_t protocol_features;
> +
>          dev->backend_features |= 1ULL << VHOST_USER_F_PROTOCOL_FEATURES;
>  
>          err = vhost_user_get_u64(dev, VHOST_USER_GET_PROTOCOL_FEATURES,
> @@ -1976,19 +1981,34 @@ static int vhost_user_backend_init(struct vhost_dev *dev, void *opaque,
>              return -EPROTO;
>          }
>  
> -        dev->protocol_features =
> -            protocol_features & VHOST_USER_PROTOCOL_FEATURE_MASK;
> -
> -        if (!dev->config_ops || !dev->config_ops->vhost_dev_config_notifier) {
> -            /* Don't acknowledge CONFIG feature if device doesn't support it */
> -            dev->protocol_features &= ~(1ULL << VHOST_USER_PROTOCOL_F_CONFIG);
> -        } else if (!(protocol_features &
> -                    (1ULL << VHOST_USER_PROTOCOL_F_CONFIG))) {
> -            error_setg(errp, "Device expects VHOST_USER_PROTOCOL_F_CONFIG "
> -                       "but backend does not support it.");
> -            return -EINVAL;
> +        /*
> +         * We will use all the protocol features we support - although
> +         * we suppress F_CONFIG if we know QEMUs internal code can not support
> +         * it.
> +         */
> +        protocol_features &= VHOST_USER_PROTOCOL_FEATURE_MASK;
> +
> +        if (supports_f_config) {
> +            if (!virtio_has_feature(protocol_features,
> +                                    VHOST_USER_PROTOCOL_F_CONFIG)) {
> +                error_setg(errp, "vhost-user device %s expecting "
> +                           "VHOST_USER_PROTOCOL_F_CONFIG but the vhost-user backend does "
> +                           "not support it.", dev->vdev->name);
> +                return -EPROTO;
> +            }
> +        } else {
> +            if (virtio_has_feature(protocol_features,
> +                                   VHOST_USER_PROTOCOL_F_CONFIG)) {
> +                warn_reportf_err(*errp, "vhost-user backend supports "
> +                                 "VHOST_USER_PROTOCOL_F_CONFIG for "
> +                                 "device %s but QEMU does not.",
> +                                 dev->vdev->name);
> +                protocol_features &= ~(1ULL << VHOST_USER_PROTOCOL_F_CONFIG);
> +            }
>          }
>  
> +        /* final set of protocol features */
> +        dev->protocol_features = protocol_features;
>          err = vhost_user_set_protocol_features(dev, dev->protocol_features);
>          if (err < 0) {
>              error_setg_errno(errp, EPROTO, "vhost_backend_init failed");
> -- 
> 2.30.2



  reply	other threads:[~2022-03-22 14:03 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-21 15:30 [PATCH v1 00/13] various virtio docs, fixes and tweaks Alex Bennée
2022-03-21 15:30 ` [Virtio-fs] [PATCH v1 01/13] hw/virtio: move virtio-pci.h into shared include space Alex Bennée
2022-03-21 15:30   ` Alex Bennée
2022-03-21 22:27   ` [Virtio-fs] " Philippe Mathieu-Daudé
2022-03-21 22:27     ` Philippe Mathieu-Daudé
2022-03-21 15:30 ` [PATCH v1 02/13] virtio-pci: add notification trace points Alex Bennée
2022-03-21 15:30 ` [PATCH v1 03/13] hw/virtio: add vhost_user_[read|write] " Alex Bennée
2022-03-21 22:29   ` Philippe Mathieu-Daudé
2022-03-21 15:30 ` [PATCH v1 04/13] docs: vhost-user: clean up request/reply description Alex Bennée
2022-03-21 22:30   ` Philippe Mathieu-Daudé
2022-03-21 15:30 ` [PATCH v1 05/13] docs: vhost-user: rewrite section on ring state machine Alex Bennée
2022-03-21 15:30 ` [PATCH v1 06/13] docs: vhost-user: replace master/slave with front-end/back-end Alex Bennée
2022-03-21 15:30 ` [PATCH v1 07/13] vhost-user.rst: add clarifying language about protocol negotiation Alex Bennée
2022-03-21 15:30 ` [PATCH v1 08/13] libvhost-user: expose vu_request_to_string Alex Bennée
2022-03-21 22:31   ` Philippe Mathieu-Daudé
2022-03-21 15:30 ` [PATCH v1 09/13] docs/devel: start documenting writing VirtIO devices Alex Bennée
2022-03-21 15:30 ` [PATCH v1 10/13] include/hw: start documenting the vhost API Alex Bennée
2022-03-21 15:30 ` [PATCH v1 11/13] contrib/vhost-user-blk: fix 32 bit build and enable Alex Bennée
2022-03-21 22:32   ` Philippe Mathieu-Daudé
2022-05-16 10:46     ` Alex Bennée
2022-03-21 15:30 ` [PATCH v1 12/13] hw/virtio/vhost-user: don't suppress F_CONFIG when supported Alex Bennée
2022-03-22 14:02   ` Michael S. Tsirkin [this message]
2022-03-22 15:54     ` Alex Bennée
2022-03-22 16:22       ` Michael S. Tsirkin
2022-03-21 15:30 ` [PATCH v1 13/13] virtio/vhost-user: dynamically assign VhostUserHostNotifiers Alex Bennée
2022-12-06 10:54   ` Philippe Mathieu-Daudé
2022-12-06 15:45   ` Stefan Hajnoczi
2022-03-22 13:56 ` [PATCH v1 00/13] various virtio docs, fixes and tweaks Michael S. Tsirkin
2022-03-22 15:50   ` Alex Bennée
2022-03-22 16:13     ` Michael S. Tsirkin
2022-05-13 10:15 ` Michael S. Tsirkin

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=20220322095720-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=fam@euphon.net \
    --cc=marcandre.lureau@redhat.com \
    --cc=mathieu.poirier@linaro.org \
    --cc=maxime.coquelin@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=raphael.norwitz@nutanix.com \
    --cc=slp@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=viresh.kumar@linaro.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.