virtualization.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
To: Vincent Whitchurch <vincent.whitchurch@axis.com>
Cc: Ohad Ben-Cohen <ohad@wizery.com>,
	kishon@ti.com, Mathieu Poirier <mathieu.poirier@linaro.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Arnaud POULIQUEN <arnaud.pouliquen@st.com>,
	"linux-remoteproc@vger.kernel.org"
	<linux-remoteproc@vger.kernel.org>,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Liam Girdwood <liam.r.girdwood@linux.intel.com>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	"sound-open-firmware@alsa-project.org"
	<sound-open-firmware@alsa-project.org>
Subject: Re: [PATCH v6 0/4] Add a vhost RPMsg API
Date: Thu, 17 Sep 2020 12:29:12 +0200	[thread overview]
Message-ID: <20200917102911.GB11491@ubuntu> (raw)
In-Reply-To: <20200917083644.66yjer4zvoiftrk3@axis.com>

Hi Vincent,

On Thu, Sep 17, 2020 at 10:36:44AM +0200, Vincent Whitchurch wrote:
> On Thu, Sep 17, 2020 at 07:47:06AM +0200, Guennadi Liakhovetski wrote:
> > On Tue, Sep 15, 2020 at 02:13:23PM +0200, Arnaud POULIQUEN wrote:
> > > So i would be agree with Vincent[2] which proposed to switch on a RPMsg API
> > > and creating a vhost rpmsg device. This is also proposed in the 
> > > "Enhance VHOST to enable SoC-to-SoC communication" RFC[3].
> > > Do you think that this alternative could match with your need?
> > 
> > As I replied to Vincent, I understand his proposal and the approach taken 
> > in the series [3], but I'm not sure I agree, that adding yet another 
> > virtual device / driver layer on the vhost side is a good idea. As far as 
> > I understand adding new completely virtual devices isn't considered to be 
> > a good practice in the kernel. Currently vhost is just a passive "library" 
> > and my vhost-rpmsg support keeps it that way. Not sure I'm in favour of 
> > converting vhost to a virtual device infrastructure.
> 
> I know it wasn't what you meant, but I noticed that the above paragraph
> could be read as if my suggestion was to convert vhost to a virtual
> device infrastructure, so I just want to clarify that that those are not
> related.  The only similarity between what I suggested in the thread in
> [2] and Kishon's RFC in [3] is that both involve creating a generic
> vhost-rpmsg driver which would allow the RPMsg API to be used for both
> sides of the link, instead of introducing a new API just for the server
> side.  That can be done without rewriting drivers/vhost/.

Thanks for the clarification. Another flexibility, that I'm trying to preserve 
with my approach is keeping direct access to iovec style data buffers for 
cases where that's the structure, that's already used by the respective 
driver on the host side. Since we already do packing and unpacking on the 
guest / client side, we don't need the same on the host / server side again.

Thanks
Guennadi

> > > [1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=338335 
> > > [2]. https://www.spinics.net/lists/linux-virtualization/msg44195.html
> > > [3]. https://www.spinics.net/lists/linux-remoteproc/msg06634.html  
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  reply	other threads:[~2020-09-17 10:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-01 15:11 [PATCH v6 0/4] Add a vhost RPMsg API Guennadi Liakhovetski
2020-09-01 15:11 ` [PATCH v6 1/4] vhost: convert VHOST_VSOCK_SET_RUNNING to a generic ioctl Guennadi Liakhovetski
2020-09-01 15:11 ` [PATCH v6 2/4] rpmsg: move common structures and defines to headers Guennadi Liakhovetski
     [not found]   ` <20200901172321.GC236120@xps15>
2020-09-02  5:35     ` Guennadi Liakhovetski
     [not found]       ` <20200902172437.GC280378@xps15>
2020-09-03  5:51         ` Guennadi Liakhovetski
2020-09-01 15:11 ` [PATCH v6 3/4] rpmsg: update documentation Guennadi Liakhovetski
2020-09-01 15:11 ` [PATCH v6 4/4] vhost: add an RPMsg API Guennadi Liakhovetski
2020-09-15 12:13 ` [PATCH v6 0/4] Add a vhost " Arnaud POULIQUEN
2020-09-17  5:47   ` Guennadi Liakhovetski
2020-09-17  8:36     ` Vincent Whitchurch
2020-09-17 10:29       ` Guennadi Liakhovetski [this message]
2020-09-17 15:21     ` Arnaud POULIQUEN
2020-09-18  5:44       ` Guennadi Liakhovetski
2020-09-18  7:47         ` Arnaud POULIQUEN
2020-09-18  9:47           ` Guennadi Liakhovetski
2020-09-18 10:39             ` Vincent Whitchurch
2020-09-18 11:02               ` Guennadi Liakhovetski
2020-09-18 17:26             ` Arnaud POULIQUEN

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=20200917102911.GB11491@ubuntu \
    --to=guennadi.liakhovetski@linux.intel.com \
    --cc=arnaud.pouliquen@st.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=kishon@ti.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).