[libvirt] [PATCH v1 6/6] ivshmem: add start param to server attribute

[Martin Kletzander]

On Thu, Aug 28, 2014 at 03:46:47PM +0200, David Marchand wrote:
>
>On 08/28/2014 02:26 PM, David Marchand wrote:
>>
>>> I'm not sure, though, what to do with the first point (race between
>>> libvirt creating the socket to see that it exists and ivshmem
>>> disconnecting).  Maybe libvirt could do this (if QEMU would support
>>> it):
>>>
>>> 1: try to create the socket (if it exists, continue with 4)
>>>
>>> 2: connect to the socket
>>>
>>> 3: if connecting fails, goto 1;
>>>
>>> 4: if libvirt was the one who created the socket, start the server
>>>     and pass the FD of the socket to it
>>>
>>> 5: start qemu and pass the socket to it (qemu already supports that
>>>     with other devices like netdevs, etc.
>>>
>>> This would take care of all three points.  No race, no permission
>>> issues, nothing.
>>>
>>> What do you think?
>>
>> - Mmm, I had felt that there could be a race in the socket check, yes.
>> The LISTEN_FDS support in the server is not that big of a change.
>> I think I can take care of that.
>>
>>
>> - Did not think of the other points.
>> I think there is still some problem with your proposition, I need more
>> time to think about it (may be some prototyping to be sure).
>
>I had misunderstood something about listen()/connect().
>Ok, your proposition looks good to me.
>
>At least for the server, this should be transparent as long as the
>server handles LISTEN_FDS env variable or an option to tell it which fd
>he should listen on.
>

Parameter is fine, too, I was probably just thinking about the
LISTEN_FDS stuff too much due to having some trouble implementing it
in libvirtd.

>For the ivshmem part in QEMU itself, I think adding a property to
>ivshmem pci class should do the trick, will see if I (or Maxime) can do
>this.
>

Great.  One more minor thing, though.  In libvirt, we need to have the
option to know whether QEMU supports that newly added option.  We are
introspecting such things using QMP, so if it's a device property, we
should be able to get that.

>Are there any other points concerning the server ?
>

Not that I know of (yet).  Feel free to Cc me on the patches for the
ivshmem stuff in qemu-devel.

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140828/725e63e8/attachment-0001.sig>