Re: [PATCH v4] migration/rdma: add x-rdma-chunk-size parameter

On Fri, Jul 31, 2026 at 07:15:56PM +0800, Zhang, GuoQing (Sam) wrote:
> 
> 
> Hi Peter,

Sam,

> 
> Sorry for late reply. I just got the time and machine to look into this.
> 
> For current upstream code, qemu_rdma_write() len is always
> TARGET_PAGE_SIZE (4KB), which is far less than the 1MB chunk size.
> The mergeable check bounds current_length within a single chunk, so
> current_length can never reach rdma_merge_max(). You're right that
> it's dead code in this case.
> 
> I did experiment with len being 2MB and chunk size being 1MB, where
> the condition does trigger: mergeable fails, current_length resets
> to 0, then += 2MB, hitting rdma_merge_max() (2 * 1MB = 2MB). But
> even in that case, removing this flush caused no issue, since the
> buffer gets flushed on the next qemu_rdma_write() call when
> mergeable fails anyway or on rdma_registration_stop() at the end.

Thanks for double checking this.

While going through RDMA code I do see a bunch of leftover things maybe
used for older versions of QEMU but seems redundant for new QEMU.

Some other example, like qemu_rdma_write_one() has support for
block->is_ram_block==false, but I don't know what's that for, might be
relevant to qemu_rdma_save_page() with this comment:

 * Parameters:
 *    @offset == 0 :
 *        This means that 'block_offset' is a full virtual address that does not
 *        belong to a RAMBlock of the virtual machine and instead
 *        represents a private malloc'd memory area that the caller wishes to
 *        transfer.
 *
 *    @offset != 0 :
 *        Offset is an offset to be added to block_offset and used
 *        to also lookup the corresponding RAMBlock.

So I had a feeling that old rdma code was designed to be able to even
migrate some malloc() chunks, when offset==0, even if I don't know anything
using it.. Meanwhile, it seems also be wrong saying that it's malloc()ed
chunk if offset==0: IIUC pc.ram (or whatever 1st ramblock we allocate) has
ramblock->offset==0 too normally... I'm not sure if it'll be recognized as
a malloc()ed region then in RDMA migration code.

Maybe I can check them up and touch some of those up while looking at some
tickets, I'll see.  I think I have some better understanding of the whole
soft RoCE now, so maybe I can try. If you're actively using RDMA (which I
had that impression..) and if you want to look into this, that'll be nice
too.

Thanks,

-- 
Peter Xu