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. Of course, the result needs a careful check.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
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
