From: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: kvm@vger.kernel.org, linux-remoteproc@vger.kernel.org,
virtualization@lists.linux-foundation.org,
sound-open-firmware@alsa-project.org,
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
Liam Girdwood <liam.r.girdwood@linux.intel.com>,
Jason Wang <jasowang@redhat.com>,
Ohad Ben-Cohen <ohad@wizery.com>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Mathieu Poirier <mathieu.poirier@linaro.org>,
Vincent Whitchurch <vincent.whitchurch@axis.com>
Subject: Re: [PATCH v4 4/4] vhost: add an RPMsg API
Date: Tue, 4 Aug 2020 17:19:17 +0200 [thread overview]
Message-ID: <20200804151916.GC19025@ubuntu> (raw)
In-Reply-To: <20200804102132-mutt-send-email-mst@kernel.org>
On Tue, Aug 04, 2020 at 10:27:08AM -0400, Michael S. Tsirkin wrote:
> On Wed, Jul 22, 2020 at 05:09:27PM +0200, Guennadi Liakhovetski wrote:
> > Linux supports running the RPMsg protocol over the VirtIO transport
> > protocol, but currently there is only support for VirtIO clients and
> > no support for a VirtIO server. This patch adds a vhost-based RPMsg
> > server implementation.
> >
> > Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
> > ---
> > drivers/vhost/Kconfig | 7 +
> > drivers/vhost/Makefile | 3 +
> > drivers/vhost/rpmsg.c | 375 ++++++++++++++++++++++++++++++++++++
> > drivers/vhost/vhost_rpmsg.h | 74 +++++++
> > 4 files changed, 459 insertions(+)
> > create mode 100644 drivers/vhost/rpmsg.c
> > create mode 100644 drivers/vhost/vhost_rpmsg.h
> >
> > diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
> > index d3688c6afb87..602421bf1d03 100644
> > --- a/drivers/vhost/Kconfig
> > +++ b/drivers/vhost/Kconfig
> > @@ -38,6 +38,13 @@ config VHOST_NET
> > To compile this driver as a module, choose M here: the module will
> > be called vhost_net.
> >
> > +config VHOST_RPMSG
> > + tristate
>
> So this lacks a description line so it does not appear
> in menuconfig. How is user supposed to set it?
> I added a one-line description.
That was on purpose. I don't think there's any value in this API stand-alone,
so I let users select it as needed. But we can change that too, id desired.
> > + depends on VHOST
>
> Other drivers select VHOST instead. Any reason not to
> do it like this here?
I have
+ select VHOST
+ select VHOST_RPMSG
in my client driver patch.
> > + help
> > + Vhost RPMsg API allows vhost drivers to communicate with VirtIO
> > + drivers, using the RPMsg over VirtIO protocol.
> > +
>
> > config VHOST_SCSI
> > tristate "VHOST_SCSI TCM fabric driver"
> > depends on TARGET_CORE && EVENTFD
> > diff --git a/drivers/vhost/Makefile b/drivers/vhost/Makefile
> > index f3e1897cce85..9cf459d59f97 100644
> > --- a/drivers/vhost/Makefile
> > +++ b/drivers/vhost/Makefile
> > @@ -2,6 +2,9 @@
> > obj-$(CONFIG_VHOST_NET) += vhost_net.o
> > vhost_net-y := net.o
> >
> > +obj-$(CONFIG_VHOST_RPMSG) += vhost_rpmsg.o
> > +vhost_rpmsg-y := rpmsg.o
> > +
> > obj-$(CONFIG_VHOST_SCSI) += vhost_scsi.o
> > vhost_scsi-y := scsi.o
> >
> > diff --git a/drivers/vhost/rpmsg.c b/drivers/vhost/rpmsg.c
> > new file mode 100644
> > index 000000000000..d7ab48414224
> > --- /dev/null
> > +++ b/drivers/vhost/rpmsg.c
> > @@ -0,0 +1,375 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright(c) 2020 Intel Corporation. All rights reserved.
> > + *
> > + * Author: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
> > + *
> > + * Vhost RPMsg VirtIO interface. It provides a set of functions to match the
> > + * guest side RPMsg VirtIO API, provided by drivers/rpmsg/virtio_rpmsg_bus.c
> > + * These functions handle creation of 2 virtual queues, handling of endpoint
> > + * addresses, sending a name-space announcement to the guest as well as any
> > + * user messages. This API can be used by any vhost driver to handle RPMsg
> > + * specific processing.
> > + * Specific vhost drivers, using this API will use their own VirtIO device
> > + * IDs, that should then also be added to the ID table in virtio_rpmsg_bus.c
> > + */
> > +
> > +#include <linux/compat.h>
> > +#include <linux/file.h>
> > +#include <linux/miscdevice.h>
> > +#include <linux/module.h>
> > +#include <linux/mutex.h>
> > +#include <linux/vhost.h>
> > +#include <linux/virtio_rpmsg.h>
> > +#include <uapi/linux/rpmsg.h>
> > +
> > +#include "vhost.h"
> > +#include "vhost_rpmsg.h"
> > +
> > +/*
> > + * All virtio-rpmsg virtual queue kicks always come with just one buffer -
> > + * either input or output
> > + */
> > +static int vhost_rpmsg_get_single(struct vhost_virtqueue *vq)
> > +{
> > + struct vhost_rpmsg *vr = container_of(vq->dev, struct vhost_rpmsg, dev);
> > + unsigned int out, in;
> > + int head = vhost_get_vq_desc(vq, vq->iov, ARRAY_SIZE(vq->iov), &out, &in,
> > + NULL, NULL);
> > + if (head < 0) {
> > + vq_err(vq, "%s(): error %d getting buffer\n",
> > + __func__, head);
> > + return head;
> > + }
> > +
> > + /* Nothing new? */
> > + if (head == vq->num)
> > + return head;
> > +
> > + if (vq == &vr->vq[VIRTIO_RPMSG_RESPONSE] && (out || in != 1)) {
>
> This in != 1 looks like a dependency on a specific message layout.
> virtio spec says to avoid these. Using iov iters it's not too hard to do
> ...
This is an RPMsg VirtIO implementation, and it has to match the virtio_rpmsg_bus.c
driver, and that one has specific VirtIO queue and message usage patterns.
> > + vq_err(vq,
> > + "%s(): invalid %d input and %d output in response queue\n",
> > + __func__, in, out);
> > + goto return_buf;
> > + }
> > +
> > + if (vq == &vr->vq[VIRTIO_RPMSG_REQUEST] && (in || out != 1)) {
> > + vq_err(vq,
> > + "%s(): invalid %d input and %d output in request queue\n",
> > + __func__, in, out);
> > + goto return_buf;
> > + }
> > +
> > + return head;
> > +
> > +return_buf:
> > + /*
> > + * FIXME: might need to return the buffer using vhost_add_used()
> > + * or vhost_discard_vq_desc(). vhost_discard_vq_desc() is
> > + * described as "being useful for error handling," but it makes
> > + * the thus discarded buffers "unseen," so next time we look we
> > + * retrieve them again?
>
>
> Yes. It's your decision what to do on error. if you also signal
> an eventfd using vq_err, then discarding will
> make it so userspace can poke at ring and hopefully fix it ...
I assume the user-space in this case is QEMU. Would it be the safest to use
vhost_add_used() then?
> > + */
> > + return -EINVAL;
> > +}
[snip]
> > + return 0;
> > +
> > +return_buf:
> > + /*
> > + * FIXME: vhost_discard_vq_desc() or vhost_add_used(), see comment in
> > + * vhost_rpmsg_get_single()
> > + */
>
> What's to be done with this FIXME?
This is the same question as above - I just wasn't sure which error handling
was appropriate here, don't think many vhost drivers do any od this...
Thanks
Guennadi
next prev parent reply other threads:[~2020-08-04 15:19 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-22 15:09 [PATCH v4 0/4] Add a vhost RPMsg API Guennadi Liakhovetski
2020-07-22 15:09 ` [PATCH v4 1/4] vhost: convert VHOST_VSOCK_SET_RUNNING to a generic ioctl Guennadi Liakhovetski
2020-07-23 8:34 ` Stefano Garzarella
2020-07-22 15:09 ` [PATCH v4 2/4] rpmsg: move common structures and defines to headers Guennadi Liakhovetski
2020-08-11 17:51 ` Mathieu Poirier
2020-07-22 15:09 ` [PATCH v4 3/4] rpmsg: update documentation Guennadi Liakhovetski
2020-07-22 15:09 ` [PATCH v4 4/4] vhost: add an RPMsg API Guennadi Liakhovetski
2020-08-04 14:27 ` Michael S. Tsirkin
2020-08-04 15:19 ` Guennadi Liakhovetski [this message]
2020-08-10 13:44 ` Michael S. Tsirkin
2020-08-12 12:32 ` Guennadi Liakhovetski
2020-08-25 13:41 ` Guennadi Liakhovetski
2020-08-25 13:53 ` Michael S. Tsirkin
2020-07-30 16:08 ` [PATCH v4 0/4] Add a vhost " Michael S. Tsirkin
2020-07-31 5:47 ` Guennadi Liakhovetski
2020-08-03 13:25 ` Mathieu Poirier
2020-08-03 20:46 ` Michael S. Tsirkin
2020-08-04 13:37 ` Mathieu Poirier
2020-08-04 14:07 ` Michael S. Tsirkin
2020-08-04 19:30 ` Mathieu Poirier
2020-08-05 11:34 ` Michael S. Tsirkin
2020-08-04 12:26 ` Michael S. Tsirkin
2020-08-04 13:19 ` Guennadi Liakhovetski
2020-08-04 14:10 ` Michael S. Tsirkin
2020-08-04 14:46 ` Guennadi Liakhovetski
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=20200804151916.GC19025@ubuntu \
--to=guennadi.liakhovetski@linux.intel.com \
--cc=bjorn.andersson@linaro.org \
--cc=jasowang@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=liam.r.girdwood@linux.intel.com \
--cc=linux-remoteproc@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=mst@redhat.com \
--cc=ohad@wizery.com \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=sound-open-firmware@alsa-project.org \
--cc=vincent.whitchurch@axis.com \
--cc=virtualization@lists.linux-foundation.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 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).