On 16.09.2015 14:51, Paolo Bonzini wrote: > > > On 16/09/2015 13:27, Claudio Fontana wrote: >>>> See my answer to Paolo: >>>> http://lists.nongnu.org/archive/html/qemu-devel/2015-07/msg05341.html >> Sorry for not noticing the previous discussion.. >> >> Still it would seem more sensible to say explicitly how big the field is I >> think, >> especially if we want to make it possible to have independent server >> implementations of this... > > There was another question that went unanswered: > >> Does anyone care about ivshmem on 32-bit hosts? > > And I might even double down with "does anyone care about ivshmem on > big-endian hosts?" > > Just defining the protocol to be "64-bit little-endian" would be nice, > even if it would break those 2 people that respectively used ivshmem on > 32-bit Intel and big-endian PPC. (And maybe also the one guy who used > it on 32-bit big-endian PPC!). > > Paolo
Defining in general the protocol to be 64-bit and little endian is better than not defining it at all I think. For the two guys that use ivshmem on 32-bit Intel and big-endian PPC, please speak now! If there is indeed some use we could use some form of versioning I presume. There is regrettably no version register I could find in the current ivshmem implementation (is there something in the patch series I have missed?) Incidentally, (but please ignore this comment for the purpose of this series) I was thinking that if the device would provide a little bit more, like a separate BAR3 as a read-only shared memory area, and even (should I dare?) some form of simple multicast use case, like a peer negotiation and notification mechanism, that would make it even a bit more useful. But this is for another time.. Ciao, Claudio