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
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
