From mboxrd@z Thu Jan 1 00:00:00 1970 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 Message-ID: <540441E4.7080203@6wind.com> References: <1407488118-11245-1-git-send-email-david.marchand@6wind.com> <1407488118-11245-3-git-send-email-david.marchand@6wind.com> <20140808150202.GD13382@stefanha-thinkpad.redhat.com> <53FC2D9C.8020804@6wind.com> <53FC69BE.7010100@redhat.com> <20140828094911.GA26741@stefanha-thinkpad.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, claudio.fontana@huawei.com, armbru@redhat.com, jani.kokkonen@huawei.com, cam@cs.ualberta.ca To: Stefan Hajnoczi , Paolo Bonzini Return-path: Received: from mail-wg0-f45.google.com ([74.125.82.45]:42443 "EHLO mail-wg0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753128AbaIAJwk (ORCPT ); Mon, 1 Sep 2014 05:52:40 -0400 Received: by mail-wg0-f45.google.com with SMTP id k14so5198378wgh.16 for ; Mon, 01 Sep 2014 02:52:39 -0700 (PDT) In-Reply-To: <20140828094911.GA26741@stefanha-thinkpad.redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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