Re: Reconciling qemu-kvm and qemu's PIT

[Jan Kiszka <jan.kiszka@siemens.com>]

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