On 03.01.2013, at 21:37, Scott Wood wrote: > On 01/03/2013 02:33:39 PM, Alexander Graf wrote: >> Am 03.01.2013 um 21:20 schrieb Scott Wood <scottw...@freescale.com>: >> > On 12/27/2012 11:16:51 PM, Bharat Bhushan wrote: >> >> This patch install the timer reset handler. This will be called when >> >> the guest is reset. >> >> Signed-off-by: Bharat Bhushan <bharat.bhus...@freescale.com> >> >> --- >> >> v2: same as v1 >> >> hw/ppc_booke.c | 12 ++++++++++++ >> >> 1 files changed, 12 insertions(+), 0 deletions(-) >> >> diff --git a/hw/ppc_booke.c b/hw/ppc_booke.c >> >> index d51e7fa..837a5b6 100644 >> >> --- a/hw/ppc_booke.c >> >> +++ b/hw/ppc_booke.c >> >> @@ -231,6 +231,16 @@ void store_booke_tcr(CPUPPCState *env, target_ulong >> >> val) >> >> } >> >> +static void ppc_booke_timer_reset_handle(void *opaque) >> >> +{ >> >> + CPUPPCState *env = opaque; >> >> + >> >> + env->spr[SPR_BOOKE_TSR] = 0; >> >> + env->spr[SPR_BOOKE_TCR] = 0; >> >> + >> >> + booke_update_irq(env); >> >> +} >> > >> > When does KVM_SET_SREGS get called? >> That's up to the next patch. > > The watchdog one? I don't see any direct connection to this function. Does > a reset always involve a CPU state change? If that's what we're relying on, > it least deserves a code comment in this function. Otherwise it looks like > no special handling is required when setting SREG SPRs in KVM-compatible code > (i.e. not code that is only used in TCG mode).
That's why we want an indication to the lower levels that TSR changed. Basically the code would look like: cpu_synchronize_register_set(BOOKE_TIMERS); /* fetches current TSR, indicates internally that TSR is potentially dirty */ env->spr[TSR] = 0; at which point the kvm entry code would know that it needs to write back TSR. Today, the infrastructure for that is missing, but Bharat is working on it. Alex