[dpdk-dev] [PATCH v4 00/17] Wind River Systems AVP PMD vs virtio? - ivshmem is back

[Markus Armbruster]

Stefan Hajnoczi <stefanha at redhat.com> writes:

> On Fri, Mar 17, 2017 at 09:48:38AM +0100, Thomas Monjalon wrote:
>> We are discussing about IVSHMEM but its support by Qemu is confused.
>> This feature is not in the MAINTAINERS file of Qemu.
>> Please Qemu maintainers, what is the future of IVSHMEM?

Red-headed stepchild?

> git-log(1) shows that Marc-André Lureau worked on ivshmem in 2016 but
> it's not under very active development at the moment.  I have CCed him.

Marc-André and I did substantial work to fix ivhmem's worst technical
issues, including memory-corrupting race conditions (unlikely ones, but
those are arguably the worst).  More issues remain.  Have a look at
docs/specs/ivshmem-spec.txt in the QEMU source tree[1].  It's depressing
reading, I'm afraid.

In my opinion, merging ivshmem in 2010 was a mistake.  Some users have
since found it useful (good for them), so we fixed it up for their
benefit.  Nevertheless, I still can't recommend it.

> The vhost-user interface seems to be getting more attention.  It's a way
> to run virtio devices in separate host processes (e.g. userspace network
> switch).
>
> There was a brief discussion about "ivshmem 2.0" recently but I think
> that fizzled out because the use case was narrow: a new and cut-down
> device model for real-time use cases.

Yes.  If you're interested in ivshmem, go read it[2].  At least two good
ideas came up: provide for an ID of the next higher protocol level, and
generic state signalling.

Why do I like these ideas?  My main objection to ivshmem's isn't
technical flaws, but that it's a bad building block (see [3] item 5).
These ideas could make it a less bad building block.

Turning ideas into reality is work.  Jan Kiszka (who started the
discussion) chose not to pursue it, because his requirements don't align
with upstream QEMU's very well, so he'd have to do more extra work than
he can justify.

Bottom line: if you want a better future for ivshmem than the status
quo, you need to put in the work and solve some hard problems.


[1] Link to my public repository, for convenience:
http://repo.or.cz/qemu/armbru.git/blob_plain/HEAD:/docs/specs/ivshmem-spec.txt
[2] https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg02860.html
[3] https://lists.gnu.org/archive/html/qemu-devel/2014-06/msg02968.html