On Fri, 5 Jul 2019 at 10:48, Paolo Bonzini <pbonz...@redhat.com> wrote: > You're right, the compatibility causes wrong behavior for the default > -rtc settings (the RC pauses across migration). The right thing to do > would be to store the base rather than the offset: that is, you store > the time at which LR was written. Then the offset is s->lr - s->base > and it's independent of the machine on which the rtc_clock is being read.
Right. How do we handle this for back-compat purposes? I guess we need to have a new migration subsection, so if it's present it has the 'base' value and we ignore the 'offset' in the main migration data, and if it's not present we assume an old->new migration and use the existing offset code. New->old migration would not be possible as the new subsection is always-present. > By the way, the data sheet says "the counter and match values are > compared in a comparator. When both values are equal, the RTCINTR > interrupt is asserted HIGH"; QEMU compares the RTC value (read from > RTC_DR) and not the counter value, but Linux code seems to expect QEMU's > behavior. The datasheet appears to be confused on this point -- for instance in section 2.1 figure 2.3 talks about "interrupt generation when the current RTC value (RTCDR) equals the Match Register value"... thanks -- PMM
