Re: Reconciling qemu-kvm and qemu's PIT

[Avi Kivity <avi@redhat.com>]

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