Re: [Qemu-devel] pl031 time across vm save/reload

[Peter Maydell]

On Fri, 5 Jul 2019 at 11:32, Paolo Bonzini <address@hidden> wrote:
>
> On 05/07/19 12:21, Peter Maydell wrote:
> > On Fri, 5 Jul 2019 at 11:13, Paolo Bonzini <address@hidden> wrote:
> >> Yes, something like that but I would just bump the version.  Version 1
> >> has the old meaning for the first field, version 2 has the new meaning.
> >
> > Yeah, we could do that. I thought we preferred to avoid using
> > version-numbers for migration though these days ? (cc'ing DG
> > in case he has an opinion.)
>
> Yeah I suppose a subsection would make it easier to keep the old broken
> behavior for old machine types.  It would be a bit more code.

On which note, which of us is going to write this code ? :-)

> >> And also, since our brains are fresh on pl031... currently s->lr is
> >> always 0; besides the bug that writing RTC_LR should update it, the
> >> datasheet says the counter counts up from 1 so perhaps at startup s->lr
> >> should be set to a nonzero value?   That would be
> >> qemu_ref_timedate(QEMU_CLOCK_VIRTUAL) - 1.
> >
> > The 'summary of RTC registers' section in the datasheet says
> > that RTCLR's reset value is zero...
>
> Right, but RTCDR doesn't return the current wallclock after power up on
> real hardware, doesn't it?  So the choices are 1) RTCLR returns 0 and it
> looks like the board was powered on in the seventies; 2) RTCLR is not 0
> and it looks like some firmware ran initialized RTCLR.

I would want to test the behaviour of real hardware here before
bothering to change QEMU's implementation. And I'm not sure
it really justifies fiddling with it... (It's not impossible
that the hardware implementation really does hold "last value
written to this register" distinct from "whatever the offset
we have between the counter and RTCDR is", such that the value
read from RTCLR immediately on reset has no relation to what
the RTC is actually done and is just the reset value of the
relevant flops (ie 0).)

thanks
-- PMM