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. Also it looks like newer interface definitions specify using "guest native endianness" for Virtual Queue data. So I think the same should be done for RPMsg instead of enforcing LE? Thanks Guennadi On Mon, Jun 08, 2020 at 09:37:15AM +0200, Guennadi Liakhovetski wrote:> Hi Michael, > > On Fri, Jun 05, 2020 at 08:34:35AM +0200, Guennadi Liakhovetski wrote: > > > > On Thu, Jun 04, 2020 at 03:23:37PM -0400, Michael S. Tsirkin wrote: > > [snip] > > > > Another it's out of line with 1.0 spec passing guest > > > endian data around. Won't work if host and guest > > > endian-ness do not match. Should pass eveything in LE and > > > convert. > > > > Yes, I have to fix this, thanks. > > Just to make sure my understanding is correct: this would involve also > modifying the current virtio_rpmsg_bus.c implementation to add > endianness conversions. That's what you meant, right?
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.> So > I think the same should be done for RPMsg instead of enforcing LE? > > Thanks > GuennadiThat makes hardware implementations as well as any cross-endian hypervisors tricky. -- MST
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