Re: [Qemu-devel] Why I advise against using ivshmem

[Vincent JARDIN <vincent.jardin@6wind.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