On 21/09/2016 09:36, zhong...@sangfor.com.cn wrote:
> If we change base_rtc while migration, thngs look work fine as 
> normal, but in fact some important information lost. QEMU lost 
> knowledge of time when the guest starts. This infomation maybe hasn't
> users nowadays.

I see your point.  However, I think it's simpler to have a single
"delta" between qemu_clock_get_ns(rtc_clock) and the guest RTC clock.

To do this, base_rtc and last_update could even be merged in a single
variable (offset is different).

> But maybe in the futhure we need, on the other hand, maybe some 
> derived release spawned from community version needs and depends on 
> this feature, who knows!

This is not a problem now.  If it's needed in the future one can
complicate the code later.  If it's needed by some downstream release,
they will deal with it.  The goal of QEMU is to have simple code.

> Should we merge offset into last_update? I suggest better not, that 
> disrupts time axis model

I agree.  But I don't see a reason to keep base_rtc and last_update
separate.  Together they are "rtc_delta".  They are separate mostly for

> After this patch, our next step is to eliminate deviation during 
> migration. That time meaning of s->offset will be extended. In the
> further future, we may implement some functions on statistics of
> guest lifetime despite it has been migrated or not. That needs a
> fixed base_rtc.

Extending the meaning of s->offset is fine, but a fixed s->base_rtc
is not good.  The guest can already modify base_rtc: it will do it every
time it calls rtc_set_time, for example if the time of day is changed in
the guest.

I suggest that you post the simplest possible patch to fix your issue,
which calls rtc_update_time pre-save and rtc_set_time post-load
(resetting s->offset after the rtc_set_time, as in the version <= 2
code).  I'm interested in the code to eliminate the pause during
migration, too.



Reply via email to