From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.5 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F1383C433E0 for ; Tue, 4 Aug 2020 15:19:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E344B2086A for ; Tue, 4 Aug 2020 15:19:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729496AbgHDPTX (ORCPT ); Tue, 4 Aug 2020 11:19:23 -0400 Received: from mga12.intel.com ([192.55.52.136]:65135 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728586AbgHDPTX (ORCPT ); Tue, 4 Aug 2020 11:19:23 -0400 IronPort-SDR: MqdE98bm7iYYL8NZZbiCdMdTnf8B/+NRs0cXSJ3NOYbkNHD8jjzZ/Eg2jcQgyHGEemf8L36/e0 JAGwHpqfBNqg== X-IronPort-AV: E=McAfee;i="6000,8403,9703"; a="131894842" X-IronPort-AV: E=Sophos;i="5.75,434,1589266800"; d="scan'208";a="131894842" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2020 08:19:21 -0700 IronPort-SDR: W+0vT9pAMJBlKPN8WWB96VYU+kRNXdEUZ7vCtbaQQAlMLFNnvV0fPnuBjQUVihn0RRt51v9QU5 8jZKh7RTmSTA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,434,1589266800"; d="scan'208";a="292606786" Received: from gliakhov-mobl2.ger.corp.intel.com (HELO ubuntu) ([10.252.37.210]) by orsmga006.jf.intel.com with ESMTP; 04 Aug 2020 08:19:18 -0700 Date: Tue, 4 Aug 2020 17:19:17 +0200 From: Guennadi Liakhovetski To: "Michael S. Tsirkin" Cc: kvm@vger.kernel.org, linux-remoteproc@vger.kernel.org, virtualization@lists.linux-foundation.org, sound-open-firmware@alsa-project.org, Pierre-Louis Bossart , Liam Girdwood , Jason Wang , Ohad Ben-Cohen , Bjorn Andersson , Mathieu Poirier , Vincent Whitchurch Subject: Re: [PATCH v4 4/4] vhost: add an RPMsg API Message-ID: <20200804151916.GC19025@ubuntu> References: <20200722150927.15587-1-guennadi.liakhovetski@linux.intel.com> <20200722150927.15587-5-guennadi.liakhovetski@linux.intel.com> <20200804102132-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200804102132-mutt-send-email-mst@kernel.org> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.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 > > --- > > 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 > > + * > > + * 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 > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#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