[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 1/2] xen/arm: support the ARM generic virtual timer



At 16:17 +0000 on 09 Jan (1357748277), Stefano Stabellini wrote:
> +static void vtimer_interrupt(int irq, void *dev_id, struct cpu_user_regs 
> *regs)
> +{
> +    current->arch.virt_timer.ctl = READ_CP32(CNTV_CTL);
> +    WRITE_CP32(current->arch.virt_timer.ctl | CNTx_CTL_MASK, CNTV_CTL);

This is masking the vtimer interrupt in a way that's visible to the
currently running guest.  Is that going to confuse the guest?

When we talked about this before I had imagined that the masking would
happen in the GIC, where the guest doesn't see it. 

> +    vgic_vcpu_inject_irq(current, irq, 1);
> +}
> +
>  /* Set up the timer interrupt on this CPU */
>  void __cpuinit init_timer_interrupt(void)
>  {
> @@ -172,6 +183,7 @@ void __cpuinit init_timer_interrupt(void)
>  
>      /* XXX Need to find this IRQ number from devicetree? */
>      request_irq(26, timer_interrupt, 0, "hyptimer", NULL);
> +    request_irq(27, vtimer_interrupt, 0, "virtimer", NULL);
>      request_irq(30, timer_interrupt, 0, "phytimer", NULL);
>  }
>  
> +static void virt_timer_expired(void *data)
> +{
> +    struct vtimer *t = data;
> +    vcpu_wake(t->v);

Shouldn't this also inject the irq?  Otherwise when an unscheduled
guest's timer goes off, we take two interrupts - one for the hyp timer
to call this function and then another immediately after
virt_timer_restore() which causes us to inject the vtimer irq. 
If we injected the irq here (and arranged to mask the vtimer irq) we'd
avoid a second interrupt.

Tim.


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.