From: Halil Pasic <pasic@linux.vnet.ibm.com>
To: Jianjun Duan <duanj@linux.vnet.ibm.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: veroniabahaa@gmail.com, peter.maydell@linaro.org,
mdroth@linux.vnet.ibm.com, mst@redhat.com, quintela@redhat.com,
mark.cave-ayland@ilande.co.uk, qemu-devel@nongnu.org,
mreitz@redhat.com, blauwirbel@gmail.com, amit.shah@redhat.com,
qemu-ppc@nongnu.org, kraxel@redhat.com, kwolf@redhat.com,
dmitry@daynix.com, pbonzini@redhat.com, rth@twiddle.net,
leon.alrae@imgtec.com, aurelien@aurel32.net,
david@gibson.dropbear.id.au
Subject: Re: [Qemu-devel] [QEMU PATCH v8 2/3] migration: migrate QTAILQ
Date: Thu, 27 Oct 2016 13:16:04 +0200 [thread overview]
Message-ID: <3f457449-b23e-dd9c-1ca7-711e6b828144@linux.vnet.ibm.com> (raw)
In-Reply-To: <46f2cb18-564c-b64f-a9ca-929df3f282c0@linux.vnet.ibm.com>
On 10/26/2016 07:33 PM, Jianjun Duan wrote:
>>>>>>> +#define QTAILQ_FIRST_OFFSET 0
>>>>>>> >>>>>> +#define QTAILQ_LAST_OFFSET (sizeof(void *))
>>>>>> >>>>>
>>>>>> >>>>> OK, you might want to add some asserts somewhere in a .c just to catch if
>>>>>> >>>>> any of these offsets change.
>>>>>> >>>>>
>>>>> >>>> if the layout of QTAILQ changes, the version id for the vmsd should also
>>>>> >>>> be changed. It will break migration between different versions. However
>>>>> >>>> the operation doesn't depend on these values.
>>>> >>>
>>>> >>> No, changing layout of QTAILQ doesn't need to change the version id of vmsd;
>>>> >>> it's an internal change. But if someone does make the change and forgets
>>>> >>> to update your OFFSET macros it'll cause memory corruption.
>>>> >>> You could catch that with an assert (possibly build time).
>>>> >>>
>>> >> If we use these constant I would agree an assertion is necessary. By
>>> >> using a macro we leave the door open for change. and if someone changes
>>> >> the layout, he or she better change the macros and the version id. If an
>>> >> assertion is added, then that assertion needs to be changed to reflect
>>> >> the change, then in the unlikely situations we could have several
>>> >> version of layout/macro/assertions floating around. That is too much. SO
>>> >> version id is the best guard here.
>> >
>> > Version id's are irrelevant here.
>> > The macros are irrelevant here.
>> > I'm talking about a potential mismatch between the definition of QTAILQ_LAST_OFFSET
>> > and the definition of Q_TAILQ_HEAD.
>> >
>> > Dave
>> >
> I suppose anyone who changes the layout should also change the macro and
> version ID of the relevant vmsd. Similar issue was discussed before as
> the early version tried to generate all these offsets based on the
> element and head type. You can see in version 2 discussion.
>
>
> Thanks,
> Jianjun
IMHO Dave is right, although a change in head/entry does not seem too
likely to me. Just want to point out that Dave's proposal (discussed here
https://lists.gnu.org/archive/html/qemu-devel/2016-10/msg03770.html)
does not have these issues and it appears more elegant to me. Jianjun
why do you prefer doing the offsets manually?
Halil
next prev parent reply other threads:[~2016-10-27 11:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-25 20:47 [Qemu-devel] [QEMU PATCH v8 0/3] migration: migrate QTAILQ Jianjun Duan
2016-10-25 20:47 ` [Qemu-devel] [QEMU PATCH v8 1/3] migration: extend VMStateInfo Jianjun Duan
2016-10-26 12:14 ` Dr. David Alan Gilbert
2016-10-25 20:47 ` [Qemu-devel] [QEMU PATCH v8 2/3] migration: migrate QTAILQ Jianjun Duan
2016-10-26 16:29 ` Dr. David Alan Gilbert
2016-10-26 16:50 ` Jianjun Duan
2016-10-26 16:53 ` Dr. David Alan Gilbert
2016-10-26 17:04 ` Jianjun Duan
2016-10-26 17:09 ` Dr. David Alan Gilbert
2016-10-26 17:33 ` Jianjun Duan
2016-10-27 11:16 ` Halil Pasic [this message]
2016-10-27 16:49 ` [Qemu-devel] [Qemu-ppc] " Jianjun Duan
2016-10-25 20:47 ` [Qemu-devel] [QEMU PATCH v8 3/3] tests/migration: Add test for QTAILQ migration Jianjun Duan
2016-10-26 16:48 ` Dr. David Alan Gilbert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3f457449-b23e-dd9c-1ca7-711e6b828144@linux.vnet.ibm.com \
--to=pasic@linux.vnet.ibm.com \
--cc=amit.shah@redhat.com \
--cc=aurelien@aurel32.net \
--cc=blauwirbel@gmail.com \
--cc=david@gibson.dropbear.id.au \
--cc=dgilbert@redhat.com \
--cc=dmitry@daynix.com \
--cc=duanj@linux.vnet.ibm.com \
--cc=kraxel@redhat.com \
--cc=kwolf@redhat.com \
--cc=leon.alrae@imgtec.com \
--cc=mark.cave-ayland@ilande.co.uk \
--cc=mdroth@linux.vnet.ibm.com \
--cc=mreitz@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=quintela@redhat.com \
--cc=rth@twiddle.net \
--cc=veroniabahaa@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).