Re: [Xen-devel] [PATCH v3 12/13] xen/arm: start the vtimer Xen timers on the processor they should be running on

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2013-04-24 at 20:07 +0100, Stefano Stabellini wrote:
> The Xen physical timer emulator and virtual timer driver use two
> internal Xen timers: initialize them on the processor the vcpu is
> going to be running on, rather than the processor that it's creating the
> vcpu.

But this CPU can change as the vcpu migrates around the pcpus, do we not
need to handle that case too?

Surely we need some code in virt_timer_restore at least? Possibly a call
to migrate_timer? Although perhaps there is a less expensive way when we
know the timer isn't running?

> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
> ---
>  xen/arch/arm/vtimer.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
> index 1cb365e..2444851 100644
> --- a/xen/arch/arm/vtimer.c
> +++ b/xen/arch/arm/vtimer.c
> @@ -48,7 +48,7 @@ int vcpu_vtimer_init(struct vcpu *v)
>  {
>      struct vtimer *t = &v->arch.phys_timer;
>  
> -    init_timer(&t->timer, phys_timer_expired, t, smp_processor_id());
> +    init_timer(&t->timer, phys_timer_expired, t, v->processor);
>      t->ctl = 0;
>      t->offset = NOW();
>      t->cval = NOW();
> @@ -56,7 +56,7 @@ int vcpu_vtimer_init(struct vcpu *v)
>      t->v = v;
>  
>      t = &v->arch.virt_timer;
> -    init_timer(&t->timer, virt_timer_expired, t, smp_processor_id());
> +    init_timer(&t->timer, virt_timer_expired, t, v->processor);
>      t->ctl = 0;
>      t->offset = READ_SYSREG64(CNTVCT_EL0) + READ_SYSREG64(CNTVOFF_EL2);
>      t->cval = 0;



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel