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 ?