search for: memnic

...the >> hypervisor. That way we can share memory between virtual machines. >> Ivshmem is nice and simple but does not seem to be used anymore. >> And it >> does not define higher level devices, like a console. > > FYI, ivhsmem is used here: > http://dpdk.org/browse/memnic/tree/ > > http://dpdk.org/browse/memnic/tree/pmd/pmd_memnic.c#n449 > > There are some few other references too, if needed. It may be used, but that doesn't mean it's maintained, or robust against abuse. My advice is to steer clear of it.

...the >> hypervisor. That way we can share memory between virtual machines. >> Ivshmem is nice and simple but does not seem to be used anymore. >> And it >> does not define higher level devices, like a console. > > FYI, ivhsmem is used here: > http://dpdk.org/browse/memnic/tree/ > > http://dpdk.org/browse/memnic/tree/pmd/pmd_memnic.c#n449 > > There are some few other references too, if needed. It may be used, but that doesn't mean it's maintained, or robust against abuse. My advice is to steer clear of it.

...ich 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

...ich 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

...t 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 p...

...otest/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...

...otest/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...

...n 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, &g...

Hi, i am working on the jailhouse[1] project and am currently looking at inter-VM communication. We want to connect guests directly with virtual consoles based on shared memory. The code complexity in the hypervisor should be minimal, it should just make the shared memory discoverable and provide a signaling mechanism. We would like to reuse virtio so that Linux-guests will eventually just work

Hi, i am working on the jailhouse[1] project and am currently looking at inter-VM communication. We want to connect guests directly with virtual consoles based on shared memory. The code complexity in the hypervisor should be minimal, it should just make the shared memory discoverable and provide a signaling mechanism. We would like to reuse virtio so that Linux-guests will eventually just work

Some dropped quoted text restored. Vincent JARDIN <vincent.jardin at 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

Some dropped quoted text restored. Vincent JARDIN <vincent.jardin at 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

...a ivshmem[2] device for the > hypervisor. That way we can share memory between virtual machines. > Ivshmem is nice and simple but does not seem to be used anymore. > And it > does not define higher level devices, like a console. FYI, ivhsmem is used here: http://dpdk.org/browse/memnic/tree/ http://dpdk.org/browse/memnic/tree/pmd/pmd_memnic.c#n449 There are some few other references too, if needed. Best regards, Vincent

...way we can share memory between virtual machines. > >> Ivshmem is nice and simple but does not seem to be used anymore. > >> And it > >> does not define higher level devices, like a console. > > > > FYI, ivhsmem is used here: > > http://dpdk.org/browse/memnic/tree/ > > > > http://dpdk.org/browse/memnic/tree/pmd/pmd_memnic.c#n449 > > > > There are some few other references too, if needed. > > It may be used, but that doesn't mean it's maintained, or robust > against abuse. My advice is to steer clear of it. Cou...

...ent 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...

...between virtual machines. >> >> Ivshmem is nice and simple but does not seem to be used anymore. >> >> And it >> >> does not define higher level devices, like a console. >> > >> > FYI, ivhsmem is used here: >> > http://dpdk.org/browse/memnic/tree/ >> > >> > http://dpdk.org/browse/memnic/tree/pmd/pmd_memnic.c#n449 >> > >> > There are some few other references too, if needed. >> >> It may be used, but that doesn't mean it's maintained, or robust >> against abuse. My advice i...

...between virtual machines. >> >> Ivshmem is nice and simple but does not seem to be used anymore. >> >> And it >> >> does not define higher level devices, like a console. >> > >> > FYI, ivhsmem is used here: >> > http://dpdk.org/browse/memnic/tree/ >> > >> > http://dpdk.org/browse/memnic/tree/pmd/pmd_memnic.c#n449 >> > >> > There are some few other references too, if needed. >> >> It may be used, but that doesn't mean it's maintained, or robust >> against abuse. My advice i...