From: Stefan Hajnoczi <stefanha@redhat.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: virtio-fs@redhat.com, miklos@szeredi.hu, qemu-devel@nongnu.org,
dgilbert@redhat.com
Subject: Re: [PATCH 3/4] virtiofsd: Specify size of notification buffer using config space
Date: Fri, 22 Nov 2019 10:33:00 +0000 [thread overview]
Message-ID: <20191122103300.GD464656@stefanha-x1.localdomain> (raw)
In-Reply-To: <20191115205543.1816-4-vgoyal@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 4180 bytes --]
On Fri, Nov 15, 2019 at 03:55:42PM -0500, Vivek Goyal wrote:
> diff --git a/contrib/virtiofsd/fuse_virtio.c b/contrib/virtiofsd/fuse_virtio.c
> index 411114c9b3..982b6ad0bd 100644
> --- a/contrib/virtiofsd/fuse_virtio.c
> +++ b/contrib/virtiofsd/fuse_virtio.c
> @@ -109,7 +109,8 @@ static uint64_t fv_get_features(VuDev *dev)
> uint64_t features;
>
> features = 1ull << VIRTIO_F_VERSION_1 |
> - 1ull << VIRTIO_FS_F_NOTIFICATION;
> + 1ull << VIRTIO_FS_F_NOTIFICATION |
> + 1ull << VHOST_USER_F_PROTOCOL_FEATURES;
This is not needed since VHOST_USER_F_PROTOCOL_FEATURES is already added
by vu_get_features_exec():
vu_get_features_exec(VuDev *dev, VhostUserMsg *vmsg)
{
vmsg->payload.u64 =
1ULL << VHOST_F_LOG_ALL |
1ULL << VHOST_USER_F_PROTOCOL_FEATURES;
if (dev->iface->get_features) {
vmsg->payload.u64 |= dev->iface->get_features(dev);
}
>
> return features;
> }
> @@ -927,6 +928,27 @@ static bool fv_queue_order(VuDev *dev, int qidx)
> return false;
> }
>
> +static uint64_t fv_get_protocol_features(VuDev *dev)
> +{
> + return 1ull << VHOST_USER_PROTOCOL_F_CONFIG;
> +}
Please change vu_get_protocol_features_exec() in a separate patch so
that devices don't need this boilerplate .get_protocol_features() code:
static bool
vu_get_protocol_features_exec(VuDev *dev, VhostUserMsg *vmsg)
{
...
- if (dev->iface->get_config && dev->iface->set_config) {
+ if (dev->iface->get_config || dev->iface->set_config) {
features |= 1ULL << VHOST_USER_PROTOCOL_F_CONFIG;
}
> +
> +static int fv_get_config(VuDev *dev, uint8_t *config, uint32_t len)
> +{
> + struct virtio_fs_config fscfg = {};
> +
> + fuse_log(FUSE_LOG_DEBUG, "%s:Setting notify_buf_size=%d\n", __func__,
> + sizeof(struct fuse_notify_lock_out));
> + /*
> + * As of now only notification related to lock is supported. As more
> + * notification types are supported, bump up the size accordingly.
> + */
> + fscfg.notify_buf_size = sizeof(struct fuse_notify_lock_out);
Missing cpu_to_le32().
I'm not sure about specifying the size precisely down to the last byte
because any change to guest-visible aspects of the device (like VIRTIO
Configuration Space) are not compatible across live migration. It will
be necessary to introduce a device version command-line option for live
migration compatibility so that existing guests can be migrated to a new
virtiofsd without the device changing underneath them.
How about rounding this up to 4 KB?
> static void vuf_get_config(VirtIODevice *vdev, uint8_t *config)
> {
> VHostUserFS *fs = VHOST_USER_FS(vdev);
> struct virtio_fs_config fscfg = {};
> + int ret;
> +
> + /*
> + * As of now we only get notification buffer size from device. And that's
> + * needed only if notification queue is enabled.
> + */
> + if (fs->notify_enabled) {
> + ret = vhost_dev_get_config(&fs->vhost_dev, (uint8_t *)&fs->fscfg,
> + sizeof(struct virtio_fs_config));
> + if (ret < 0) {
Indentation.
> + error_report("vhost-user-fs: get device config space failed."
> + " ret=%d\n", ret);
> + return;
> + }
Missing le32_to_cpu() for notify_buf_size.
> + }
>
> memcpy((char *)fscfg.tag, fs->conf.tag,
> MIN(strlen(fs->conf.tag) + 1, sizeof(fscfg.tag)));
>
> virtio_stl_p(vdev, &fscfg.num_request_queues, fs->conf.num_request_queues);
> + virtio_stl_p(vdev, &fscfg.notify_buf_size, fs->fscfg.notify_buf_size);
>
> memcpy(config, &fscfg, sizeof(fscfg));
> }
> @@ -545,6 +569,8 @@ static void vuf_device_realize(DeviceState *dev, Error **errp)
> fs->vhost_dev.nvqs = 2 + fs->conf.num_request_queues;
>
> fs->vhost_dev.vqs = g_new0(struct vhost_virtqueue, fs->vhost_dev.nvqs);
> +
> + vhost_dev_set_config_notifier(&fs->vhost_dev, &fs_ops);
Is this really needed since vhost_user_fs_handle_config_change() ignores
it?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-11-22 10:34 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-15 20:55 [PATCH 0/4] [RFC] virtiofsd, vhost-user-fs: Add support for notification queue Vivek Goyal
2019-11-15 20:55 ` [PATCH 1/4] virtiofsd: Release file locks using F_UNLCK Vivek Goyal
2019-11-22 10:07 ` Stefan Hajnoczi
2019-11-22 13:45 ` Vivek Goyal
2019-11-15 20:55 ` [PATCH 2/4] virtiofd: Create a notification queue Vivek Goyal
2019-11-22 10:19 ` Stefan Hajnoczi
2019-11-22 14:47 ` Vivek Goyal
2019-11-22 17:29 ` Dr. David Alan Gilbert
2019-11-15 20:55 ` [PATCH 3/4] virtiofsd: Specify size of notification buffer using config space Vivek Goyal
2019-11-22 10:33 ` Stefan Hajnoczi [this message]
2019-11-25 14:57 ` Vivek Goyal
2019-11-15 20:55 ` [PATCH 4/4] virtiofsd: Implement blocking posix locks Vivek Goyal
2019-11-22 10:53 ` Stefan Hajnoczi
2019-11-25 15:38 ` [Virtio-fs] " Vivek Goyal
2019-11-22 17:47 ` Dr. David Alan Gilbert
2019-11-25 15:44 ` [Virtio-fs] " Vivek Goyal
2019-11-26 13:02 ` Dr. David Alan Gilbert
2019-11-27 19:08 ` Vivek Goyal
2019-12-09 11:06 ` Dr. David Alan Gilbert
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=20191122103300.GD464656@stefanha-x1.localdomain \
--to=stefanha@redhat.com \
--cc=dgilbert@redhat.com \
--cc=miklos@szeredi.hu \
--cc=qemu-devel@nongnu.org \
--cc=vgoyal@redhat.com \
--cc=virtio-fs@redhat.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).