From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47598) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wv8HG-0001CK-2o for qemu-devel@nongnu.org; Thu, 12 Jun 2014 12:55:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wv8H6-0000KZ-5r for qemu-devel@nongnu.org; Thu, 12 Jun 2014 12:55:01 -0400 Received: from mail-we0-x22b.google.com ([2a00:1450:400c:c03::22b]:62201) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wv8H5-0000KK-W3 for qemu-devel@nongnu.org; Thu, 12 Jun 2014 12:54:52 -0400 Received: by mail-we0-f171.google.com with SMTP id q58so1606176wes.30 for ; Thu, 12 Jun 2014 09:54:50 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <5399DB57.4070500@redhat.com> Date: Thu, 12 Jun 2014 18:54:47 +0200 From: Paolo Bonzini 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> <5399CF09.8030803@6wind.com> In-Reply-To: <5399CF09.8030803@6wind.com> 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: Vincent JARDIN , Markus Armbruster Cc: Henning Schild , David Marchand , qemu-devel@nongnu.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org Il 12/06/2014 18:02, Vincent JARDIN ha scritto: > >> * 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. We don't ship everything that is part of QEMU, just like we selectively disable many drivers in Linux. Markus especially referred to parts *outside* QEMU: the server, the uio driver, etc. These out-of-tree, non-packaged parts of ivshmem are one of the reasons why Red Hat has disabled ivshmem in RHEL7. He also listed many others. Basically for parts of QEMU that are not of high quality, we either fix them (this is for example what we did for qcow2) or disable them. Not just ivshmem suffered this fate, for example many network cards, sound cards, SCSI storage adapters. Now, vhost-user is in the process of being merged for 2.1. Compared to the DPDK solution: * it doesn't require hugetlbfs (which only enabled shared memory by chance in older QEMU releases, that was never documented) * it doesn't require ivshmem (it does require shared memory, which will also be added to 2.1) * it doesn't require the kernel driver from the DPDK sample * it is not just shared memory, but also defines an interface to use it (another of Markus's points) vhost-user is superior, and it is superior because it has been designed from the get-go through cooperation of all interested parties (namely QEMU and snabbswitch). Paolo