On 18/10/12 18:55, Christoffer Dall wrote: > On Thu, Oct 18, 2012 at 1:26 PM, Marc Zyngier <marc.zyngier@xxxxxxx> wrote: >> - As you just said, the CPU starts with interrupt masked. >> - Soon enough, the GIC gets initialized (all interrupt lines disabled, >> CPU interface enabled). >> - Then, interrupts are unmasked at the CPU level. >> >> Normally, nothing should happen, as all interrupts are disabled (at the >> distributor level). But if the host has already inserted an IRQ in a LR, >> then this interrupt will fire as soon as the CPU clears its I bit, >> irrespective of the distributor state. >> >> The fix is to honor the enable bits even for interrupts that are already >> inserted in the CPU virtual control interface, by retiring them from the >> LRs. >> > > This I understand. > > What I think I confuse is that while you can take an irq exception on > the cpu that comes from nowhere and everybody should be happy, if you > actually ask the gic where it came from and you see it's from some > device you assume is not enabled on the gic, then it's bad. You being > the kernel. Correct? The kernel completely relies on the GIC not doing silly things, like signaling an interrupt that is disabled. This is absolutely fundamental. What happens in our timer case is that the interrupt is ignored by the kernel (counts as a spurious interrupt) until the driver requests the interrupt line and provides a handler. At that point, the interrupt fires, even if the driver hasn't enabled the line. Of course, the driver isn't ready yet to see the interrupt kicking in, and all hell break loose. M. -- Jazz is not dead. It just smells funny... _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
