Peter Xu <pet...@redhat.com> writes: > On Thu, May 23, 2024 at 04:05:43PM -0300, Fabiano Rosas wrote: >> We're about to enable the use of O_DIRECT in the migration code and >> due to the alignment restrictions imposed by filesystems we need to >> make sure the flag is only used when doing aligned IO. >> >> The migration will do parallel IO to different regions of a file, so >> we need to use more than one file descriptor. Those cannot be obtained >> by duplicating (dup()) since duplicated file descriptors share the >> file status flags, including O_DIRECT. If one migration channel does >> unaligned IO while another sets O_DIRECT to do aligned IO, the >> filesystem would fail the unaligned operation. >> >> The add-fd QMP command along with the fdset code are specifically >> designed to allow the user to pass a set of file descriptors with >> different access flags into QEMU to be later fetched by code that >> needs to alternate between those flags when doing IO. >> >> Extend the fdset matching to behave the same with the O_DIRECT flag. >> >> Signed-off-by: Fabiano Rosas <faro...@suse.de> > > Reviewed-by: Peter Xu <pet...@redhat.com> > > One thing I am confused but totally irrelevant to this specific change. > > I wonder why do we need dupfds at all, and why client needs to remove-fd at > all.
This answer was lost to time. > > It's about what would go wrong if qmp client only add-fd, then if it's > consumed by anything, it gets moved from "fds" list to "dupfds" list. The > thing is I don't expect the client should pass over any fd that will not be > consumed. Then if it's always consumed, why bother dup() at all, and why > bother an explicit remove-fd. With the lack of documentation, I can only imagine the code was initially written to be more flexible, but we ended up never needing the extra flexibility. Maybe we could change that transparently in the future and deprecate qmp_remove_fd(). I'm thinking, even for the mapped-ram work, we might not need libvirt to call that function ever.
