qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 03/46] ivhsmem: read do not accept more than


From: Claudio Fontana
Subject: Re: [Qemu-devel] [PATCH v3 03/46] ivhsmem: read do not accept more than sizeof(long)
Date: Wed, 16 Sep 2015 15:05:56 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Thunderbird/38.2.0

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]