search for: ivshmem_device_spec

...ly part of some tree-wide infrastructure or cleanup work is from September 2012 (commit c08ba66). 2. There is no libvirt support 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. If this...

...ly part of some tree-wide infrastructure or cleanup work is from September 2012 (commit c08ba66). 2. There is no libvirt support 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. If this...

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

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

Vincent JARDIN <vincent.jardin at 6wind.com> writes: > On 10/06/2014 18:48, Henning Schild wrote:> Hi, >> In a first prototype i implemented 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,

Vincent JARDIN <vincent.jardin at 6wind.com> writes: > On 10/06/2014 18:48, Henning Schild wrote:> Hi, >> In a first prototype i implemented 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,

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

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

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

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

...gt; > 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...

...self 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 at vger.kernel.org and I'll merge them via the KVM tree for now. I'll (more than) gladly give maintainership away in due...

...ving 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 check...

...ly 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 i...

...ly 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 i...

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

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