On Tue, Sep 19, 2017 at 08:50:49PM +0100, Mark Cave-Ayland wrote: > On 18/09/17 23:44, David Gibson wrote: > > > So, adding new things to the migration stream always requires some > > thought. The commit message should contain a rationale for why the > > proposed representation is a good one. In particular is it one that's > > unlikely to be difficult if the device changes internal details in > > future. When possible it's best to stick to architected documented > > state of the modelled hardware, though I can see you're probably going > > to need some extras in this case. > > Yes, I think that's the case here. Definitely the timer can't be armed > correctly without origin_time, and if qemu_timer_active isn't present > and migration occurs with an active timer then a subsequent call to > openpic_tmr_get_timer() will be incorrect. Does that sound right to > you?
You'll certainly need some sort of time variable, which could be
expressed in various ways equivalently. I don't know if you'll need
an explicit extra "active" boolean - are there any openpic registers
which would indicate if a timer is active? It's generally best to
represent state using documented forms from the hardware whenever
possible.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
