[libvirt] [RFC] require for suggestions on support for ivshmem device

[Wang Rui]

On 2014/7/17 17:37, Martin Kletzander wrote:
> On Tue, May 20, 2014 at 11:17:32AM +0200, Martin Kletzander wrote:
>> On Wed, May 14, 2014 at 08:23:21AM +0000, Wangrui (K) wrote:
>>> Hi,
>>>
>>> Libvirt does not support ivshmem(Inter-VM Shared Memory) device recently,
>>> thus, I would like to know if there's any plan to support it in the future?
>>> If not, I would like to contribute a serial of patches to do so.
>>>
> 
> I came back to this mail right now because I need to have this
> implemented.  Is there any progress on your side with this or should I
> try hitting this?
> 

There's some experimental progress, not good enough to send patches.
Sure, you can hav a try. I would keep attention on your patches.

You mentioned shm unlink below. If I Understand Correctly, QEMU does have code to cleanup shm.
Libvirt should do the cleanup job.
> [...]
>>> There are two ways to use ivshmem with qemu
>>> (please refer to http://qemu.weilnetz.de/qemu-doc.html#pcsys_005fother_005fdevs ):
>>> 1.Guests map a POSIX shared memory region into the guest as a PCI device
>>> that enables zero-copy communication to the application level of the guests, The basic syntax is:
>>>
>>>  qemu-system-i386-device ivshmem, size = <size in format accepted by -m> [, shm = <shm name>]
>>>
>>> 2.If desired, interrupts can be sent between guest VMs accessing the same shared memory region.
>>> Interrupt support requires using a shared memory server and using a chardev socket to connect to it.
>>> An example syntax when using the shared memory server is:
>>>
>>>  qemu-system-i386-device ivshmem, size = <size in format accepted by -m> [, chardev = <id>] [, msi = on]
>>>                               [, ioeventfd = on] [, vectors = n] [, role = peer | master]
>>>  qemu-system-i386-chardev socket, path = <path>, id = <id>
>>>
>>> The respective xml configuration for the above 2 qemu command lines are shown as below:
>>>
>>> Example1: automatically attach device with KVM
>>>
>>>  <devices>
>>>    <ivshmem role='master'>
>>>      <memory name='dom-ivshmem' size='2'/>
>>>    </ivshmem>
>>>  </devices>
>>>
>>> NOTE: "size" means ivshmem size in unit MB, "name" means shm name
>>>      "role" is optional, it may be set to "master" or "peer", the default one is "master"
>>>
>>
>> What do these roles mean, I mean what's the difference between master
>> and peer and why is it only used with the chardev?  Does it mean
>> master can only send interrupts or...?  Just curious.
>>
> 
> @Cam (Cc'd) I was wondering about the role= options, so I looked into
> the code.  It looks like role=peer just effectively disables
> migration.  Did I miss any other difference?
> 
> From the libvirt's POV I'd have a few more questions if I may.  How
> does the migration work (if there's role=master) WRT other guests
> using the same shm?  I found no shm_unlink call in QEMU sources (but
> again, I'm not experienced in QEMU's internals), does that mean that
> cleanup should be done by libvirt?
> 
> Thank you for any info provided.
> 
> Martin