Open Stack

Thank you for information !

So, you mean the situation is not changed from the reference thread[1] 
in qemu-devel ML 3 years ago, and the difficulties of ivshmem you 
mentioned is described in this thread. Am I right?

[1] "[Qemu-devel] Why I advise against using ivshmem"
https://lists.linuxfoundation.org/pipermail/virtualization/2014-June/026767.html

On 2017/05/08 9:09, Daniel P. Berrange wrote:
> On Fri, Apr 28, 2017 at 09:38:38AM +0100, sfinucan at redhat.com wrote:
>> On Fri, 2017-04-28 at 13:23 +0900, TETSURO NAKAMURA wrote:
>>> Hi Nova team,
>>>
>>> I'm writing this e-mail because I'd like to have a discussion about
>>> DPDK support at OpenStack Summit in Boston.
>>>
>>> We have developed a dpdk-based patch panel named SPP[1], and we'd
>>> like to start working on Openstack (ML2 driver) to develop
>>> "networking-spp".
>>>
>>> Especially, we'd like to use DPDK-ivshmem that was used to be used
>>> to create "dpdkr" interface in ovs-dpdk[2].
>>
>> To the best of my knowledge, IVSHMEM ports are no longer supported in
>> upstream. The documentation for this feature was recently removed from
>> OVS [1] stating:
>>
>>   - The ivshmem library has been removed in DPDK since DPDK 16.11.
>>   - The instructions/scheme provided will not work with current
>>     supported and future DPDK versions.
>>   - The linked patch needed to enable support in QEMU has never
>>     been upstreamed and does not apply to the last 4 QEMU releases.
>>   - Userspace vhost has become the defacto OVS-DPDK path to the guest.
>>
>> Note: I worked on DPDK vSwitch [2] way back when, and there were severe
>> security implications with sharing a chunk of host memory between
>> multiple guests (which is how IVSHMEM works). I'm not at all surprised
>> the feature was killed.
>
> Security is only one of the issues. Upstream QEMU maintainers considered
> the ivshmem device to have a seriously flawed design and discourage anyone
> from using it. For anything network related QEMU maintainers strongly
> recommand using vhost-user.
>
> IIUC, there is some experimental work to create a virtio based replacement
> for ivshmem, for non-network related vm-2-vm communications, but that is
> not going to be something usable for a while yet. This however just
> reinforces the point that ivshmem is considered obsolete / flawed
> technology by QEMU maintainers.
>
> Regards,
> Daniel
>

-- 
Tetsuro Nakamura <nakamura.tetsuro at lab.ntt.co.jp>
NTT Network Service Systems Laboratories
TEL:0422 59 6914(National)/+81 422 59 6914(International)
3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan