On 2021/2/4 2:49, Dr. David Alan Gilbert wrote: > * Chuan Zheng (zhengch...@huawei.com) wrote: >> Signed-off-by: Zhimin Feng <fengzhim...@huawei.com> >> Signed-off-by: Chuan Zheng <zhengch...@huawei.com> >> --- >> migration/qemu-file.c | 5 +++++ >> migration/qemu-file.h | 1 + >> 2 files changed, 6 insertions(+) >> >> diff --git a/migration/qemu-file.c b/migration/qemu-file.c >> index be21518..37f6201 100644 >> --- a/migration/qemu-file.c >> +++ b/migration/qemu-file.c >> @@ -260,6 +260,11 @@ void ram_control_before_iterate(QEMUFile *f, uint64_t >> flags) >> } >> } >> >> +void *getQIOChannel(QEMUFile *f) >> +{ >> + return f->opaque; >> +} >> + > > Unfortunately that's not right, since the opaque isn't always a > QUIChannel, so getOpaque would be a suitable name here. > > It's a shame this is needed; I'm surprised you ever have a QEMUFIle* in > the rdma code in somewhere you don't have the QIOChannel; could you > avoid this by adding a QIOChannel pointer into the RDAMContext to point > back to the channel which it's for? > > Dave > OK, i'll try it. >> void ram_control_after_iterate(QEMUFile *f, uint64_t flags) >> { >> int ret = 0; >> diff --git a/migration/qemu-file.h b/migration/qemu-file.h >> index a9b6d6c..4cef043 100644 >> --- a/migration/qemu-file.h >> +++ b/migration/qemu-file.h >> @@ -165,6 +165,7 @@ void qemu_file_set_blocking(QEMUFile *f, bool block); >> void ram_control_before_iterate(QEMUFile *f, uint64_t flags); >> void ram_control_after_iterate(QEMUFile *f, uint64_t flags); >> void ram_control_load_hook(QEMUFile *f, uint64_t flags, void *data); >> +void *getQIOChannel(QEMUFile *f); >> >> /* Whenever this is found in the data stream, the flags >> * will be passed to ram_control_load_hook in the incoming-migration >> -- >> 1.8.3.1 >> -- Regards. Chuan