----- Original Message ----- > On 16.09.2015 11:33, Marc-André Lureau wrote: > > ----- Original Message ----- > >> On 15.09.2015 18:07, marcandre.lur...@redhat.com wrote: > >>> From: Marc-André Lureau <marcandre.lur...@redhat.com> > >>> > >>> ivshmem_read() only reads sizeof(long) from the input buffer. Accepting > >>> more could lead to fifo8 abort() on 32bit systems if fifo is not empty. > >>> > >>> Signed-off-by: Marc-André Lureau <marcandre.lur...@redhat.com> > >>> --- > >>> hw/misc/ivshmem.c | 2 +- > >>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>> > >>> diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c > >>> index cc76989..fb53b3f 100644 > >>> --- a/hw/misc/ivshmem.c > >>> +++ b/hw/misc/ivshmem.c > >>> @@ -272,7 +272,7 @@ static void ivshmem_receive(void *opaque, const > >>> uint8_t > >>> *buf, int size) > >>> > >>> static int ivshmem_can_receive(void * opaque) > >>> { > >>> - return 8; > >>> + return sizeof(long); > >>> } > >>> > >> > >> Is the right fix this one, or should ivshmem_read() not rely on > >> sizeof(long)? > > > > > > 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... > > This field is used to communicate directly with another process on the host > right? > Should we not mandate the communication interface quite precisely, in order > to allow independent server development? > I'll push it further: do we need to consider endianness? It's the same host I > know, but is the meaning of the field endian-independant, or fully > expressed?
I am not aware of any specification, so following implementation it is 'long' integer in native endianness I agree we could document and change the protocol, but this will likely break it and could be done in a different patch series. thanks