From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38129) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YspyR-0001rN-FS for qemu-devel@nongnu.org; Thu, 14 May 2015 06:02:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YspyL-0000vU-RI for qemu-devel@nongnu.org; Thu, 14 May 2015 06:02:39 -0400 Received: from mail-wg0-x22d.google.com ([2a00:1450:400c:c00::22d]:35107) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YspyL-0000uT-Kz for qemu-devel@nongnu.org; Thu, 14 May 2015 06:02:33 -0400 Received: by wgnd10 with SMTP id d10so67374291wgn.2 for ; Thu, 14 May 2015 03:02:32 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <555472B6.3060502@redhat.com> Date: Thu, 14 May 2015 12:02:30 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1431528122-50960-1-git-send-email-cornelia.huck@de.ibm.com> <1431528122-50960-2-git-send-email-cornelia.huck@de.ibm.com> <20150513165438-mutt-send-email-mst@redhat.com> <20150513170335.2d662124.cornelia.huck@de.ibm.com> <20150513180005-mutt-send-email-mst@redhat.com> <55539E7C.90004@de.ibm.com> <20150513234516-mutt-send-email-mst@redhat.com> <55546945.4050400@de.ibm.com> <20150514112845-mutt-send-email-mst@redhat.com> In-Reply-To: <20150514112845-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH RFC 1/1] virtio: migrate config_vector List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" , Christian Borntraeger Cc: Cornelia Huck , qemu-devel@nongnu.org, jjherne@linux.vnet.ibm.com On 14/05/2015 11:36, Michael S. Tsirkin wrote: > > There are three answers: > 1. Yes, it's sure to get detected because everything gets shifted > and then you get an unexpected string instead of next device name. > 2. If you want a more generic way to detect this, then please work > on changing format for devices generally so each device > section has a byte length attached to it. Then we know that > when we make changes, they are detected as device will end > earlier/later than expected. No need for that. Subsections were introduced exactly to allow a change to be compatible in the common case and incompatible in the uncommon case. Check out "git log -- grep subsection -- savevm.c". > 3. You can have a different workaround: add property "skip config vec > on migration" and set it for old spapr machine types. > old types continue losing config vec; new ones work better. Why in the world would you want that? Paolo