From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47577) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcCPd-0003qy-Ju for qemu-devel@nongnu.org; Wed, 16 Sep 2015 09:06:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZcCPZ-00049c-Jc for qemu-devel@nongnu.org; Wed, 16 Sep 2015 09:06:13 -0400 Received: from lhrrgout.huawei.com ([194.213.3.17]:23285) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcCPZ-00049S-Af for qemu-devel@nongnu.org; Wed, 16 Sep 2015 09:06:09 -0400 References: <1442333283-13119-1-git-send-email-marcandre.lureau@redhat.com> <1442333283-13119-4-git-send-email-marcandre.lureau@redhat.com> <55F935E4.2030705@huawei.com> <534883311.12512111.1442395999383.JavaMail.zimbra@redhat.com> <55F95223.5050909@huawei.com> <55F965CC.6030807@redhat.com> From: Claudio Fontana Message-ID: <55F96934.4060307@huawei.com> Date: Wed, 16 Sep 2015 15:05:56 +0200 MIME-Version: 1.0 In-Reply-To: <55F965CC.6030807@redhat.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 03/46] ivhsmem: read do not accept more than sizeof(long) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= Cc: marcandre lureau , drjones@redhat.com, cam@cs.ualberta.ca, qemu-devel@nongnu.org, stefanha@redhat.com 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