From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33048) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bAJy8-00023B-5U for qemu-devel@nongnu.org; Tue, 07 Jun 2016 12:35:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bAJy5-0007jg-0k for qemu-devel@nongnu.org; Tue, 07 Jun 2016 12:35:08 -0400 Date: Tue, 7 Jun 2016 17:34:57 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20160607163457.GA22900@work-vm> References: <1464717764-9040-1-git-send-email-duanj@linux.vnet.ibm.com> <1464717764-9040-5-git-send-email-duanj@linux.vnet.ibm.com> <877fe7iqj3.fsf@oc4731375738.ibm.com> <57505AA6.6080201@linux.vnet.ibm.com> <20160607144313.GC2257@work-vm> <25630722-124a-f11f-9298-9653b3553558@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25630722-124a-f11f-9298-9653b3553558@redhat.com> Subject: Re: [Qemu-devel] [QEMU RFC PATCH v3 4/6] Migration: migrate QTAILQ List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Jianjun Duan , Sascha Silbe , qemu-devel@nongnu.org, veroniabahaa@gmail.com, peter.maydell@linaro.org, quintela@redhat.com, mst@redhat.com, mark.cave-ayland@ilande.co.uk, mdroth@linux.vnet.ibm.com, mreitz@redhat.com, blauwirbel@gmail.com, dmitry@daynix.com, qemu-ppc@nongnu.org, kraxel@redhat.com, amit.shah@redhat.com, kwolf@redhat.com, david@gibson.dropbear.id.au, leon.alrae@imgtec.com, aurelien@aurel32.net, rth@twiddle.net * Paolo Bonzini (pbonzini@redhat.com) 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? > > 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 / dgilbert@redhat.com / Manchester, UK