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

David Marchand david.marchand at 6wind.com
Thu Aug 28 13:46:47 UTC 2014


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.

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.

Are there any other points concerning the server ?


-- 
David Marchand




More information about the libvir-list mailing list