From: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
To: "Michael S. Tsirkin" <mst@redhat.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 12:15:27 +0200 [thread overview]
Message-ID: <20200608101526.GD10562@ubuntu> (raw)
In-Reply-To: <20200608051358-mutt-send-email-mst@kernel.org>
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
next prev parent reply other threads:[~2020-06-08 10:15 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 [this message]
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=20200608101526.GD10562@ubuntu \
--to=guennadi.liakhovetski@linux.intel.com \
--cc=bjorn.andersson@linaro.org \
--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).