All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
To: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: linux-remoteproc <linux-remoteproc@vger.kernel.org>
Subject: Re: RPMSG over VirtIO under KVM
Date: Thu, 16 Apr 2020 21:15:17 +0200	[thread overview]
Message-ID: <20200416191516.GB25561@ubuntu> (raw)
In-Reply-To: <CANLsYky6hdPnerfYvZk6SdO2supVPSr7Sa_x4-UsJ6Y5bgTfHQ@mail.gmail.com>

Hi Mathieu,

On Thu, Apr 16, 2020 at 11:50:48AM -0600, Mathieu Poirier wrote:
> Good day Guennadi,
> 
> On Thu, 16 Apr 2020 at 08:06, Guennadi Liakhovetski
> <guennadi.liakhovetski@linux.intel.com> wrote:
> >
> > Hi,
> >
> > It has been proposed to port the VirtIO SOF driver [1], used to
> > implement audio support under Linux, running in a KVM guest, to use
> > RPMSG to communicate with the SOF vhost driver, running on the Linux
> > host. On one hand I see an rpmsg-virtio driver, which should make such
> > a port possible, on the other hand I don't see a single VirtIO driver
> > in the kernel, using RPMSG for Linux virtualisation.
> 
> Above you wrote "rpmsg-virtio" driver, which I take to mean the code
> found in file virtio_rpmsg_bus.c [1].

Exactly.

> The code in [1] centers around
> the communication between an application processor and some form of
> remote processor (micro controller or dsp).  The "virtio" part of the
> name refers to the underlying infrastructure put in place to
> communicate with the remote processor, all coming from the virtio
> space.  Here instead of using the virtio mechanic to communicate
> between a host and a guest, it is used to communicate with a remote
> processor.
> 
> I came to the same conclusion a while back - as of today no virtio
> drivers are using RPMSG to communicate between host and guest.  I
> suppose nobody needed it or implemented their own schemes.
> 
> [1].  https://elixir.bootlin.com/linux/v5.7-rc1/source/drivers/rpmsg/virtio_rpmsg_bus.c
> 
> >
> > Hence my questions: is this a good idea? Is there anything in the
> > kernel VirtIO RPMSG implementation, that would make this impossible?
> 
> I don't see why it wouldn't be a good idea, nor what would technically
> prevent such a thing from happening.  Two things work in your favour:
> 1) the RPMSG foundation has been tailored to be used over different
> kinds of hardware and 2) an existing implementation is already using
> virtioqueues.
> 
> I suggest to start looking at function rpmsg_register_device(), used
> by different RPMSG drivers - the magic is really in the RPMSG
> operations (struct rpmsg_device_ops) that are used to abstract the HW
> implementation.

Exactly, just what I was thinking too. And I also think it can well be 
possible to reuse the code in virtio_rpmsg_bus.c, possibly with some 
limited extensions and modifications. I'll get it rolling then.

Thanks
Guennadi

> Regards,
> Mathieu
> 
> > [1] https://thesofproject.github.io/latest/developer_guides/virtualization/virtualization.html

      reply	other threads:[~2020-04-16 19:15 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-16 14:05 RPMSG over VirtIO under KVM Guennadi Liakhovetski
2020-04-16 17:50 ` Mathieu Poirier
2020-04-16 19:15   ` Guennadi Liakhovetski [this message]

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=20200416191516.GB25561@ubuntu \
    --to=guennadi.liakhovetski@linux.intel.com \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=mathieu.poirier@linaro.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.