On 11/02/2016 03:45 AM, Juan Quintela wrote:
> Jianjun Duan <du...@linux.vnet.ibm.com> wrote:
>> Currently we cannot directly transfer a QTAILQ instance because of the
>> limitation in the migration code. Here we introduce an approach to
>> transfer such structures. We created VMStateInfo vmstate_info_qtailq
>> for QTAILQ. Similar VMStateInfo can be created for other data structures
>> such as list.
>>
>> This approach will be used to transfer pending_events and ccs_list in spapr
>> state.
>>
>> We also create some macros in qemu/queue.h to access a QTAILQ using pointer
>> arithmetic. This ensures that we do not depend on the implementation
>> details about QTAILQ in the migration code.
>>
>> Signed-off-by: Jianjun Duan <du...@linux.vnet.ibm.com>
>
>
>> +
>> + trace_get_qtailq(vmsd->name, version_id);
>> + if (version_id > vmsd->version_id) {
>> + error_report("%s %s", vmsd->name, "too new");
>> + trace_get_qtailq_end(vmsd->name, "too new", -EINVAL);
>> +
>> + return -EINVAL;
>> + }
>> + if (version_id < vmsd->minimum_version_id) {
>> + error_report("%s %s", vmsd->name, "too old");
>> + trace_get_qtailq_end(vmsd->name, "too old", -EINVAL);
>> + return -EINVAL;
>> + }
>> +
>> + while (qemu_get_byte(f)) {
>> + elm = g_malloc(size);
>
> I think this is not generic enough. We really need to allocate a new
> element, and then fill it with default values.
>
> virtio list code use it in this way.
>
>
To do that we need probably to expand VMStateDescription and/or
VMStateField so that a default value can be supplied. Or we can always
fill the untouched fields in post_load.
Thanks,
Jianjun
> Thanks, Juan.
>
