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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
