[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [QEMU RFC PATCH v3 4/6] Migration: migrate QTAILQ

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [QEMU RFC PATCH v3 4/6] Migration: migrate QTAILQ
Date: Tue, 7 Jun 2016 18:31:41 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0

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.

>   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



>   f) You might need to fix up Amit's scripts/vmstate-static-checker.py

reply via email to

[Prev in Thread] Current Thread [Next in Thread]