From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40586) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QgtJi-0001Ab-6u for qemu-devel@nongnu.org; Wed, 13 Jul 2011 02:53:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QgtJh-0001cL-CP for qemu-devel@nongnu.org; Wed, 13 Jul 2011 02:53:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:17988) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QgtJh-0001c9-2t for qemu-devel@nongnu.org; Wed, 13 Jul 2011 02:53:05 -0400 Message-ID: <4E1D40CA.2060206@redhat.com> Date: Wed, 13 Jul 2011 09:52:58 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1310321709-30770-1-git-send-email-avi@redhat.com> <1310321709-30770-31-git-send-email-avi@redhat.com> <1310510489.2845.26.camel@bling.home> In-Reply-To: <1310510489.2845.26.camel@bling.home> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v3 30/56] rtl8139: convert to memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson , Anthony Liguori Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org On 07/13/2011 01:41 AM, Alex Williamson wrote: > > static int rtl8139_post_load(void *opaque, int version_id) > > { > > @@ -3283,7 +3242,7 @@ static void rtl8139_pre_save(void *opaque) > > rtl8139_set_next_tctr_time(s, current_time); > > s->TCTR = muldiv64(current_time - s->TCTR_base, PCI_FREQUENCY, > > get_ticks_per_sec()); > > - s->rtl8139_mmio_io_addr_dummy = s->rtl8139_mmio_io_addr; > > + s->rtl8139_mmio_io_addr_dummy = 0; > > This makes the dummy value fairly useless for preserving new->old > migration. > Drop it altogether and bump the version or add a subsection > to prevent migration to old versions that consume this? That means we can't migrate to 0.14, even though 0.14 is safe. How about we fix 0.13.blah? And make the rule that we only support backwards migration to fully patched releases. There's no problem requiring an updated target; only an updated source is an issue. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.