[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