On 09/01/2014 03:52 AM, David Marchand wrote:
>>> 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
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
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 d
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 ar
Hello Stefan,
On 08/08/2014 05:02 PM, Stefan Hajnoczi wrote:
On Fri, Aug 08, 2014 at 10:55:18AM +0200, David Marchand wrote:
+For each client (QEMU processes) that connects to the server:
+- the server assigns an ID for this client and sends this ID to him as the
first
+ message,
+- the serve
On Fri, Aug 08, 2014 at 10:55:18AM +0200, David Marchand wrote:
> +For each client (QEMU processes) that connects to the server:
> +- the server assigns an ID for this client and sends this ID to him as the
> first
> + message,
> +- the server sends a fd to the shared memory object to this client
