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
