Re: [libvirt] [PATCH v1 6/6] ivshmem: add start param to server attribute
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