From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51388) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wv7SL-000565-Vr for qemu-devel@nongnu.org; Thu, 12 Jun 2014 12:02:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wv7SG-0001cA-4y for qemu-devel@nongnu.org; Thu, 12 Jun 2014 12:02:25 -0400 Received: from mail-wg0-f44.google.com ([74.125.82.44]:35415) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wv7SF-0001bc-W7 for qemu-devel@nongnu.org; Thu, 12 Jun 2014 12:02:20 -0400 Received: by mail-wg0-f44.google.com with SMTP id x13so1481714wgg.3 for ; Thu, 12 Jun 2014 09:02:18 -0700 (PDT) Message-ID: <5399CF09.8030803@6wind.com> Date: Thu, 12 Jun 2014 18:02:17 +0200 From: Vincent JARDIN MIME-Version: 1.0 References: <20140610184818.2e490419@nbschild1> <53978375.6090707@6wind.com> <87ppie1v4r.fsf@blackfin.pond.sub.org> <20140612094413.15e56938@nbschild1> <87vbs6qjhj.fsf_-_@blackfin.pond.sub.org> In-Reply-To: <87vbs6qjhj.fsf_-_@blackfin.pond.sub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Why I advise against using ivshmem List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Henning Schild , David Marchand , qemu-devel@nongnu.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org Markus, see inline (I am not on all mailing list, please, keep the cc list). > Sure! The reasons for my dislike range from practical to > philosophical. > > My practical concerns include: > > 1. ivshmem code needs work, but has no maintainer See David's contributions: http://patchwork.ozlabs.org/patch/358750/ > 2. There is no libvirt support One can use qemu without libvivrt. > 3. Out-of-tree server program required for full functionality We have the source code, it provides the documentation to write our own better server program. > 4. Out-of-tree kernel uio driver required No, it is optional. > These concerns are all fixable, but it'll take serious work, and time. > Something like: > > * Find a maintainer for the device model I guess, we can find it into the DPDK.org community. > * Review and fix its code > > * Get the required kernel module upstream which module? uio, it is not required. > * Get all the required parts outside QEMU packaged in major distros, or > absorbed into QEMU Redhat did disable it. why? it is there in QEMU. > In short, create a viable community around ivshmem, either within the > QEMU community, or separately but cooperating. At least, DPDK.org community is a community using it. > On to the more philosophical ones. > > 5. Out-of-tree interface required > > Paraphrasing an old quip: Some people, when confronted with a > problem, think "I know, I'll use shared memory." Now they have two > problems. > > Shared memory is not an interface. It's at best something you can > use to build an interface. > > I'd rather have us offer something with a little bit more structure. > Very fast guest-to-guest networking perhaps. It is not just networking, you have other use cases like HPC, sharing in-memory databases. > > 6. Device models belong into QEMU > > Say you build an actual interface on top of ivshmem. Then ivshmem in > QEMU together with the supporting host code outside QEMU (see 3.) and > the lower layer of the code using it in guests (kernel + user space) > provide something that to me very much looks like a device model. > > Device models belong into QEMU. It's what QEMU does. See my previous statement, it is not just device model. Best regards, Vincent