From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:34820)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <quintela@redhat.com>) id 1StAxe-0000iz-IR
	for qemu-devel@nongnu.org; Mon, 23 Jul 2012 01:13:39 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <quintela@redhat.com>) id 1StAxd-0007rn-En
	for qemu-devel@nongnu.org; Mon, 23 Jul 2012 01:13:38 -0400
Received: from mx1.redhat.com ([209.132.183.28]:23050)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <quintela@redhat.com>) id 1StAxd-0007rO-6L
	for qemu-devel@nongnu.org; Mon, 23 Jul 2012 01:13:37 -0400
From: Juan Quintela <quintela@redhat.com>
In-Reply-To: <1342781633-7288-8-git-send-email-pbonzini@redhat.com> (Paolo
	Bonzini's message of "Fri, 20 Jul 2012 12:53:53 +0200")
References: <1342781633-7288-1-git-send-email-pbonzini@redhat.com>
	<1342781633-7288-8-git-send-email-pbonzini@redhat.com>
Date: Mon, 23 Jul 2012 07:12:52 +0200
Message-ID: <87eho3kqln.fsf@elfo.mitica>
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [Qemu-devel] [PATCH 7/7] RTC: Allow to migrate from old QEMU
Reply-To: quintela@redhat.com
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>, qemu-devel@nongnu.org

Paolo Bonzini <pbonzini@redhat.com> wrote:
> From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
>
> The new logic is compatible with old, and it should not block migration
> from old QEMU.  However, the new version cannot migrate to the old one.
>
> Cc: Juan Quintela <quintela@redhat.com>

I guess that you removed the tm structs.

This are the current fields.

    .fields      = (VMStateField []) {
        VMSTATE_BUFFER(cmos_data, RTCState),
        VMSTATE_UINT8(cmos_index, RTCState),
        VMSTATE_INT32(current_tm.tm_sec, RTCState),
        VMSTATE_INT32(current_tm.tm_min, RTCState),
        VMSTATE_INT32(current_tm.tm_hour, RTCState),
        VMSTATE_INT32(current_tm.tm_wday, RTCState),
        VMSTATE_INT32(current_tm.tm_mday, RTCState),
        VMSTATE_INT32(current_tm.tm_mon, RTCState),
        VMSTATE_INT32(current_tm.tm_year, RTCState),

you can change this to:

        VMSTATE_UNUSED(7*4);

Some for the others.

        VMSTATE_TIMER(periodic_timer, RTCState),
        VMSTATE_INT64(next_periodic_time, RTCState),
        VMSTATE_INT64(next_second_time, RTCState),
        VMSTATE_TIMER(second_timer, RTCState),
        VMSTATE_TIMER(second_timer2, RTCState),
        VMSTATE_UINT32_V(irq_coalesced, RTCState, 2),
        VMSTATE_UINT32_V(period, RTCState, 2),
        VMSTATE_END_OF_LIST()
    }


>  static const VMStateDescription vmstate_rtc = {
>      .name = "mc146818rtc",
> -    .version_id = 2,
> -    .minimum_version_id = 1,
> +    .version_id = 3,
> +    .minimum_version_id = 3,
>      .minimum_version_id_old = 1,
> +    .load_state_old = rtc_load_old,
>      .post_load = rtc_post_load,
>      .fields      = (VMStateField []) {
>          VMSTATE_BUFFER(cmos_data, RTCState),
> @@ -837,7 +873,7 @@ static int rtc_initfn(ISADevice *dev)

no changes in the other part of vmstate?  that is at least strange?  I
guess they are on the other patches on the series.  Will take a look.


>      memory_region_init_io(&s->io, &cmos_ops, s, "rtc", 2);
>      isa_register_ioport(dev, &s->io, base);
>  
> -    qdev_set_legacy_instance_id(&dev->qdev, base, 2);
> +    qdev_set_legacy_instance_id(&dev->qdev, base, 3);
>      qemu_register_reset(rtc_reset, s);
>  
>      object_property_add(OBJECT(s), "date", "struct tm",