On Thu, Aug 21, 2025 at 09:45:36AM -0400, Peter Xu wrote: > On Thu, Aug 21, 2025 at 03:07:57PM +0300, Vladimir Sementsov-Ogievskiy wrote: > > What I dislike in the way, when we reset to blocking always, and set > > non-blocking again where needed: > > > > 1. Extra fcntl calls for nothing (I think actually, in most cases, for > > fds passed through migration stream(s) we'll want to keep fd as is) > > > > 2. When we reset to blocking on target, it's visible on source and may > > break things. > > > > In these series it's probably doesn't really matter, as at the time when > > we get the descriptor on target, it should not be used anymore on source. > > > > But for example, in CPR-transfer, where descriptors are passed in the > > preliminary stage, and source is running and use the descriptors, we > > shouldn't change the non-blocking status of fd on target. Probably, > > CPR-transfer for now only works with fds which are blpcking, so we don't > > have a problem. > > > > So, I think, that better default is preserve state of the flag for fds > > passed through migration stream. And backends may modify it if needed (I > > think, in most cases - they will not need). > > I agree having that as a default iochannel behavior is questionable. > > If it was defined for any fd-passing protocols making sure nonblocking > status is predictable (in this case, fds will be always blocking), IMHO it > should be done in the protocol layer either constantly setting or clearing > NONBLOCK flag before sending the fds, rather than having it silently > processed in iochannel internals.
We explicitly did not want to rely on the senders to do this, as the senders generally does not know what receiving QEMU wants to do with the FDs. Clearing the non-blocking flag was chosen to make the default state of passed-in FDs, be identical to the default state of FDs that QEMU opens itself. This removes the possibility of bugs we've seen in the past, where code assumed an FD's blocking flag was in its default state you get from 'socket()' and then broke when receiving a pre-opened FD over QEMU in a different state. Basically anything using SocketAddress should be getting an FD in the same state whether opened by QEMU or passed in. > Do we know how many existing users are relying such behavior? I wonder if > we could still push this operation to the protocols that will need it, then > we can avoid this slightly awkward iochannel feature flag, because the > iochannel user will simply always have full control. Primarily this is relevant to the monitor QMP/HMP, which in turns makes it is relevant to UNIX chardevs. There are a number of other areas in QEMU calling qio_channel_readv_full() with a non-NULL fds argument though. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
