On Mon, Aug 04, 2014 at 01:31:05PM +0100, Marc Zyngier wrote: > On Mon, Aug 04 2014 at 12:57:16 pm BST, Christoffer Dall <christoffer.dall@xxxxxxxxxx> wrote: > > On Mon, Jun 16, 2014 at 07:47:57PM +0100, Marc Zyngier wrote: > >> Thomas, all, > >> > >> Since ARM has grown some virtualization extensions, there is a > >> particular issue I've carefully avoided to address, and which is now > >> biting me exactly where you think it does. > >> > >> Let's expose the problem: > >> - We have a per-CPU timer (the architected timer) > >> - This timer is shared across virtual machines > >> - We context-switch the state of the timer on entry/exit of the VM > >> > >> The state of the timer itself is basically a control word and a > >> comparator value. Not much. Ah yes, one tiny detail: the state of the > >> interrupt controller (the GIC) is also part of the state. > >> > >> This interrupt state is not the pending state, but the internal state > >> (called the "active" state), indicating if the interrupt is in > >> progress or not. If the interrupt is active (and configured as a level > >> interrupt), then the interrupt can't fire again until the guest EOIs > >> it (there is some special hardware dedicated to this). > > > > Can you clarify this part. I was under the impression from reading the > > GICv2 specs at least that an active interrupt can become active and > > pending (and the pending part of that would cause the interrupt to fire > > again). Specifically, I'm thinking about transition A2 in Figure 3-1 in > > the GICv2 spec (ARM IHI 0048B.b). Am I reading this incorrectly or is > > there something special about the timer in this regard? > > Nothing special about the timer. Just that the timer being a level > interrupt, the pending state is a direct consequence of the level being > high (as mentionned in the note at the bottom of 1.4.2). > > You go from Pending to Active-and-Pending, and then to Active (when the > timer is reprogrammed/disabled, though you may go back to A&P if the timer > fires again immediately). Eventually, after the EOI, you go back to > Inactive. > > Here, the only bit we really care about is the Active bit (Pending > changes anyway, as we save/restore the timer context). > > Or is there something that I don't understand in your question? > If not using priorities, what difference does it make if we save/restore the active bit? The whole point is that a timer that the guest hasn't reprogrammed/disabled should not raise a hardware interrupt, right? So what I inferred from your text is that we prevent that from happening by restoring the active bit. But that will still cause the hardware to assert the signal (we will become A&P) and that would raise the interrupt on the hardware, we would trap again, and so on. Or? -Christoffer _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
