[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |