Re: [Qemu-devel] Why I advise against using ivshmem
Stefan Hajnoczi stefa...@gmail.com writes: On Tue, Jun 17, 2014 at 11:44:11AM +0200, Paolo Bonzini wrote: Il 17/06/2014 11:03, David Marchand ha scritto: Unless someone steps up and maintains ivshmem, I think it should be deprecated and dropped from QEMU. Then I can maintain ivshmem for QEMU. If this is ok, I will send a patch for MAINTAINERS file. Typically, adding yourself to maintainers is done only after having proved your ability to be a maintainer. :) So, let's stop talking and go back to code! You can start doing what was suggested elsewhere in the thread: get the server and uio driver merged into the QEMU tree, document the protocol in docs/specs/ivshmem_device_spec.txt, and start fixing bugs such as the ones that Markus reported. One more thing to add to the list: static void ivshmem_read(void *opaque, const uint8_t * buf, int flags) The flags argument should be size. Size should be checked before accessing buf. Please also see the bug fixes in the following unapplied patch: [PATCH] ivshmem: fix potential OOB r/w access (#2) by Sebastian Krahmer https://lists.gnu.org/archive/html/qemu-devel/2014-04/msg03538.html Another one: most devices can be controlled via a dedicated CONFIG_DEVNAME, but not ivshmem: it uses CONFIG_KVM and CONFIG_PCI. Giving it its own CONFIG_IVSHMEM would be nice. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Why I advise against using ivshmem
On Wed, Jun 18, 2014 at 10:57 PM, David Marchand david.march...@6wind.com wrote: On 06/18/2014 12:48 PM, Stefan Hajnoczi wrote: One more thing to add to the list: static void ivshmem_read(void *opaque, const uint8_t * buf, int flags) The flags argument should be size. Size should be checked before accessing buf. You are welcome to send a fix and I will review it. I don't plan to send ivshmem patches in the near future because I don't use or support it. I thought you were interested in bringing ivshmem up to a level where distros feel comfortable enabling and supporting it. Getting there will require effort from you to audit, clean up, and achieve test coverage. That's what a maintainer needs to do in a case like this. Stefan -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Why I advise against using ivshmem
On 06/18/2014 05:01 PM, Andreas Färber wrote: late onto this thread: SUSE Security team has just recently done a thorough review of QEMU ivshmem code because a customer has requested this be supported in SLES12. Multiple security-related patches were submitted by Stefan Hajnoczi and Sebastian Krahmer, and I fear they are probably still not merged for lack of active maintainer... In such cases, after review, I expect them to be picked up by Peter as committer or via qemu-trivial. So -1, against dropping it. Are these patches on patchwork ? Vincent, you will find an RFC for an ivshmem-test in the qemu-devel list archives or possibly on my qtest branch. The blocking issue that I haven't worked on yet is that we can't unconditionally run the qtest because it depends on KVM enabled at configure time (as opposed to runtime) to have the device available. http://patchwork.ozlabs.org/patch/336367/ As others have stated before, the nahanni server seems unmaintained, thus not getting packaged by SUSE either and making testing the interrupt parts of ivshmem difficult - unless we sort out and fill with actual test code my proposed qtest. Thanks for the RFC patch. About ivshmem server, yes I will look at it. I will see what I can propose or if importing nahanni implementation as-is is the best solution. Anyway, first, documentation. -- David Marchand -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Why I advise against using ivshmem
On Tue, Jun 17, 2014 at 11:44:11AM +0200, Paolo Bonzini wrote: Il 17/06/2014 11:03, David Marchand ha scritto: Unless someone steps up and maintains ivshmem, I think it should be deprecated and dropped from QEMU. Then I can maintain ivshmem for QEMU. If this is ok, I will send a patch for MAINTAINERS file. Typically, adding yourself to maintainers is done only after having proved your ability to be a maintainer. :) So, let's stop talking and go back to code! You can start doing what was suggested elsewhere in the thread: get the server and uio driver merged into the QEMU tree, document the protocol in docs/specs/ivshmem_device_spec.txt, and start fixing bugs such as the ones that Markus reported. One more thing to add to the list: static void ivshmem_read(void *opaque, const uint8_t * buf, int flags) The flags argument should be size. Size should be checked before accessing buf. Please also see the bug fixes in the following unapplied patch: [PATCH] ivshmem: fix potential OOB r/w access (#2) by Sebastian Krahmer https://lists.gnu.org/archive/html/qemu-devel/2014-04/msg03538.html Stefan pgp5LqUdx7Rvg.pgp Description: PGP signature
Re: [Qemu-devel] Why I advise against using ivshmem
On Tue, Jun 17, 2014 at 11:03:32AM +0200, David Marchand wrote: On 06/17/2014 04:54 AM, Stefan Hajnoczi wrote: ivshmem has a performance disadvantage for guest-to-host communication. Since the shared memory is exposed as PCI BARs, the guest has to memcpy into the shared memory. vhost-user can access guest memory directly and avoid the copy inside the guest. Actually, you can avoid this memory copy using frameworks like DPDK. I guess it's careful to allocate all packets in the mmapped BAR? That's fine if you can modify applications but doesn't work for unmodified applications using regular networking APIs. Stefan pgpPxEpGjindt.pgp Description: PGP signature
Re: [Qemu-devel] Why I advise against using ivshmem
Hello Stefan, On 06/18/2014 12:48 PM, Stefan Hajnoczi wrote: One more thing to add to the list: static void ivshmem_read(void *opaque, const uint8_t * buf, int flags) The flags argument should be size. Size should be checked before accessing buf. You are welcome to send a fix and I will review it. Please also see the bug fixes in the following unapplied patch: [PATCH] ivshmem: fix potential OOB r/w access (#2) by Sebastian Krahmer https://lists.gnu.org/archive/html/qemu-devel/2014-04/msg03538.html Thanks for the pointer. I'll check it. -- David Marchand -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Why I advise against using ivshmem
On 06/18/2014 12:51 PM, Stefan Hajnoczi wrote: Actually, you can avoid this memory copy using frameworks like DPDK. I guess it's careful to allocate all packets in the mmapped BAR? Yes. That's fine if you can modify applications but doesn't work for unmodified applications using regular networking APIs. If you have access to source code, this should not be a problem. -- David Marchand -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Why I advise against using ivshmem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 18.06.2014 12:48, schrieb Stefan Hajnoczi: On Tue, Jun 17, 2014 at 11:44:11AM +0200, Paolo Bonzini wrote: Il 17/06/2014 11:03, David Marchand ha scritto: Unless someone steps up and maintains ivshmem, I think it should be deprecated and dropped from QEMU. Then I can maintain ivshmem for QEMU. If this is ok, I will send a patch for MAINTAINERS file. Typically, adding yourself to maintainers is done only after having proved your ability to be a maintainer. :) So, let's stop talking and go back to code! You can start doing what was suggested elsewhere in the thread: get the server and uio driver merged into the QEMU tree, document the protocol in docs/specs/ivshmem_device_spec.txt, and start fixing bugs such as the ones that Markus reported. One more thing to add to the list: static void ivshmem_read(void *opaque, const uint8_t * buf, int flags) The flags argument should be size. Size should be checked before accessing buf. Please also see the bug fixes in the following unapplied patch: [PATCH] ivshmem: fix potential OOB r/w access (#2) by Sebastian Krahmer https://lists.gnu.org/archive/html/qemu-devel/2014-04/msg03538.html Jumping late onto this thread: SUSE Security team has just recently done a thorough review of QEMU ivshmem code because a customer has requested this be supported in SLES12. Multiple security-related patches were submitted by Stefan Hajnoczi and Sebastian Krahmer, and I fear they are probably still not merged for lack of active maintainer... In such cases, after review, I expect them to be picked up by Peter as committer or via qemu-trivial. So -1, against dropping it. Vincent, you will find an RFC for an ivshmem-test in the qemu-devel list archives or possibly on my qtest branch. The blocking issue that I haven't worked on yet is that we can't unconditionally run the qtest because it depends on KVM enabled at configure time (as opposed to runtime) to have the device available. http://patchwork.ozlabs.org/patch/336367/ As others have stated before, the nahanni server seems unmaintained, thus not getting packaged by SUSE either and making testing the interrupt parts of ivshmem difficult - unless we sort out and fill with actual test code my proposed qtest. Regards, Andreas - -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJToanZAAoJEPou0S0+fgE/L6YP/jtPiwvz3YoW3+H/h/YzrnE7 xVP92jj5orzmbG3HMmEnx0l7YrtzYkwymgUO56dy2SrLFe0xVMnxuzcHLzHLsnm3 bYvMVq3eAx8sdx9c/O2B/rQbNo2p8PF/luTNewN7A+w5TX0XgxdI3TpLT2pVxf0b kMaBnfivzUf2JY/zg6NaiGnwvVrA/0kXsCGKcTBiMQxOX2EdDgNak842SjlmS332 dPbqp5PIMdxwCxI/p+gpmu0cSy1bl2H6N2gkmKQZ63Z2tA7bWn/APdQeHyOcESZE xRAfDz2Cs3/6EL7FLirJWdwT9EMNaFcM+eRgIqDamFzviQPZVuLKdDUteO1k9x1s FlhL3ZRa3qHair9ByEJItqzneAeYmuwZ2DkKh4p/HQfbcxLzZlL8a1EEtYz5DTy0 8+Ax6IU5U5RZmwJ4/M/Ov5eT4t/fNe0MbG3mf5A8FJ6GWoF11ut/wyj70p/EmXua QjUblK/eFemN4YvIi0ovD4DR9ZH2+bXOb44wKL7yFahKLldaP4y9DhJTap2J0mT1 b62FfFZ6hVIGP5n30OHLlhe39QY6SyIPc4JNc9VZ3GcpXtfOHPUOAD/ykt/As1P3 cPfL+jM0QSb6VNJHNbvUsSlJ6xI26qEWzyJ5R7ww4fyEoq4XiE2RCDUWJ2t9/jQb +Bi/esBUDhAduc1Eh3FK =MtPH -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Why I advise against using ivshmem
Il 18/06/2014 16:57, David Marchand ha scritto: Hello Stefan, On 06/18/2014 12:48 PM, Stefan Hajnoczi wrote: One more thing to add to the list: static void ivshmem_read(void *opaque, const uint8_t * buf, int flags) The flags argument should be size. Size should be checked before accessing buf. You are welcome to send a fix and I will review it. This is not what a maintainer should do. A maintainer should, if possible, contribute fixes to improve the code. I know this is very different from usual company-style development (even open source software can be developed on with methods more typical of proprietary software), but we're asking you to do it because you evidently understand ivshmem better than us. Claudio has more experience with free/open-source software. Since he's interested in ivshmem, he can help you too. Perhaps you could try sending out the patch, and Claudio can review it and send pull requests at least in the beginning? Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Why I advise against using ivshmem
Hello all, On 06/17/2014 04:54 AM, Stefan Hajnoczi wrote: ivshmem has a performance disadvantage for guest-to-host communication. Since the shared memory is exposed as PCI BARs, the guest has to memcpy into the shared memory. vhost-user can access guest memory directly and avoid the copy inside the guest. Actually, you can avoid this memory copy using frameworks like DPDK. Unless someone steps up and maintains ivshmem, I think it should be deprecated and dropped from QEMU. Then I can maintain ivshmem for QEMU. If this is ok, I will send a patch for MAINTAINERS file. -- David Marchand -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Why I advise against using ivshmem
Il 17/06/2014 11:03, David Marchand ha scritto: Unless someone steps up and maintains ivshmem, I think it should be deprecated and dropped from QEMU. Then I can maintain ivshmem for QEMU. If this is ok, I will send a patch for MAINTAINERS file. Typically, adding yourself to maintainers is done only after having proved your ability to be a maintainer. :) So, let's stop talking and go back to code! You can start doing what was suggested elsewhere in the thread: get the server and uio driver merged into the QEMU tree, document the protocol in docs/specs/ivshmem_device_spec.txt, and start fixing bugs such as the ones that Markus reported. Since ivshmem is basically KVM-only (it has a soft dependency on ioeventfd), CC the patches to kvm@vger.kernel.org and I'll merge them via the KVM tree for now. I'll (more than) gladly give maintainership away in due time. Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Why I advise against using ivshmem
On Fri, Jun 13, 2014 at 10:10 PM, Paolo Bonzini pbonz...@redhat.com wrote: Il 13/06/2014 15:41, Vincent JARDIN ha scritto: 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). Right, ivshmem is better for guest-to-guest. vhost-user is not restricted to networking, but it is indeed more focused on guest-to-host. ivshmem is usable for guest-to-host, but I would prefer still some hybrid that uses vhost-like messages to pass the shared memory fds to the external program. ivshmem has a performance disadvantage for guest-to-host communication. Since the shared memory is exposed as PCI BARs, the guest has to memcpy into the shared memory. vhost-user can access guest memory directly and avoid the copy inside the guest. Unless someone steps up and maintains ivshmem, I think it should be deprecated and dropped from QEMU. Stefan -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Why I advise against using ivshmem
(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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Why I advise against using ivshmem
Some dropped quoted text restored. Vincent JARDIN vincent.jar...@6wind.com writes: 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/ We're grateful for David's patch for qemu-char.c, but this isn't ivshmem maintenance, yet. - Error handling is generally poor. For instance, device_add ivshmem kills your guest instantly. - More subjectively, I don't trust the code to be robust against abuse by our own guest, or the other guests sharing the memory. Convincing me would take a code audit. - MAINTAINERS doesn't cover ivshmem.c. - The last non-trivial commit that isn't obviously part of some tree-wide infrastructure or cleanup work is from September 2012 (commit c08ba66). 2. There is no libvirt support One can use qemu without libvivrt. You asked me for my reasons for disliking ivshmem. This is one. Sure, I can drink my water through a straw while standing on one foot, but that doesn't mean I have to like it. And me not liking it doesn't mean the next guy shouldn't like it. To each their own. 3. Out-of-tree server program required for full functionality Interrupts require a shared memory server running in the host (see docs/specs/ivshmem_device_spec.txt). It doesn't tell where to find one. The initial commit 6cbf4c8 points to www.gitorious.org/nahanni. That repository's last commit is from September 2012. He's dead, Jim. ivshmem_device_spec.txt is silent on what the server is supposed to do. We have the source code, it provides the documentation to write our own better server program. Good for you. Not good enough for the QEMU community. QEMU features requiring on out-of-tree software to be useful are fine, as long as said out-of-tree software is readily available to QEMU developers and users. Free software with a community around it and packaged in major distros qualifies. If you haven't got that, talk to us to find out whether what you've got qualifies, and if not, what you'd have to do to make it qualify. Back when we accepted ivshmem, the out-of-tree parts it needs were well below the community packaged bar. But folks interested in it talked to us, and the fact that it's in shows that QEMU maintainers decided what they had then was enough. Unfortunately, we now have considerably less: Nahanni appears to be dead. An apparently dead git repository you can study is not enough. The fact that you hold an improved reimplementation privately is immaterial. So is the (plausible) claim that others could also create a reimplementation. If this server requires privileges: I don't trust it without an audit. 4. Out-of-tree kernel uio driver required No, it is optional. Good to know. Would you be willing to send a patch to ivshmem_device_spec.txt clarifying that? The device is intended to be used with the provided UIO driver (ivshmem_device_spec.txt again). As far as I can tell, the provided UIO driver is the one in the dead Nahanni repo. By now, you should be expecting this: I don't trust that one either. 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. Up to now, I've been wearing my QEMU hat. Let me exchange it for my Red one for a bit. We (Red Hat) don't just package ship metric tons of random free software. We package ship useful free software we can support for many, many years. Sometimes, we find that we have to focus serious development resources on making something useful supportable (Paolo mentioned qcow2). We obviously can't focus on everything, though. Anyway, ivshmem didn't make the cut for RHEL-7.0. Sorry if that inconveniences you. To get it into RHEL, you need to show it's both useful and supportable. Building a community around it would go a long way towards that. If you want to discuss this in more detail with us, you may want to try communication channels provided by your RHEL subscription in addition to the QEMU development mailing list. Don't be shy, you're paying for it! As always, I'm not speaking for myself, not my employer. Okay, wearing my QEMU hat again. 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. Using something isn't the same as maintaining something. But it's a necessary
Re: [Qemu-devel] Why I advise against using ivshmem
(+merging with Paolo's email because of overlaps) see inline (I am not on all mailing list, please, keep the cc list). 1. ivshmem code needs work, but has no maintainer See David's contributions: http://patchwork.ozlabs.org/patch/358750/ We're grateful for David's patch for qemu-char.c, but this isn't ivshmem maintenance, yet. others can come (doc), see below. 2. There is no libvirt support One can use qemu without libvivrt. You asked me for my reasons for disliking ivshmem. This is one. Sure, I can drink my water through a straw while standing on one foot, but that doesn't mean I have to like it. And me not liking it doesn't mean the next guy shouldn't like it. To each their own. I like using qemu without libvirt, libvirt is not part of qemu. Let's avoid trolling about it ;) Back when we accepted ivshmem, the out-of-tree parts it needs were well below the community packaged bar. But folks interested in it talked to us, and the fact that it's in shows that QEMU maintainers decided what they had then was enough. Unfortunately, we now have considerably less: Nahanni appears to be dead. agree and to bad it is dead. We should let Nahanni dead since ivshmem is a QEMU topic now, see below. Does it make sense? An apparently dead git repository you can study is not enough. The fact that you hold an improved reimplementation privately is immaterial. So is the (plausible) claim that others could also create a reimplementation. Got the point. What's about a patch to docs/specs/ivshmem_device_spec.txt that improves it? I can make qemu's ivshmem better: - keep explaining memnic for instance, - explain how to write other ivshmem. does it help? 4. Out-of-tree kernel uio driver required No, it is optional. Good to know. Would you be willing to send a patch to ivshmem_device_spec.txt clarifying that? got the point, yes, * 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. Up to now, I've been wearing my QEMU hat. Let me exchange it for my Red one for a bit. We (Red Hat) don't just package ship metric tons of random free software. We package ship useful free software we can support for many, many years. Sometimes, we find that we have to focus serious development resources on making something useful supportable (Paolo mentioned qcow2). We obviously can't focus on everything, though. Good open technology should rule. ivshmem has use cases. And I go agree with you, it is like the phoenix, it has to be re-explained/documented to be back to life. I was not aware that the QEMU community was missing ivshmem contributors (my bad I did not check MAINTAINERS). Anyway, ivshmem didn't make the cut for RHEL-7.0. Sorry if that inconveniences you. To get it into RHEL, you need to show it's both useful and supportable. Building a community around it would go a long way towards that. understood. If you want to discuss this in more detail with us, you may want to try communication channels provided by your RHEL subscription in addition to the QEMU development mailing list. Don't be shy, you're paying for it! done. I was focusing on DPDK.org and ignorant of QEMU's status, thinking Redhat was covering it. How to know which part of an opensource software are and are not included into Redhat. Sales are ignorant about it ;). Redhat randomly disables some files at compilation (for some good reasons I guess, but not public rationals or I am missing something). Feel free to open this PR to anyone: https://bugzilla.redhat.com/show_bug.cgi?id=1088332 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. Using something isn't the same as maintaining something. But it's a necessary first step. understood, after David's patch, documentation will come. (now Paolo's email since there were some overlaps) 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. You made the right choices, these out-of-tree packages are not required. You can use QEMU's ivshmem without any of the out-of-tree packages. The out-of-tree packages are just some examples of using ivshmem. 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. I and David (cc) are working on making it better based on the issues that are found. Now, vhost-user is in the process of being merged for 2.1. Compared to the DPDK solution: now, you cannot compare vhost-user to DPDK/ivshmem; both should exsit because
Re: [Qemu-devel] Why I advise against using ivshmem
Nahanni's poor current development coupled with virtIO's promising expansion was what encouraged us to explore virtIO-serial [1] for inter-virtual machine communication. Though virtIO-serial as it is isn't helpful for inter-VM communication, some work is needed for this purpose and this is exactly what we (I and two of my fellow classmates) accomplished. We haven't published it yet since we do need to polish yet for upstreaming it and are planning do it in near future. [1]: http://fedoraproject.org/wiki/Features/VirtioSerial On Fri, Jun 13, 2014 at 2:56 PM, Vincent JARDIN vincent.jar...@6wind.com wrote: (+merging with Paolo's email because of overlaps) see inline (I am not on all mailing list, please, keep the cc list). 1. ivshmem code needs work, but has no maintainer See David's contributions: http://patchwork.ozlabs.org/patch/358750/ We're grateful for David's patch for qemu-char.c, but this isn't ivshmem maintenance, yet. others can come (doc), see below. 2. There is no libvirt support One can use qemu without libvivrt. You asked me for my reasons for disliking ivshmem. This is one. Sure, I can drink my water through a straw while standing on one foot, but that doesn't mean I have to like it. And me not liking it doesn't mean the next guy shouldn't like it. To each their own. I like using qemu without libvirt, libvirt is not part of qemu. Let's avoid trolling about it ;) Back when we accepted ivshmem, the out-of-tree parts it needs were well below the community packaged bar. But folks interested in it talked to us, and the fact that it's in shows that QEMU maintainers decided what they had then was enough. Unfortunately, we now have considerably less: Nahanni appears to be dead. agree and to bad it is dead. We should let Nahanni dead since ivshmem is a QEMU topic now, see below. Does it make sense? An apparently dead git repository you can study is not enough. The fact that you hold an improved reimplementation privately is immaterial. So is the (plausible) claim that others could also create a reimplementation. Got the point. What's about a patch to docs/specs/ivshmem_device_spec.txt that improves it? I can make qemu's ivshmem better: - keep explaining memnic for instance, - explain how to write other ivshmem. does it help? 4. Out-of-tree kernel uio driver required No, it is optional. Good to know. Would you be willing to send a patch to ivshmem_device_spec.txt clarifying that? got the point, yes, * 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. Up to now, I've been wearing my QEMU hat. Let me exchange it for my Red one for a bit. We (Red Hat) don't just package ship metric tons of random free software. We package ship useful free software we can support for many, many years. Sometimes, we find that we have to focus serious development resources on making something useful supportable (Paolo mentioned qcow2). We obviously can't focus on everything, though. Good open technology should rule. ivshmem has use cases. And I go agree with you, it is like the phoenix, it has to be re-explained/documented to be back to life. I was not aware that the QEMU community was missing ivshmem contributors (my bad I did not check MAINTAINERS). Anyway, ivshmem didn't make the cut for RHEL-7.0. Sorry if that inconveniences you. To get it into RHEL, you need to show it's both useful and supportable. Building a community around it would go a long way towards that. understood. If you want to discuss this in more detail with us, you may want to try communication channels provided by your RHEL subscription in addition to the QEMU development mailing list. Don't be shy, you're paying for it! done. I was focusing on DPDK.org and ignorant of QEMU's status, thinking Redhat was covering it. How to know which part of an opensource software are and are not included into Redhat. Sales are ignorant about it ;). Redhat randomly disables some files at compilation (for some good reasons I guess, but not public rationals or I am missing something). Feel free to open this PR to anyone: https://bugzilla.redhat.com/show_bug.cgi?id=1088332 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. Using something isn't the same as maintaining something. But it's a necessary first step. understood, after David's patch, documentation will come. (now Paolo's email since there were some overlaps) 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. You made the right choices, these out-of-tree packages are not
Re: [Qemu-devel] Why I advise against using ivshmem
Il 13/06/2014 11:26, Vincent JARDIN ha scritto: 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. You made the right choices, these out-of-tree packages are not required. You can use QEMU's ivshmem without any of the out-of-tree packages. The out-of-tree packages are just some examples of using ivshmem. 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. Disabling all the unwanted devices is a lot of work and thankless too (you only get complaints, in fact!). But we prefer to ship only what we know we can test, support and improve. We do not want customers' bug reports to languish because they are using code that cannot really be fixed. Note that we do take into account community contributions in choosing which new code can be supported. For example most work on VMDK images was done by Fam when he was a student, libiscsi is mostly the work of Peter Lieven, and so on; both of them are supported in RHEL. These people did/do a great job, and we were happy to embrace those features! Now, putting back my QEMU hat... 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. I and David (cc) are working on making it better based on the issues that are found. Now, vhost-user is in the process of being merged for 2.1. Compared to the DPDK solution: 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: - 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 None of these is virtio specific, except the last (even then, you could repurpose the messages to pass the address of the whole shared memory area, instead of the vrings only). Yes, the only front-end for vhost-user, right now, is a network device. But it is possible to connect vhost-scsi to vhost-user as well, it is possible to develop a vhost-serial as well, and it is possible to only use the RPC and develop arbitrary shared-memory based tools using this API. It's just that no one has done it yet. Also, vhost-user is documented! See here: https://lists.gnu.org/archive/html/qemu-devel/2014-03/msg00581.html 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. * it doesn't require hugetlbfs (which only enabled shared memory by chance in older QEMU releases, that was never documented) ivhsmem does not require hugetlbfs. It is optional. * it doesn't require the kernel driver from the DPDK sample 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. Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Why I advise against using ivshmem
Hello, On 06/13/2014 11:26 AM, Vincent JARDIN wrote: 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 Regards, Olivier -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Why I advise against using ivshmem
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Why I advise against using ivshmem
Il 13/06/2014 15:41, Vincent JARDIN ha scritto: 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? I don't know exactly what the answer is, and this is probably not the right list to discuss it. I guess there are partnership programs with Red Hat that I don't know the details of, but these are more for management folks and not really for developers. ivshmem in particular was disabled even in RHEL7 beta, so you could have found out about this in December and opened a bug in Bugzilla about it. 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? The first things to do are: 1) try to understand if there is any value in a simplified shared memory device with no interrupts (and those no eventfd or uio dependencies, not even optionally). You are not using them because DPDK only does polling and basically reserves a core for the NIC code. If so, this would be a very simple device, just a 100 or so lines of code. We could get this in upstream, and it would be likely enabled in RHEL too. 2) if not, get the server and uio driver merged into the QEMU tree, and document the protocol in docs/specs/ivshmem_device_spec.txt. It doesn't matter if the code comes from the Nahanni repository or from your own implementation. Also start fixing bugs such as the ones that Markus reported (removing all exit() invocations). Writing testcases using the qtest framework would also be useful, but first of all it is important to make ivshmem easier to use. If not, what do you use at Redhat to test Qemu? We do integration testing using autotest/virt-test (QEMU and KVM developers for upstream use it too) and also some manual functional tests. Contributing ivshmem tests to the virt-test would also be helpful in demonstrating your interest in maintaining ivshmem. The repository and documentation is at https://github.com/autotest/virt-test/ (a bit Fedora-centric). 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). Right, ivshmem is better for guest-to-guest. vhost-user is not restricted to networking, but it is indeed more focused on guest-to-host. ivshmem is usable for guest-to-host, but I would prefer still some hybrid that uses vhost-like messages to pass the shared memory fds to the external program. Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
