I am adding Vincent Whitchurch and the virtualization mailing list... On Thu, 3 Dec 2020 at 13:42, Guennadi Liakhovetski <guennadi.liakhovetski@xxxxxxxxxxxxxxx> wrote: > > (adding vhost maintainers and the author of [1]) > > Hi, > > I'm working on an Audio DSP virtualisation solution [2] and the next > step in its upstreaming should be an RPMsg vhost implementation, based > on [3], which contains a simple addition to the current library-style > vhost API. Later in [1] a different approach has been presented, > converting the vhost framework to a proper bus-type and device driver. > Therefore my questions: > > 1. if the latter approach is prefered, should we expect follow up > versions of [1] and their upstreaming? > 2. judging by the size and complexity of [1] would it maybe be > preferable to first extract a minimum patch set just to add vhost > rpmsg? Looking at the patch set it should be doable and not too > difficult? Kishon, would it be something you could submit? To me that is the best approach. It might be best for you to do the work and credit Kishon where needed. > 3. or would it be preferable to keep vhost in its present form, use > [3] for rpmsg support and re-implement [1] based on a different > vhost / vringh approach? > > Thanks > Guennadi > > [1] https://www.spinics.net/lists/kvm/msg219632.html > [2] https://mailman.alsa-project.org/pipermail/sound-open-firmware/2020-April/003766.html > [3] https://www.spinics.net/lists/linux-virtualization/msg43359.html > > On Wed, Dec 02, 2020 at 01:39:54PM -0700, Mathieu Poirier wrote: > > Good day, > > > > On Wed, Dec 02, 2020 at 12:05:55PM +0100, Guennadi Liakhovetski wrote: > > > Hi Mathieu, > > > > > > I'd like to resume reviewing and begin upstreaming of the next steps of > > > my Audio DSP Virtualisation work, based on this your patch set. How > > > > I'm all for it too. > > > > > confident are we that it's going to be upstreamed in its present form? > > > What's the plan to push it to "next?" > > > > > > > I thought we were pretty unanimous that something like what Kishon did was the > > way to go. > > > > > Thanks > > > Guennadi > > > > > > On Mon, Nov 23, 2020 at 05:06:10PM +0100, Guennadi Liakhovetski wrote: > > > > Hi Mathieu, > > > > > > > > Thanks for bringing all the stuff together and for polishing it! > > > > > > > > For the entire series: > > > > > > > > Tested-by: Guennadi Liakhovetski <guennadi.liakhovetski@xxxxxxxxxxxxxxx> > > > > Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@xxxxxxxxxxxxxxx> > > > > > > > > Thanks > > > > Guennadi > > > > > > > > On Fri, Nov 20, 2020 at 02:42:37PM -0700, Mathieu Poirier wrote: > > > > > This revision addresses comments received from the previous revision, > > > > > i.e V6. Please see details below. > > > > > > > > > > It starts by making the RPMSG protocol transport agnostic by > > > > > moving the headers it uses to generic types and using those in the > > > > > current implementation. From there it re-uses the work that Arnaud > > > > > published[1] to make the name service modular. > > > > > > > > > > Tested on stm32mp157 with the RPMSG client sample application. Applies > > > > > cleanly on rpmsg-next. > > > > > > > > > > Thanks, > > > > > Mathieu > > > > > > > > > > [1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=338335 > > > > > > > > > > ------- > > > > > New for V7: > > > > > - Fixed error path in rpmsg_probe() as reported by Guennadi > > > > > > > > > > Arnaud Pouliquen (4): > > > > > rpmsg: virtio: Rename rpmsg_create_channel > > > > > rpmsg: core: Add channel creation internal API > > > > > rpmsg: virtio: Add rpmsg channel device ops > > > > > rpmsg: Turn name service into a stand alone driver > > > > > > > > > > Mathieu Poirier (4): > > > > > rpmsg: Introduce __rpmsg{16|32|64} types > > > > > rpmsg: virtio: Move from virtio to rpmsg byte conversion > > > > > rpmsg: Move structure rpmsg_ns_msg to header file > > > > > rpmsg: Make rpmsg_{register|unregister}_device() public > > > > > > > > > > drivers/rpmsg/Kconfig | 9 ++ > > > > > drivers/rpmsg/Makefile | 1 + > > > > > drivers/rpmsg/rpmsg_core.c | 44 ++++++++ > > > > > drivers/rpmsg/rpmsg_internal.h | 14 ++- > > > > > drivers/rpmsg/rpmsg_ns.c | 126 +++++++++++++++++++++ > > > > > drivers/rpmsg/virtio_rpmsg_bus.c | 186 +++++++++++-------------------- > > > > > include/linux/rpmsg.h | 63 ++++++++++- > > > > > include/linux/rpmsg/byteorder.h | 67 +++++++++++ > > > > > include/linux/rpmsg/ns.h | 45 ++++++++ > > > > > include/uapi/linux/rpmsg_types.h | 11 ++ > > > > > 10 files changed, 439 insertions(+), 127 deletions(-) > > > > > create mode 100644 drivers/rpmsg/rpmsg_ns.c > > > > > create mode 100644 include/linux/rpmsg/byteorder.h > > > > > create mode 100644 include/linux/rpmsg/ns.h > > > > > create mode 100644 include/uapi/linux/rpmsg_types.h > > > > > > > > > > -- > > > > > 2.25.1 > > > > >
