On Thu, Oct 18, 2012 at 2:16 PM, Marc Zyngier <marc.zyngier@xxxxxxx> wrote: > 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. > I see, thanks for the explanation. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
