Re: [Qemu-devel] [PATCH v3 2/2] docs: update ivshmem device spec

[David Marchand <david.marchand@6wind.com>]

On 08/28/2014 11:49 AM, Stefan Hajnoczi wrote:
> On Tue, Aug 26, 2014 at 01:04:30PM +0200, Paolo Bonzini wrote:
>> Il 26/08/2014 08:47, David Marchand ha scritto:
>>>
>>> Using a version message supposes we want to keep ivshmem-server and QEMU
>>> separated (for example, in two distribution packages) while we can avoid
>>> this, so why would we do so ?
>>>
>>> If we want the ivshmem-server to come with QEMU, then both are supposed
>>> to be aligned on your system.
>>
>> What about upgrading QEMU and ivshmem-server while you have existing
>> guests?  You cannot restart ivshmem-server, and the new QEMU would have
>> to talk to the old ivshmem-server.
>
> Version negotiation also helps avoid confusion if someone combines
> ivshmem-server and QEMU from different origins (e.g. built from source
> and distro packaged).
>
> It's a safeguard to prevent hard-to-diagnose failures when the system is
> misconfigured.
>

Hum, so you want the code to be defensive against mis-use, why not.

I wanted to keep modifications on ivshmem as little as possible in a 
first phase (all the more so as there are potential ivshmem users out 
there that I think will be impacted by a protocol change).

Sending the version as the first "vm_id" with an associated fd to -1 
before sending the real client id should work with existing QEMU client 
code (hw/misc/ivshmem.c).

Do you have a better idea ?
Is there a best practice in QEMU for "version negotiation" that could 
work with ivshmem protocol ?

I have a v4 ready with this (and all the pending comments), I will send 
it later unless a better idea is exposed.


Thanks.

-- 
David Marchand