On 2021/2/4 2:49, Dr. David Alan Gilbert wrote:
> * Chuan Zheng (zhengchuan@huawei.com) wrote:
>> Signed-off-by: Zhimin Feng <fengzhimin1@huawei.com>
>> Signed-off-by: Chuan Zheng <zhengchuan@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