qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Vincent JARDIN
Subject: Re: [Qemu-devel] Why I advise against using ivshmem
Date: Thu, 12 Jun 2014 18:02:17 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7

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
See David's contributions:
  http://patchwork.ozlabs.org/patch/358750/

2. There is no libvirt support

One can use qemu without libvivrt.

3. Out-of-tree server program required for full functionality

We have the source code, it provides the documentation to write our own better server program.

4. Out-of-tree kernel uio driver required

No, it is optional.

These concerns are all fixable, but it'll take serious work, and time.
Something like:

* Find a maintainer for the device model
I guess, we can find it into the DPDK.org community.

* Review and fix its code

* Get the required kernel module upstream

which module? uio, it is not required.

* Get all the required parts outside QEMU packaged in major distros, or
   absorbed into QEMU

Redhat did disable it. why? it is there in QEMU.

In short, create a viable community around ivshmem, either within the
QEMU community, or separately but cooperating.

At least, DPDK.org community is a community using it.

On to the more philosophical ones.

5. Out-of-tree interface required

    Paraphrasing an old quip: Some people, when confronted with a
    problem, think "I know, I'll use shared memory."  Now they have two
    problems.

    Shared memory is not an interface.  It's at best something you can
    use to build an interface.

    I'd rather have us offer something with a little bit more structure.
    Very fast guest-to-guest networking perhaps.

It is not just networking, you have other use cases like HPC, sharing in-memory databases.


6. Device models belong into QEMU

    Say you build an actual interface on top of ivshmem.  Then ivshmem in
    QEMU together with the supporting host code outside QEMU (see 3.) and
    the lower layer of the code using it in guests (kernel + user space)
    provide something that to me very much looks like a device model.

    Device models belong into QEMU.  It's what QEMU does.
See my previous statement, it is not just device model.


Best regards,
  Vincent




reply via email to

[Prev in Thread] Current Thread [Next in Thread]