[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [Qemu-devel] [QEMU RFC PATCH v3 4/6] Migration: migrate Q
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-ppc] [Qemu-devel] [QEMU RFC PATCH v3 4/6] Migration: migrate QTAILQ |
Date: |
Tue, 7 Jun 2016 18:35:51 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 |
On 07/06/2016 18:34, Dr. David Alan Gilbert wrote:
> * Paolo Bonzini (address@hidden) wrote:
>>
>>
>> On 07/06/2016 16:43, Dr. David Alan Gilbert wrote:
>>> b) I think you should really try and split it into two parts:
>>> 1) A VMSTATE_ARRAY_CUSTOM (?) - so it's an array of elements but we've
>>> got a special
>>> way of allocating/counting/reading the elements
>>> 2) A version of that which is for a QTAILQ.
>>> It's important that whatever ends up on the migration stream doesn't
>>> reflect
>>> that it happens to be implemented as a QTAILQ; so if you decide to
>>> change
>>> it later the migration compatibility doesn't break.
>>
>> (Just to clarify before Jianjun wakes up) a VMSTATE_ARRAY is just a
>> sequence of elements. The count, if needed as in a VARRAY, is stored
>> earlier and separately. Currently lists (including this QTAILQ) are
>> usually represented in the migration stream as a sequence of elements
>> preceded by "1" and terminated by a "0". Would you like to change it to
>> a count + sequence as well?
>>
>> This would prevent using the new QTAILQ support for other existing lists
>> such as virtio-blk and scsi's request lists.
>
> That depends if it's something you're trying to keep migration compatibility
> with; if you're trying to keep format compaibility then sure keep it as is.
> If you're not trying to keep compatibility, then why can't virtio-blk or
> scsi request lists also use a count rather than the markers?
We're trying to keep compatibility, and I think it's among the last bits
that are resisting conversion to vmstate. Which explains my interest in
Jianjun's patches. :)
Paolo
>>> c) Use new trace_ names for get_qtailq rather than misusing
>>> trace_vmstate_load_state*
>>> d) Add a trace_ for put_qtailq as well - that way when it goes horribly
>>> wrong we can
>>> turn the tracing on on both sides :-)
>>> e) Is there anyway to make QTAILQ_RAW_INSERT_TAIL any more readable?
>>> I don't think I understand why you can't use the standard QTAILQ
>>> macros.
>>
>> Because they assume a particular type. The "raw" version need to work on
>> void*.
>
> Ah OK.
>
> Dave
>
>>
>> Thanks,
>>
>> Paolo
>>
>>> f) You might need to fix up Amit's scripts/vmstate-static-checker.py
> --
> Dr. David Alan Gilbert / address@hidden / Manchester, UK
>
Re: [Qemu-ppc] [Qemu-devel] [QEMU RFC PATCH v3 4/6] Migration: migrate QTAILQ, Jianjun Duan, 2016/06/03
Re: [Qemu-ppc] [Qemu-devel] [QEMU RFC PATCH v3 4/6] Migration: migrate QTAILQ, Paolo Bonzini, 2016/06/06