On 02/28/2012 04:40 PM, Jan Kiszka wrote:
> On 2012-02-28 15:32, Avi Kivity wrote:
> >
> > VMStateDescription vmstate_pit = {
> > .name = "i8254",
> > .version_id = 3,
> > .minimum_version_id = 2,
> > .minimum_version_id_old = 1,
> > .load_state_old = pit_load_old,
> > .fields = (VMStateField []) {
> > <<<<<<< HEAD
> > VMSTATE_UINT32(flags, PITState),
> > ||||||| merged common ancestors
> > =======
> > VMSTATE_UINT32_V(channels[0].irq_disabled, PITState, 3),
> >>>>>>>> ce967e2f33861b0e17753f97fa4527b5943c94b6
> > VMSTATE_STRUCT_ARRAY(channels, PITState, 3, 2,
> > vmstate_pit_channel, PITChannelState),
> > VMSTATE_TIMER(channels[0].irq_timer, PITState),
> > VMSTATE_END_OF_LIST()
> > }
> > };
> >
> > I'm guessing that flags and irq_disabled are equivalent, but do they
> > have the same sense (that is, do the "1" values have the same meaning)?
>
> Yes. qemu-kvm sets flags to 0 or PIT_FLAGS_HPET_LEGACY, which is 1. And
> the latter means "irq_disabled".
>
> > If not, we have a migration problem.
> >
> > Is it save to just adopt the new version and drop the old one?
>
> The new upstream code was designed to match qemu-kvm's migration format,
> so you can switch.
Not entirely unexpected, but I wanted to make sure.
> Of course, the result needs a careful check.
>
Thanks!
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
