On 04/11/2011 12:06 PM, Ulrich Obergfell wrote:
>> vmstate_hpet_timer = { >> VMSTATE_UINT64(fsb, HPETTimer), >> VMSTATE_UINT64(period, HPETTimer), >> VMSTATE_UINT8(wrap_flag, HPETTimer), >> + VMSTATE_UINT64_V(saved_period, HPETTimer, 3), >> + VMSTATE_UINT64_V(ticks_not_accounted, HPETTimer, 3), >> + VMSTATE_UINT32_V(irqs_to_inject, HPETTimer, 3), >> + VMSTATE_UINT32_V(irq_rate, HPETTimer, 3), >> + VMSTATE_UINT32_V(divisor, HPETTimer, 3), > > We ought to be able to use a subsection keyed off of whether any ticks > are currently accumulated, no?Anthony, I'm not sure if I understand your question correctly. Are you suggesting to migrate the driftfix-related state conditionally / only if there are any ticks accumulated in 'ticks_not_accounted' and 'irqs_to_inject' ? The size of the driftfix-related state is 28 bytes per timer and we have 32 timers per HPETState, i.e. 896 additional bytes per HPETState. With a maximum number of 8 HPET blocks (HPETState), this amounts to 7168 bytes. Hence, unconditional migration of the driftfix-related state should not cause significant additional overhead.
It's not about overhead.
Maybe I missed something. Could you please explain which benefit you see in using a subsection ?
In the common case of there being no drift, you can migrate from a qemu that supports driftfix to a qemu that doesn't.
-- error compiling committee.c: too many arguments to function
