qemu-devel
[Top][All Lists]
Advanced

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

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


From: David Marchand
Subject: Re: [Qemu-devel] [PATCH v3 2/2] docs: update ivshmem device spec
Date: Mon, 01 Sep 2014 11:52:36 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.7.0

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



reply via email to

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