[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] pl031 time across vm save/reload
From: |
Peter Maydell |
Subject: |
Re: [Qemu-devel] pl031 time across vm save/reload |
Date: |
Fri, 5 Jul 2019 10:58:44 +0100 |
On Fri, 5 Jul 2019 at 10:48, Paolo Bonzini <address@hidden> 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
Re: [Qemu-devel] pl031 time across vm save/reload, Peter Maydell, 2019/07/05
Re: [Qemu-devel] pl031 time across vm save/reload, Peter Maydell, 2019/07/08