From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vincent JARDIN Subject: Re: [Qemu-devel] Why I advise against using ivshmem Date: Fri, 13 Jun 2014 15:41:16 +0200 Message-ID: <539AFF7C.7090702@6wind.com> 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> <87ppidnqmy.fsf@blackfin.pond.sub.org> <539AC3E0.9090404@6wind.com> <539ACDE6.7020709@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Markus Armbruster , Henning Schild , David Marchand , qemu-devel@nongnu.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org, Olivier MATZ , "thomas.monjalon@6wind.com" To: Paolo Bonzini Return-path: Received: from mail-wi0-f181.google.com ([209.85.212.181]:43001 "EHLO mail-wi0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751093AbaFMNlU (ORCPT ); Fri, 13 Jun 2014 09:41:20 -0400 Received: by mail-wi0-f181.google.com with SMTP id n3so910056wiv.2 for ; Fri, 13 Jun 2014 06:41:18 -0700 (PDT) In-Reply-To: <539ACDE6.7020709@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: > Fine, however Red Hat would also need a way to test ivshmem code, with > proper quality assurance (that also benefits upstream, of course). With > ivshmem this is not possible without the out-of-tree packages. You did not reply to my question: how to get the list of things that are/will be disabled by Redhat? About Redhat's QA, I do not care. About Qemu's QA, I do care ;) I guess we can combine both. What's about something like: tests/virtio-net-test.c # qtest_add_func( is a nop) but for ivshmem test/ivshmem-test.c ? would it have any values? If not, what do you use at Redhat to test Qemu? >> now, you cannot compare vhost-user to DPDK/ivshmem; both should exsit >> because they have different scope and use cases. It is like comparing >> two different(A) models of IPC: I do repeat this use case that you had removed because vhost-user does not solve it yet: >> - ivshmem -> framework to be generic to have shared memory for many >> use cases (HPC, in-memory-database, a network too like memnic). >> - vhost-user -> networking use case specific > > Not necessarily. First and foremost, vhost-user defines an API for > communication between QEMU and the host, including: > * file descriptor passing for the shared memory file > * mapping offsets in shared memory to physical memory addresses in the > guests > * passing dirty memory information back and forth, so that migration is > not prevented > * sending interrupts to a device > * setting up ring buffers in the shared memory Yes, I do agree that it is promising. And of course some tests are here: https://lists.gnu.org/archive/html/qemu-devel/2014-03/msg00584.html for some of the bullets you are listing (not all yet). > Also, vhost-user is documented! See here: > https://lists.gnu.org/archive/html/qemu-devel/2014-03/msg00581.html as I told you, we'll send a contribution with ivshmem's documentation. > The only part of ivshmem that vhost doesn't include is the n-way > inter-guest doorbell. This is the part that requires a server and uio > driver. vhost only supports host->guest and guest->host doorbells. agree: both will need it: vhost and ivshmem requires a doorbell for VM2VM, but then we'll have a security issue to be managed by Qemu for vhost and ivshmem. I'll be pleased to contribute on it for ivshmem thru another thread that this one. >> ivhsmem does not require DPDK kernel driver. see memnic's PMD: >> http://dpdk.org/browse/memnic/tree/pmd/pmd_memnic.c > > You're right, I was confusing memnic and the vhost example in DPDK. Definitively, it proves a lack of documentation. You welcome. Olivier did explain it: >> ivhsmem does not require hugetlbfs. It is optional. >> >> > * it doesn't require ivshmem (it does require shared memory, which >> > will also be added to 2.1) > > Right, hugetlbfs is not required. A posix shared memory or tmpfs > can be used instead. For instance, to use /dev/shm/foobar: > > qemu-system-x86_64 -enable-kvm -cpu host [...] \ > -device ivshmem,size=16,shm=foobar Best regards, Vincent From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44262) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WvRjS-0007NX-E9 for qemu-devel@nongnu.org; Fri, 13 Jun 2014 09:41:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WvRjM-0001HB-N6 for qemu-devel@nongnu.org; Fri, 13 Jun 2014 09:41:26 -0400 Received: from mail-wi0-f177.google.com ([209.85.212.177]:47993) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WvRjM-0001G7-Dq for qemu-devel@nongnu.org; Fri, 13 Jun 2014 09:41:20 -0400 Received: by mail-wi0-f177.google.com with SMTP id r20so910999wiv.16 for ; Fri, 13 Jun 2014 06:41:18 -0700 (PDT) Message-ID: <539AFF7C.7090702@6wind.com> Date: Fri, 13 Jun 2014 15:41:16 +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> <5399CF09.8030803@6wind.com> <87ppidnqmy.fsf@blackfin.pond.sub.org> <539AC3E0.9090404@6wind.com> <539ACDE6.7020709@redhat.com> In-Reply-To: <539ACDE6.7020709@redhat.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: Paolo Bonzini Cc: Henning Schild , Olivier MATZ , kvm@vger.kernel.org, Markus Armbruster , qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org, "thomas.monjalon@6wind.com" , David Marchand > Fine, however Red Hat would also need a way to test ivshmem code, with > proper quality assurance (that also benefits upstream, of course). With > ivshmem this is not possible without the out-of-tree packages. You did not reply to my question: how to get the list of things that are/will be disabled by Redhat? About Redhat's QA, I do not care. About Qemu's QA, I do care ;) I guess we can combine both. What's about something like: tests/virtio-net-test.c # qtest_add_func( is a nop) but for ivshmem test/ivshmem-test.c ? would it have any values? If not, what do you use at Redhat to test Qemu? >> now, you cannot compare vhost-user to DPDK/ivshmem; both should exsit >> because they have different scope and use cases. It is like comparing >> two different(A) models of IPC: I do repeat this use case that you had removed because vhost-user does not solve it yet: >> - ivshmem -> framework to be generic to have shared memory for many >> use cases (HPC, in-memory-database, a network too like memnic). >> - vhost-user -> networking use case specific > > Not necessarily. First and foremost, vhost-user defines an API for > communication between QEMU and the host, including: > * file descriptor passing for the shared memory file > * mapping offsets in shared memory to physical memory addresses in the > guests > * passing dirty memory information back and forth, so that migration is > not prevented > * sending interrupts to a device > * setting up ring buffers in the shared memory Yes, I do agree that it is promising. And of course some tests are here: https://lists.gnu.org/archive/html/qemu-devel/2014-03/msg00584.html for some of the bullets you are listing (not all yet). > Also, vhost-user is documented! See here: > https://lists.gnu.org/archive/html/qemu-devel/2014-03/msg00581.html as I told you, we'll send a contribution with ivshmem's documentation. > The only part of ivshmem that vhost doesn't include is the n-way > inter-guest doorbell. This is the part that requires a server and uio > driver. vhost only supports host->guest and guest->host doorbells. agree: both will need it: vhost and ivshmem requires a doorbell for VM2VM, but then we'll have a security issue to be managed by Qemu for vhost and ivshmem. I'll be pleased to contribute on it for ivshmem thru another thread that this one. >> ivhsmem does not require DPDK kernel driver. see memnic's PMD: >> http://dpdk.org/browse/memnic/tree/pmd/pmd_memnic.c > > You're right, I was confusing memnic and the vhost example in DPDK. Definitively, it proves a lack of documentation. You welcome. Olivier did explain it: >> ivhsmem does not require hugetlbfs. It is optional. >> >> > * it doesn't require ivshmem (it does require shared memory, which >> > will also be added to 2.1) > > Right, hugetlbfs is not required. A posix shared memory or tmpfs > can be used instead. For instance, to use /dev/shm/foobar: > > qemu-system-x86_64 -enable-kvm -cpu host [...] \ > -device ivshmem,size=16,shm=foobar Best regards, Vincent