From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56187) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YspZl-0000MG-68 for qemu-devel@nongnu.org; Thu, 14 May 2015 05:37:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YspZj-00076S-Fs for qemu-devel@nongnu.org; Thu, 14 May 2015 05:37:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40522) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YspZj-00075M-9C for qemu-devel@nongnu.org; Thu, 14 May 2015 05:37:07 -0400 Date: Thu, 14 May 2015 11:36:57 +0200 From: "Michael S. Tsirkin" Message-ID: <20150514112845-mutt-send-email-mst@redhat.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55546945.4050400@de.ibm.com> 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: Christian Borntraeger Cc: Cornelia Huck , qemu-devel@nongnu.org, jjherne@linux.vnet.ibm.com On Thu, May 14, 2015 at 11:22:13AM +0200, Christian Borntraeger wrote: > Am 13.05.2015 um 23:47 schrieb Michael S. Tsirkin: > > On Wed, May 13, 2015 at 08:57:00PM +0200, Christian Borntraeger wrote: > >> Am 13.05.2015 um 18:14 schrieb Michael S. Tsirkin: > >>>> - AFAICS, there's no easy way to add transport-specific subsections - > >>>> and simply adding config_vector in ccw would break compatibility > >>> > >>> subsections break compatibility too. The only way around that is to set > >>> a flag to skip migrating config_vector for old machine types. > >> > >> My main concern is about undetected compatibility issues. A subsection will > >> tell the user that something went wrong. What happens if we just add a new > >> qemu_put_byte in the stream. Will the savevm core always detect that we have > >> too many or not enough bytes? If yes, adding new stuff in the stream will > >> always be detected in some way as error we can go with just adding > >> qemu_put_be16/qemu_get_be16 in virtio_ccw_save_config/virtio_ccw_load_config. > >> Old/new QEMUs will then not be compatible - but thats probably ok as long as it > >> errors out. > >> > >> My understanding was that we do not have a guarentee that this will be > >> detected all the time and having random junk in some variables is a debugging > >> nightmare. Is that correct? > >> > >> > >> Christian > > > > It's not too bad - normally there's a bunch of strings that > > helps you find out what's going on. > > But if you really care about debuggability of migration streams, help move > > forward dgilbert's RFC that switched to a self-delimiting format. > > Just piling up random hacks in virtio seems like a wrong approach. > > > > Thats not my question. PLEASE try to understand my question. > I want a hard stop if migration changes in incompatible ways. > If adding a qemu_put_byte in virtio_ccw gets detected we can just fix > virtio_ccw AS YOU SUGGESTED. I just want to know if I can rely on that > or not. > > Christian I answered exactly this question but let me try to spell the answer out a bit more. 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. 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. -- MST