[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [QEMU RFC PATCH v2 4/6] Migration: migrate QTAILQ
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [QEMU RFC PATCH v2 4/6] Migration: migrate QTAILQ |
Date: |
Thu, 26 May 2016 09:11:43 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 |
On 25/05/2016 22:17, Jianjun Duan wrote:
>
>
> On 05/25/2016 12:22 PM, Paolo Bonzini wrote:
>>> 1 QTAILQ should only be accessed using the interfaces defined in
>>> queue.h. Its structs should not be directly used. So I created
>>> interfaces in queue.h to query about its layout. If the implementation
>>> is changed, these interfaces should be changed accordingly. Code using
>>> these interfaces should not break.
>>
>> You don't need to query the layout, as long as the knowledge
>> remains hidden in QTAILQ_RAW_* macros. And because QTAILQ_*_OFFSET
>> returns constant values, you can just put the knowledge of the offsets
>> directly in QTAILQ_RAW_FOREACH and QTAILQ_RAW_INSERT_TAIL.
>>
>>> 2 Based on point 1, vmstate_load_state/vmstate_put_state in vmstate.c
>>> doesn't exactly know the structs of QTAILAQ head and entry. So pointer
>>> arithmetic is needed to put/get a QTAILQ. To do it, we need those 6
>>> parameters to be passed in. So it is not redundant if we only want to
>>> only use the interfaces.
>>
>> No, you only need two. The other four are internal to qemu/queue.h.
>> Just like QTAILQ users do not know about tqh_* and tqe_*, they need not
>> know about their offsets, only the fields that contain them.
>
> In vmstate_load/put_state usually we use a VMSD to describe the type for
> dump/load purpose. The metadata for the QTAILQ is for the same purpose.
> Of course we can encode the information in a VMSD or VMStateField if
> we don't have to change much.
A VMSD describes the "sub-structure" of the field. Here, the
substructure of a QTAILQ is the structure of each entry.
> The user may only care the position of head and entry. But to
> implement QTAILQ_RAW_***, we need more offset information than that.
> If we don't query the offsets using something like offset() and store
> it in a metadata, we have to make the assumption that all the pointer
> types have the same size.
We make this assumption elsewhere anyway. _You_ are making it by doing
loads and stores through void** in QTAILQ_RAW_*.
Thanks,
Paolo
- [Qemu-devel] [QEMU RFC PATCH v2 6/6] Migration: migrate pending_events of spapr state, (continued)
- [Qemu-devel] [QEMU RFC PATCH v2 6/6] Migration: migrate pending_events of spapr state, Jianjun Duan, 2016/05/24
- [Qemu-devel] [QEMU RFC PATCH v2 5/6] Migration: migrate ccs_list in spapr state, Jianjun Duan, 2016/05/24
- [Qemu-devel] [QEMU RFC PATCH v2 4/6] Migration: migrate QTAILQ, Jianjun Duan, 2016/05/24
- Re: [Qemu-devel] [QEMU RFC PATCH v2 4/6] Migration: migrate QTAILQ, David Gibson, 2016/05/25
- Re: [Qemu-devel] [QEMU RFC PATCH v2 4/6] Migration: migrate QTAILQ, Paolo Bonzini, 2016/05/25
- Re: [Qemu-devel] [QEMU RFC PATCH v2 4/6] Migration: migrate QTAILQ, Jianjun Duan, 2016/05/25
- Re: [Qemu-devel] [QEMU RFC PATCH v2 4/6] Migration: migrate QTAILQ, Paolo Bonzini, 2016/05/25
- Re: [Qemu-devel] [QEMU RFC PATCH v2 4/6] Migration: migrate QTAILQ, Jianjun Duan, 2016/05/25
- Re: [Qemu-devel] [QEMU RFC PATCH v2 4/6] Migration: migrate QTAILQ, Paolo Bonzini, 2016/05/25
- Re: [Qemu-devel] [QEMU RFC PATCH v2 4/6] Migration: migrate QTAILQ, Jianjun Duan, 2016/05/25
- Re: [Qemu-devel] [QEMU RFC PATCH v2 4/6] Migration: migrate QTAILQ,
Paolo Bonzini <=
- Re: [Qemu-devel] [QEMU RFC PATCH v2 4/6] Migration: migrate QTAILQ, Jianjun Duan, 2016/05/26
- Re: [Qemu-devel] [QEMU RFC PATCH v2 4/6] Migration: migrate QTAILQ, Paolo Bonzini, 2016/05/26