From: Vincent Whitchurch <vincent.whitchurch@axis.com>
To: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.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 10:36:44 +0200 [thread overview]
Message-ID: <20200917083644.66yjer4zvoiftrk3@axis.com> (raw)
In-Reply-To: <20200917054705.GA11491@ubuntu>
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/.
> > [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
next prev parent reply other threads:[~2020-09-17 8:36 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 [this message]
2020-09-17 10:29 ` Guennadi Liakhovetski
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=20200917083644.66yjer4zvoiftrk3@axis.com \
--to=vincent.whitchurch@axis.com \
--cc=arnaud.pouliquen@st.com \
--cc=bjorn.andersson@linaro.org \
--cc=guennadi.liakhovetski@linux.intel.com \
--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=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).