From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: qemu-devel@nongnu.org, stefanha@redhat.com, vgoyal@redhat.com
Subject: Re: [Qemu-devel] [PATCH 1/2] virtio: add vhost-user-fs base device
Date: Wed, 21 Aug 2019 20:11:18 +0100 [thread overview]
Message-ID: <20190821191118.GN3309@work-vm> (raw)
In-Reply-To: <20190818065944-mutt-send-email-mst@kernel.org>
* Michael S. Tsirkin (mst@redhat.com) wrote:
> On Fri, Aug 16, 2019 at 03:33:20PM +0100, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> >
> > The virtio-fs virtio device provides shared file system access using
> > the FUSE protocol carried ovew virtio.
> > The actual file server is implemented in an external vhost-user-fs device
> > backend process.
> >
> > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> > Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
> > Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
> > ---
> > configure | 13 +
> > hw/virtio/Makefile.objs | 1 +
> > hw/virtio/vhost-user-fs.c | 297 ++++++++++++++++++++
> > include/hw/virtio/vhost-user-fs.h | 45 +++
> > include/standard-headers/linux/virtio_fs.h | 41 +++
> > include/standard-headers/linux/virtio_ids.h | 1 +
> > 6 files changed, 398 insertions(+)
> > create mode 100644 hw/virtio/vhost-user-fs.c
> > create mode 100644 include/hw/virtio/vhost-user-fs.h
> > create mode 100644 include/standard-headers/linux/virtio_fs.h
> >
> > diff --git a/configure b/configure
> > index 714e7fb6a1..e7e33ee783 100755
> > --- a/configure
> > +++ b/configure
> > @@ -382,6 +382,7 @@ vhost_crypto=""
> > vhost_scsi=""
> > vhost_vsock=""
> > vhost_user=""
> > +vhost_user_fs=""
> > kvm="no"
> > hax="no"
> > hvf="no"
> > @@ -1316,6 +1317,10 @@ for opt do
> > ;;
> > --enable-vhost-vsock) vhost_vsock="yes"
> > ;;
> > + --disable-vhost-user-fs) vhost_user_fs="no"
> > + ;;
> > + --enable-vhost-user-fs) vhost_user_fs="yes"
> > + ;;
> > --disable-opengl) opengl="no"
> > ;;
> > --enable-opengl) opengl="yes"
> > @@ -2269,6 +2274,10 @@ test "$vhost_crypto" = "" && vhost_crypto=$vhost_user
> > if test "$vhost_crypto" = "yes" && test "$vhost_user" = "no"; then
> > error_exit "--enable-vhost-crypto requires --enable-vhost-user"
> > fi
> > +test "$vhost_user_fs" = "" && vhost_user_fs=$vhost_user
> > +if test "$vhost_user_fs" = "yes" && test "$vhost_user" = "no"; then
> > + error_exit "--enable-vhost-user-fs requires --enable-vhost-user"
> > +fi
> >
> > # OR the vhost-kernel and vhost-user values for simplicity
> > if test "$vhost_net" = ""; then
> > @@ -6425,6 +6434,7 @@ echo "vhost-crypto support $vhost_crypto"
> > echo "vhost-scsi support $vhost_scsi"
> > echo "vhost-vsock support $vhost_vsock"
> > echo "vhost-user support $vhost_user"
> > +echo "vhost-user-fs support $vhost_user_fs"
> > echo "Trace backends $trace_backends"
> > if have_backend "simple"; then
> > echo "Trace output file $trace_file-<pid>"
> > @@ -6921,6 +6931,9 @@ fi
> > if test "$vhost_user" = "yes" ; then
> > echo "CONFIG_VHOST_USER=y" >> $config_host_mak
> > fi
> > +if test "$vhost_user_fs" = "yes" ; then
> > + echo "CONFIG_VHOST_USER_FS=y" >> $config_host_mak
> > +fi
> > if test "$blobs" = "yes" ; then
> > echo "INSTALL_BLOBS=yes" >> $config_host_mak
> > fi
> > diff --git a/hw/virtio/Makefile.objs b/hw/virtio/Makefile.objs
> > index 964ce78607..47ffbf22c4 100644
> > --- a/hw/virtio/Makefile.objs
> > +++ b/hw/virtio/Makefile.objs
> > @@ -11,6 +11,7 @@ common-obj-$(CONFIG_VIRTIO_PCI) += virtio-pci.o
> > common-obj-$(CONFIG_VIRTIO_MMIO) += virtio-mmio.o
> > obj-$(CONFIG_VIRTIO_BALLOON) += virtio-balloon.o
> > obj-$(CONFIG_VIRTIO_CRYPTO) += virtio-crypto.o
> > +obj-$(CONFIG_VHOST_USER_FS) += vhost-user-fs.o
> > obj-$(call land,$(CONFIG_VIRTIO_CRYPTO),$(CONFIG_VIRTIO_PCI)) += virtio-crypto-pci.o
> > obj-$(CONFIG_VIRTIO_PMEM) += virtio-pmem.o
> > common-obj-$(call land,$(CONFIG_VIRTIO_PMEM),$(CONFIG_VIRTIO_PCI)) += virtio-pmem-pci.o
> > diff --git a/hw/virtio/vhost-user-fs.c b/hw/virtio/vhost-user-fs.c
> > new file mode 100644
> > index 0000000000..2753c2c07a
> > --- /dev/null
> > +++ b/hw/virtio/vhost-user-fs.c
> > @@ -0,0 +1,297 @@
> > +/*
> > + * Vhost-user filesystem virtio device
> > + *
> > + * Copyright 2018 Red Hat, Inc.
> > + *
> > + * Authors:
> > + * Stefan Hajnoczi <stefanha@redhat.com>
> > + *
> > + * This work is licensed under the terms of the GNU GPL, version 2 or
> > + * (at your option) any later version. See the COPYING file in the
> > + * top-level directory.
> > + */
> > +
> > +#include "qemu/osdep.h"
> > +#include <sys/ioctl.h>
> > +#include "standard-headers/linux/virtio_fs.h"
> > +#include "qapi/error.h"
> > +#include "hw/virtio/virtio-bus.h"
> > +#include "hw/virtio/virtio-access.h"
> > +#include "qemu/error-report.h"
> > +#include "hw/virtio/vhost-user-fs.h"
> > +#include "monitor/monitor.h"
> > +
> > +static void vuf_get_config(VirtIODevice *vdev, uint8_t *config)
> > +{
> > + VHostUserFS *fs = VHOST_USER_FS(vdev);
> > + struct virtio_fs_config fscfg = {};
> > +
> > + memcpy((char *)fscfg.tag, fs->conf.tag,
> > + MIN(strlen(fs->conf.tag) + 1, sizeof(fscfg.tag)));
> > +
> > + virtio_stl_p(vdev, &fscfg.num_queues, fs->conf.num_queues);
> > +
> > + memcpy(config, &fscfg, sizeof(fscfg));
> > +}
> > +
> > +static void vuf_start(VirtIODevice *vdev)
> > +{
> > + VHostUserFS *fs = VHOST_USER_FS(vdev);
> > + BusState *qbus = BUS(qdev_get_parent_bus(DEVICE(vdev)));
> > + VirtioBusClass *k = VIRTIO_BUS_GET_CLASS(qbus);
> > + int ret;
> > + int i;
> > +
> > + if (!k->set_guest_notifiers) {
> > + error_report("binding does not support guest notifiers");
> > + return;
> > + }
> > +
> > + ret = vhost_dev_enable_notifiers(&fs->vhost_dev, vdev);
> > + if (ret < 0) {
> > + error_report("Error enabling host notifiers: %d", -ret);
> > + return;
> > + }
> > +
> > + ret = k->set_guest_notifiers(qbus->parent, fs->vhost_dev.nvqs, true);
> > + if (ret < 0) {
> > + error_report("Error binding guest notifier: %d", -ret);
> > + goto err_host_notifiers;
> > + }
> > +
> > + fs->vhost_dev.acked_features = vdev->guest_features;
> > + ret = vhost_dev_start(&fs->vhost_dev, vdev);
> > + if (ret < 0) {
> > + error_report("Error starting vhost: %d", -ret);
> > + goto err_guest_notifiers;
> > + }
> > +
> > + /*
> > + * guest_notifier_mask/pending not used yet, so just unmask
> > + * everything here. virtio-pci will do the right thing by
> > + * enabling/disabling irqfd.
> > + */
> > + for (i = 0; i < fs->vhost_dev.nvqs; i++) {
> > + vhost_virtqueue_mask(&fs->vhost_dev, vdev, i, false);
> > + }
> > +
> > + return;
> > +
> > +err_guest_notifiers:
> > + k->set_guest_notifiers(qbus->parent, fs->vhost_dev.nvqs, false);
> > +err_host_notifiers:
> > + vhost_dev_disable_notifiers(&fs->vhost_dev, vdev);
> > +}
> > +
> > +static void vuf_stop(VirtIODevice *vdev)
> > +{
> > + VHostUserFS *fs = VHOST_USER_FS(vdev);
> > + BusState *qbus = BUS(qdev_get_parent_bus(DEVICE(vdev)));
> > + VirtioBusClass *k = VIRTIO_BUS_GET_CLASS(qbus);
> > + int ret;
> > +
> > + if (!k->set_guest_notifiers) {
> > + return;
> > + }
> > +
> > + vhost_dev_stop(&fs->vhost_dev, vdev);
> > +
> > + ret = k->set_guest_notifiers(qbus->parent, fs->vhost_dev.nvqs, false);
> > + if (ret < 0) {
> > + error_report("vhost guest notifier cleanup failed: %d", ret);
> > + return;
> > + }
> > +
> > + vhost_dev_disable_notifiers(&fs->vhost_dev, vdev);
> > +}
> > +
> > +static void vuf_set_status(VirtIODevice *vdev, uint8_t status)
> > +{
> > + VHostUserFS *fs = VHOST_USER_FS(vdev);
> > + bool should_start = status & VIRTIO_CONFIG_S_DRIVER_OK;
> > +
> > + if (!vdev->vm_running) {
> > + should_start = false;
> > + }
> > +
> > + if (fs->vhost_dev.started == should_start) {
> > + return;
> > + }
> > +
> > + if (should_start) {
> > + vuf_start(vdev);
> > + } else {
> > + vuf_stop(vdev);
> > + }
> > +}
> > +
> > +static uint64_t vuf_get_features(VirtIODevice *vdev,
> > + uint64_t requested_features,
> > + Error **errp)
> > +{
> > + /* No feature bits used yet */
> > + return requested_features;
> > +}
> > +
> > +static void vuf_handle_output(VirtIODevice *vdev, VirtQueue *vq)
> > +{
> > + /* Do nothing */
>
> Why is this safe? Is this because this never triggers? assert(0) then?
> If it triggers then backend won't be notified, which might
> cause it to get stuck.
We never process these queues in qemu - always in the guest; so am I
correct in thinking those shouldn't be used?
> > +}
> > +
> > +static void vuf_guest_notifier_mask(VirtIODevice *vdev, int idx,
> > + bool mask)
> > +{
> > + VHostUserFS *fs = VHOST_USER_FS(vdev);
> > +
> > + vhost_virtqueue_mask(&fs->vhost_dev, vdev, idx, mask);
> > +}
> > +
> > +static bool vuf_guest_notifier_pending(VirtIODevice *vdev, int idx)
> > +{
> > + VHostUserFS *fs = VHOST_USER_FS(vdev);
> > +
> > + return vhost_virtqueue_pending(&fs->vhost_dev, idx);
> > +}
> > +
> > +static void vuf_device_realize(DeviceState *dev, Error **errp)
> > +{
> > + VirtIODevice *vdev = VIRTIO_DEVICE(dev);
> > + VHostUserFS *fs = VHOST_USER_FS(dev);
> > + unsigned int i;
> > + size_t len;
> > + int ret;
> > +
> > + if (!fs->conf.chardev.chr) {
> > + error_setg(errp, "missing chardev");
> > + return;
> > + }
> > +
> > + if (!fs->conf.tag) {
> > + error_setg(errp, "missing tag property");
> > + return;
> > + }
> > + len = strlen(fs->conf.tag);
> > + if (len == 0) {
> > + error_setg(errp, "tag property cannot be empty");
> > + return;
> > + }
> > + if (len > sizeof_field(struct virtio_fs_config, tag)) {
> > + error_setg(errp, "tag property must be %zu bytes or less",
> > + sizeof_field(struct virtio_fs_config, tag));
> > + return;
> > + }
> > +
> > + if (fs->conf.num_queues == 0) {
> > + error_setg(errp, "num-queues property must be larger than 0");
> > + return;
> > + }
>
> The strange thing is that actual # of queues is this number + 2.
> And this affects an optimal number of vectors (see patch 2).
> Not sure what a good solution is - include the
> mandatory queues in the number?
> Needs to be documented in some way.
Should we be doing nvectors the same way virtio-scsi-pci does it;
with a magic 'unspecified' default where it sets the nvectors based on
the number of queues?
I think my preference is not to show the users the mandatory queues.
> > +
> > + if (!is_power_of_2(fs->conf.queue_size)) {
> > + error_setg(errp, "queue-size property must be a power of 2");
> > + return;
> > + }
>
> Hmm packed ring allows non power of 2 ...
> We need to look into a generic helper to support VQ
> size checks.
Which would also have to include the negotiation of where it's doing
packaged ring?
<snip>
Dave
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2019-08-21 19:12 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-16 14:33 [Qemu-devel] [PATCH 0/2] Add virtio-fs (experimental) Dr. David Alan Gilbert (git)
2019-08-16 14:33 ` [Qemu-devel] [PATCH 1/2] virtio: add vhost-user-fs base device Dr. David Alan Gilbert (git)
2019-08-18 11:08 ` Michael S. Tsirkin
2019-08-20 12:24 ` Cornelia Huck
2019-08-20 13:39 ` Dr. David Alan Gilbert
2019-08-21 17:52 ` Dr. David Alan Gilbert
2019-08-21 19:11 ` Dr. David Alan Gilbert [this message]
2019-08-22 8:52 ` Stefan Hajnoczi
2019-08-22 9:19 ` Cornelia Huck
2019-08-23 9:25 ` Stefan Hajnoczi
2019-09-17 9:21 ` Dr. David Alan Gilbert
2019-08-16 14:33 ` [Qemu-devel] [PATCH 2/2] virtio: add vhost-user-fs-pci device Dr. David Alan Gilbert (git)
2019-08-16 18:38 ` [Qemu-devel] [PATCH 0/2] Add virtio-fs (experimental) no-reply
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=20190821191118.GN3309@work-vm \
--to=dgilbert@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=vgoyal@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).