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: Tue, 26 Aug 2014 08:47:56 +0200 Message-ID: <53FC2D9C.8020804@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> 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, pbonzini@redhat.com, jani.kokkonen@huawei.com, cam@cs.ualberta.ca To: Stefan Hajnoczi Return-path: Received: from mail-we0-f172.google.com ([74.125.82.172]:55792 "EHLO mail-we0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757334AbaHZGsA (ORCPT ); Tue, 26 Aug 2014 02:48:00 -0400 Received: by mail-we0-f172.google.com with SMTP id x48so14228645wes.17 for ; Mon, 25 Aug 2014 23:47:59 -0700 (PDT) In-Reply-To: <20140808150202.GD13382@stefanha-thinkpad.redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 server sends a fd to the shared memory object to this client, >> +- the server creates a new set of host eventfds associated to the new client and >> + sends this set to all already connected clients, >> +- finally, the server sends all the eventfds sets for all clients to the new >> + client. > > The protocol is not extensible and no version number is exchanged. For > the most part this should be okay because clients must run on the same > machine as the server. It is assumed clients and server are compatible > with each other. > > I wonder if we'll get into trouble later if the protocol needs to be > extended or some operation needs to happen, like upgrading QEMU or the > ivshmem-server. At the very least someone building from source but > using system QEMU or ivshmem-server could get confusing failures if the > protocol doesn't match. > > How about sending a version message as the first thing during a > connection? I am not too sure about this. This would break current base version. 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. If you want to test local modifications, then it means you know what you are doing and you will call the right ivshmem-server binary with the right QEMU binary. Thanks. -- David Marchand From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55393) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XMAY3-0008BR-QX for qemu-devel@nongnu.org; Tue, 26 Aug 2014 02:48:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XMAXw-0006Lg-Bj for qemu-devel@nongnu.org; Tue, 26 Aug 2014 02:48:07 -0400 Received: from mail-we0-f174.google.com ([74.125.82.174]:33096) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XMAXw-0006LR-5K for qemu-devel@nongnu.org; Tue, 26 Aug 2014 02:48:00 -0400 Received: by mail-we0-f174.google.com with SMTP id x48so14172941wes.5 for ; Mon, 25 Aug 2014 23:47:59 -0700 (PDT) Message-ID: <53FC2D9C.8020804@6wind.com> Date: Tue, 26 Aug 2014 08:47:56 +0200 From: David Marchand MIME-Version: 1.0 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> In-Reply-To: <20140808150202.GD13382@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 2/2] docs: update ivshmem device spec List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: kvm@vger.kernel.org, claudio.fontana@huawei.com, qemu-devel@nongnu.org, armbru@redhat.com, pbonzini@redhat.com, jani.kokkonen@huawei.com, cam@cs.ualberta.ca 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 server sends a fd to the shared memory object to this client, >> +- the server creates a new set of host eventfds associated to the new client and >> + sends this set to all already connected clients, >> +- finally, the server sends all the eventfds sets for all clients to the new >> + client. > > The protocol is not extensible and no version number is exchanged. For > the most part this should be okay because clients must run on the same > machine as the server. It is assumed clients and server are compatible > with each other. > > I wonder if we'll get into trouble later if the protocol needs to be > extended or some operation needs to happen, like upgrading QEMU or the > ivshmem-server. At the very least someone building from source but > using system QEMU or ivshmem-server could get confusing failures if the > protocol doesn't match. > > How about sending a version message as the first thing during a > connection? I am not too sure about this. This would break current base version. 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. If you want to test local modifications, then it means you know what you are doing and you will call the right ivshmem-server binary with the right QEMU binary. Thanks. -- David Marchand