From: "Alex Bennée" <alex.bennee@linaro.org>
To: Yajun Wu <yajunw@nvidia.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"mst@redhat.com" <mst@redhat.com>,
Parav Pandit <parav@nvidia.com>
Subject: Re: [PATCH v2 1/4] hw/virtio: incorporate backend features in features
Date: Wed, 26 Oct 2022 08:41:53 +0100 [thread overview]
Message-ID: <877d0n58t6.fsf@linaro.org> (raw)
In-Reply-To: <DM4PR12MB5168A6071D5A3A961E0CCB69B6309@DM4PR12MB5168.namprd12.prod.outlook.com>
Yajun Wu <yajunw@nvidia.com> writes:
> Hi Alex,
>
> With this change, VHOST_USER_F_PROTOCOL_FEATURES bit will be set to
> backend for virtio block device (previously not).
>
> From https://www.qemu.org/docs/master/interop/vhost-user.html spec:
> If VHOST_USER_F_PROTOCOL_FEATURES has not been negotiated, the ring starts directly in the enabled state.
> If VHOST_USER_F_PROTOCOL_FEATURES has been negotiated, the ring is
> initialized in a disabled state and is enabled by
> VHOST_USER_SET_VRING_ENABLE with parameter 1.
>
> Vhost-user-blk won't send out VHOST_USER_SET_VRING_ENABLE today.
> Backend gets VHOST_USER_F_PROTOCOL_FEATURES negotiated and can't get VHOST_USER_SET_VRING_ENABLE.
> VQs keep in disabled state.
If the backend advertises protocol features but the stub doesn't support
it how does it get enabled?
The testing I did was mostly by hand with the gpio backend and using the
qtests. I Think we need to add some acceptance testing into avocado with
some real daemons because I don't think we have enough coverage with the
current qtest approach.
>
> Can you check on this scenario?
>
> Thanks
>
> -----Original Message-----
> From: Qemu-devel <qemu-devel-bounces+yajunw=nvidia.com@nongnu.org> On Behalf Of Alex Bennée
> Sent: Thursday, July 28, 2022 9:55 PM
> To: qemu-devel@nongnu.org
> Cc: mst@redhat.com; Alex Bennée <alex.bennee@linaro.org>
> Subject: [PATCH v2 1/4] hw/virtio: incorporate backend features in features
>
> External email: Use caution opening links or attachments
>
>
> There are some extra bits used over a vhost-user connection which are hidden from the device itself. We need to set them here to ensure we enable things like the protocol extensions.
>
> Currently net/vhost-user.c has it's own inscrutable way of persisting this data but it really should live in the core vhost_user code.
>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> Message-Id: <20220726192150.2435175-7-alex.bennee@linaro.org>
> ---
> hw/virtio/vhost-user.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c index 75b8df21a4..1936a44e82 100644
> --- a/hw/virtio/vhost-user.c
> +++ b/hw/virtio/vhost-user.c
> @@ -1460,7 +1460,14 @@ static int vhost_user_set_features(struct vhost_dev *dev,
> */
> bool log_enabled = features & (0x1ULL << VHOST_F_LOG_ALL);
>
> - return vhost_user_set_u64(dev, VHOST_USER_SET_FEATURES, features,
> + /*
> + * We need to include any extra backend only feature bits that
> + * might be needed by our device. Currently this includes the
> + * VHOST_USER_F_PROTOCOL_FEATURES bit for enabling protocol
> + * features.
> + */
> + return vhost_user_set_u64(dev, VHOST_USER_SET_FEATURES,
> + features | dev->backend_features,
> log_enabled); }
--
Alex Bennée
next prev parent reply other threads:[~2022-10-26 7:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-28 13:54 [PATCH for 7.1 v2 0/4] virtio fixes (split from virtio-gpio series) Alex Bennée
2022-07-28 13:55 ` [PATCH v2 1/4] hw/virtio: incorporate backend features in features Alex Bennée
2022-08-17 11:00 ` Michael S. Tsirkin
2022-10-26 6:11 ` Yajun Wu
2022-10-26 7:41 ` Alex Bennée [this message]
2022-11-10 10:35 ` Yajun Wu
2022-07-28 13:55 ` [PATCH v2 2/4] hw/virtio: gracefully handle unset vhost_dev vdev Alex Bennée
2022-08-17 11:01 ` Michael S. Tsirkin
2022-08-18 6:35 ` Alex Bennée
2022-07-28 13:55 ` [PATCH v2 3/4] hw/virtio: handle un-configured shutdown in virtio-pci Alex Bennée
2022-07-28 13:55 ` [PATCH v2 4/4] hw/virtio: fix vhost_user_read tracepoint Alex Bennée
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=877d0n58t6.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=mst@redhat.com \
--cc=parav@nvidia.com \
--cc=qemu-devel@nongnu.org \
--cc=yajunw@nvidia.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 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.