From: Vincent JARDIN <vincent.jardin@6wind.com> To: qemu-devel@nongnu.org Cc: Henning Schild <henning.schild@siemens.com>, Olivier MATZ <olivier.matz@6wind.com>, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org, "thomas.monjalon@6wind.com" <thomas.monjalon@6wind.com>, Paolo Bonzini <pbonzini@redhat.com>, David Marchand <david.marchand@6wind.com> Subject: Re: [Qemu-devel] Why I advise against using ivshmem Date: Sat, 14 Jun 2014 20:01:54 +0200 [thread overview] Message-ID: <539C8E12.7050504@6wind.com> (raw) In-Reply-To: <539B064D.2050501@redhat.com> (resending, this email is missing at http://lists.nongnu.org/archive/html/qemu-devel/2014-06/index.html) > 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: http://lists.nongnu.org/archive/html/qemu-devel/2014-06/msg03127.html >> 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
WARNING: multiple messages have this Message-ID (diff)
From: Vincent JARDIN <vincent.jardin@6wind.com> To: qemu-devel@nongnu.org Cc: Henning Schild <henning.schild@siemens.com>, Olivier MATZ <olivier.matz@6wind.com>, kvm@vger.kernel.org, Markus Armbruster <armbru@redhat.com>, virtualization@lists.linux-foundation.org, "thomas.monjalon@6wind.com" <thomas.monjalon@6wind.com>, Paolo Bonzini <pbonzini@redhat.com>, David Marchand <david.marchand@6wind.com> Subject: Re: [Qemu-devel] Why I advise against using ivshmem Date: Sat, 14 Jun 2014 20:01:54 +0200 [thread overview] Message-ID: <539C8E12.7050504@6wind.com> (raw) In-Reply-To: <539B064D.2050501@redhat.com> (resending, this email is missing at http://lists.nongnu.org/archive/html/qemu-devel/2014-06/index.html) > 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: http://lists.nongnu.org/archive/html/qemu-devel/2014-06/msg03127.html >> 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
next prev parent reply other threads:[~2014-06-14 18:01 UTC|newest] Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-06-10 16:48 Using virtio for inter-VM communication Henning Schild 2014-06-10 16:48 ` [Qemu-devel] " Henning Schild 2014-06-10 22:15 ` Vincent JARDIN 2014-06-10 22:15 ` Vincent JARDIN 2014-06-10 22:15 ` [Qemu-devel] " Vincent JARDIN 2014-06-12 6:48 ` Markus Armbruster 2014-06-12 6:48 ` Markus Armbruster 2014-06-12 6:48 ` [Qemu-devel] " Markus Armbruster 2014-06-12 7:44 ` Henning Schild 2014-06-12 7:44 ` [Qemu-devel] " Henning Schild 2014-06-12 9:31 ` Vincent JARDIN 2014-06-12 9:31 ` Vincent JARDIN 2014-06-12 9:31 ` [Qemu-devel] " Vincent JARDIN 2014-06-12 12:55 ` Markus Armbruster 2014-06-12 14:40 ` Why I advise against using ivshmem (was: [Qemu-devel] Using virtio for inter-VM communication) Markus Armbruster 2014-06-12 14:40 ` Markus Armbruster 2014-06-12 14:40 ` [Qemu-devel] Why I advise against using ivshmem (was: " Markus Armbruster 2014-06-12 16:02 ` Why I advise against using ivshmem Vincent JARDIN 2014-06-12 16:02 ` [Qemu-devel] " Vincent JARDIN 2014-06-12 16:54 ` Paolo Bonzini 2014-06-12 16:54 ` [Qemu-devel] " Paolo Bonzini 2014-06-13 8:46 ` Markus Armbruster 2014-06-13 9:26 ` Vincent JARDIN 2014-06-13 9:31 ` Jobin Raju George 2014-06-13 9:31 ` Jobin Raju George 2014-06-13 9:31 ` Jobin Raju George 2014-06-13 9:48 ` Olivier MATZ 2014-06-13 9:48 ` Olivier MATZ 2014-06-13 9:48 ` Olivier MATZ 2014-06-13 10:09 ` Paolo Bonzini 2014-06-13 13:41 ` Vincent JARDIN 2014-06-13 13:41 ` Vincent JARDIN 2014-06-13 13:41 ` Vincent JARDIN 2014-06-13 14:10 ` Paolo Bonzini 2014-06-13 14:10 ` Paolo Bonzini 2014-06-14 18:01 ` Vincent JARDIN [this message] 2014-06-14 18:01 ` Vincent JARDIN 2014-06-17 2:54 ` Stefan Hajnoczi 2014-06-17 9:03 ` David Marchand 2014-06-17 9:03 ` David Marchand 2014-06-17 9:44 ` Paolo Bonzini 2014-06-18 10:48 ` Stefan Hajnoczi 2014-06-18 10:48 ` Stefan Hajnoczi 2014-06-18 14:57 ` David Marchand 2014-06-18 14:57 ` David Marchand 2014-06-18 14:57 ` David Marchand 2014-06-18 15:10 ` Paolo Bonzini 2014-06-21 9:34 ` Stefan Hajnoczi 2014-06-26 20:02 ` Cam Macdonell 2014-06-26 20:02 ` Cam Macdonell 2014-06-18 15:01 ` Andreas Färber 2014-06-18 15:01 ` Andreas Färber 2014-06-19 8:25 ` David Marchand 2014-06-19 8:25 ` David Marchand 2014-06-19 8:25 ` David Marchand 2014-06-18 15:01 ` Andreas Färber 2014-06-30 11:10 ` Markus Armbruster 2014-06-30 11:10 ` Markus Armbruster 2014-06-30 11:10 ` Markus Armbruster 2014-06-18 10:51 ` Stefan Hajnoczi 2014-06-18 10:51 ` Stefan Hajnoczi 2014-06-18 14:58 ` David Marchand 2014-06-18 14:58 ` David Marchand 2014-06-18 14:58 ` David Marchand 2014-06-18 14:22 ` Claudio Fontana 2014-06-17 9:03 ` David Marchand 2014-06-13 9:29 ` Jobin Raju George 2014-06-13 9:29 ` [Qemu-devel] " Jobin Raju George 2014-06-13 9:29 ` Jobin Raju George 2014-06-12 16:02 ` Vincent JARDIN 2014-06-12 2:27 ` Using virtio for inter-VM communication Rusty Russell 2014-06-12 2:27 ` Rusty Russell 2014-06-12 2:27 ` [Qemu-devel] " Rusty Russell 2014-06-12 5:32 ` Jan Kiszka 2014-06-12 5:32 ` [Qemu-devel] " Jan Kiszka 2014-06-13 0:47 ` Rusty Russell 2014-06-13 0:47 ` [Qemu-devel] " Rusty Russell 2014-06-13 6:23 ` Jan Kiszka 2014-06-13 6:23 ` [Qemu-devel] " Jan Kiszka 2014-06-13 8:45 ` Paolo Bonzini 2014-06-13 8:45 ` [Qemu-devel] " Paolo Bonzini 2014-06-15 6:20 ` Jan Kiszka 2014-06-15 6:20 ` Jan Kiszka 2014-06-15 6:20 ` [Qemu-devel] " Jan Kiszka 2014-06-17 5:24 ` Paolo Bonzini 2014-06-17 5:24 ` [Qemu-devel] " Paolo Bonzini 2014-06-17 5:57 ` Jan Kiszka 2014-06-17 5:57 ` Jan Kiszka 2014-06-17 5:57 ` [Qemu-devel] " Jan Kiszka 2014-06-17 5:24 ` Paolo Bonzini 2014-06-12 5:32 ` Jan Kiszka
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=539C8E12.7050504@6wind.com \ --to=vincent.jardin@6wind.com \ --cc=david.marchand@6wind.com \ --cc=henning.schild@siemens.com \ --cc=kvm@vger.kernel.org \ --cc=olivier.matz@6wind.com \ --cc=pbonzini@redhat.com \ --cc=qemu-devel@nongnu.org \ --cc=thomas.monjalon@6wind.com \ --cc=virtualization@lists.linux-foundation.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.