From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50851) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fnIsg-0003pA-QH for qemu-devel@nongnu.org; Wed, 08 Aug 2018 03:27:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fnIsb-0003uu-W8 for qemu-devel@nongnu.org; Wed, 08 Aug 2018 03:27:42 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:33588 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fnIsb-0003uX-Qn for qemu-devel@nongnu.org; Wed, 08 Aug 2018 03:27:37 -0400 From: Juan Quintela In-Reply-To: (Peter Maydell's message of "Tue, 7 Aug 2018 16:09:53 +0100") References: <20180807130355.29780-1-peter.maydell@linaro.org> <87muty2u57.fsf@trasno.org> <87in4m2qni.fsf@trasno.org> <87wot21bbt.fsf@trasno.org> <87o9ee1aka.fsf@trasno.org> Reply-To: quintela@redhat.com Date: Wed, 08 Aug 2018 09:27:31 +0200 Message-ID: <87k1p11foc.fsf@trasno.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH] migration: Correctly handle subsections with no 'needed' function List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU Developers , "patches@linaro.org" , "Dr. David Alan Gilbert" Peter Maydell wrote: D> On 7 August 2018 at 16:05, Juan Quintela wrote: >> Peter Maydell wrote: >>> So it's better to use a needed-always subsection, which will give >>> the desired behaviour: >>> * new QEMU -> new QEMU: state is always migrated >>> * old QEMU -> new QEMU: migration doesn't fail, and guest >>> will work assuming it didn't care about this corner of the >>> device's functionality (the device will end up with state >>> as it was at reset, or possibly special-cased via >>> pre_load/post_load hooks for the "section not present" case) >> >> we break by definiton new QEMU -M into old QEMU. > > Is that supposed to work? I always thought that we never > supported migration back to an older QEMU version like that. It is a "best effort" case. As David told, downstream we try very hard. For upstream we do when I found that, but not anywhere else. > In any case, for all the devices here the machine types are > not versioned. This is part of the problem. For some architectures, we don't even care about migraiton. For others, we care about migration but not cross-version. And yet in others we care very much (downstream specially). And it is not clear what devices support each of them. Later, Juan.