|
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
[Prev in Thread] | Current Thread | [Next in Thread] |