On Tue, 16 Jun 2026, Peter Xu wrote: > this patch made it the other way round: the channel didn't respect > blocking mode because it always blocks, not always non-block.
You're right, the commit message was misleading. The function already blocks inside qemu_rdma_exchange_recv() when waiting for the next RDMA SEND message. What it didn't do was keep blocking when the bytes from a *single* receive were not enough to satisfy the full request -- it would return partial data instead of waiting for more. In blocking mode a QIOChannel readv should keep trying until the request is satisfied (or an error occurs), matching the behaviour of other QIOChannel implementations. That's what the loop is for. > Also, this is only the read path; there's also write. The write path already loops over the full iov in qio_channel_rdma_writev(), so it handles the blocking case correctly. Only read needed fixing. I'll send a v2 with a corrected commit message. Thanks for the review. Bin Guo
