linux-remoteproc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Cc: kvm@vger.kernel.org, linux-remoteproc@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	sound-open-firmware@alsa-project.org,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	Liam Girdwood <liam.r.girdwood@linux.intel.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 0/5] Add a vhost RPMsg API
Date: Mon, 8 Jun 2020 09:01:24 -0400	[thread overview]
Message-ID: <20200608090010-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20200608101526.GD10562@ubuntu>

On Mon, Jun 08, 2020 at 12:15:27PM +0200, Guennadi Liakhovetski wrote:
> On Mon, Jun 08, 2020 at 05:19:06AM -0400, Michael S. Tsirkin wrote:
> > On Mon, Jun 08, 2020 at 11:11:00AM +0200, Guennadi Liakhovetski wrote:
> > > Update: I looked through VirtIO 1.0 and 1.1 specs, data format their, 
> > > including byte order, is defined on a per-device type basis. RPMsg is 
> > > indeed included in the spec as device type 7, but that's the only 
> > > mention of it in both versions. It seems RPMsg over VirtIO isn't 
> > > standardised yet.
> > 
> > Yes. And it would be very good to have some standartization before we
> > keep adding things. For example without any spec if host code breaks
> > with some guests, how do we know which side should be fixed?
> > 
> > > Also it looks like newer interface definitions 
> > > specify using "guest native endianness" for Virtual Queue data.
> > 
> > They really don't or shouldn't. That's limited to legacy chapters.
> > Some definitions could have slipped through but it's not
> > the norm. I just quickly looked through the 1.1 spec and could
> > not find any instances that specify "guest native endianness"
> > but feel free to point them out to me.
> 
> Oh, there you go. No, sorry, my fault, it's the other way round: "guest 
> native" is for legacy and LE is for current / v1.0 and up.
> 
> > > So 
> > > I think the same should be done for RPMsg instead of enforcing LE?
> > 
> > That makes hardware implementations as well as any cross-endian
> > hypervisors tricky.
> 
> Yes, LE it is then. And we need to add some text to the spec.
> 
> In theory there could be a backward compatibility issue - in case someone 
> was already using virtio_rpmsg_bus.c in BE mode, but I very much doubt 
> that...
> 
> Thanks
> Guennadi

It's probably easiest to use virtio wrappers and then we don't need to
worry about it.

-- 
MST


  parent reply	other threads:[~2020-06-08 13:01 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
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 [this message]
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=20200608090010-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.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=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).