From: Vincent Whitchurch <vincent.whitchurch@axis.com>
To: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-remoteproc@vger.kernel.org"
<linux-remoteproc@vger.kernel.org>,
"virtualization@lists.linux-foundation.org"
<virtualization@lists.linux-foundation.org>,
"sound-open-firmware@alsa-project.org"
<sound-open-firmware@alsa-project.org>,
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
Liam Girdwood <liam.r.girdwood@linux.intel.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Jason Wang <jasowang@redhat.com>,
Ohad Ben-Cohen <ohad@wizery.com>,
"Bjorn Andersson" <bjorn.andersson@linaro.org>,
Mathieu Poirier <mathieu.poirier@linaro.org>
Subject: Re: [PATCH v3 5/5] vhost: add an RPMsg API
Date: Tue, 14 Jul 2020 10:33:59 +0200 [thread overview]
Message-ID: <20200714083359.wn4uoq3d7zzsddkc@axis.com> (raw)
In-Reply-To: <20200618141412.GD4189@ubuntu>
On Thu, Jun 18, 2020 at 04:14:12PM +0200, Guennadi Liakhovetski wrote:
> On Thu, Jun 18, 2020 at 03:52:42PM +0200, Vincent Whitchurch wrote:
> > Note that "the Linux side" is ambiguous for AMP since both sides can be
> > Linux, as they happen to be in my case. I'm running virtio/rpmsg
> > between two physical processors (of different architectures), both
> > running Linux.
>
> Ok, interesting, I didn't know such configurations were used too. I understood
> the Linux rpmsg implementation in the way, that it's assumed, that the "host"
> has to boot the "device" by sending an ELF formatted executable image to it, is
> that optional? You aren't sending a complete Linux image to the device side,
> are you?
I do pack the zImage, the dtb, and the initramfs into an ELF (along with
a tiny "bootloader" with just a handful of instructions), but the
remoteproc framework is not tied to the ELF format since ->parse_fw()
and friends are overridable by the remoteproc driver.
> > virtio has distinct driver and device roles so the completely different
> > APIs on each side are understandable. But I don't see that distinction
> > in the rpmsg API which is why it seems like a good idea to me to make it
> > work from both sides of the link and allow the reuse of drivers like
> > rpmsg-char, instead of imposing virtio's distinction on rpmsg.
>
> Understand. In principle I'm open to this idea, but before I implement it it
> would be good to know what maintainers think?
Certainly.
next prev parent reply other threads:[~2020-07-14 8:34 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-27 18:05 [PATCH v3 0/5] Add a vhost RPMsg API Guennadi Liakhovetski
2020-05-27 18:05 ` [PATCH v3 1/5] vhost: convert VHOST_VSOCK_SET_RUNNING to a generic ioctl Guennadi Liakhovetski
2020-05-27 18:05 ` [PATCH v3 2/5] vhost: (cosmetic) remove a superfluous variable initialisation Guennadi Liakhovetski
2020-05-27 18:05 ` [PATCH v3 3/5] rpmsg: move common structures and defines to headers Guennadi Liakhovetski
2020-05-27 18:05 ` [PATCH v3 4/5] rpmsg: update documentation Guennadi Liakhovetski
2020-05-28 19:26 ` Mathieu Poirier
2020-05-27 18:05 ` [PATCH v3 5/5] vhost: add an RPMsg API Guennadi Liakhovetski
2020-05-28 19:26 ` Mathieu Poirier
2020-06-17 19:17 ` Vincent Whitchurch
2020-06-18 9:03 ` Guennadi Liakhovetski
2020-06-18 9:33 ` Vincent Whitchurch
2020-06-18 10:39 ` Guennadi Liakhovetski
2020-06-18 13:52 ` Vincent Whitchurch
2020-06-18 14:14 ` Guennadi Liakhovetski
2020-07-14 8:33 ` Vincent Whitchurch [this message]
2020-05-29 6:01 ` [PATCH v3 0/5] Add a vhost " Jason Wang
2020-05-29 6:50 ` Guennadi Liakhovetski
2020-05-29 7:06 ` Jason Wang
2020-06-04 19:23 ` Michael S. Tsirkin
2020-06-05 6:34 ` Guennadi Liakhovetski
2020-06-08 7:37 ` Guennadi Liakhovetski
2020-06-08 9:09 ` Michael S. Tsirkin
2020-06-08 9:11 ` Guennadi Liakhovetski
2020-06-08 9:19 ` Michael S. Tsirkin
2020-06-08 10:15 ` Guennadi Liakhovetski
2020-06-08 11:16 ` Guennadi Liakhovetski
2020-06-08 13:08 ` Michael S. Tsirkin
2020-06-08 13:01 ` Michael S. Tsirkin
2020-06-05 10:01 ` [Sound-open-firmware] " Liam Girdwood
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=20200714083359.wn4uoq3d7zzsddkc@axis.com \
--to=vincent.whitchurch@axis.com \
--cc=bjorn.andersson@linaro.org \
--cc=guennadi.liakhovetski@linux.intel.com \
--cc=jasowang@redhat.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).