[Qemu-devel] ARM IRQ Generation

[Qemu-devel] ARM IRQ Generation

[Karthik]

Hi,

I am working on emulating an Spansion micro with ARM Cortex R5F Core.

It has got an Interrupt Controller which accepts multiple interrupts and
generates the IRQ to the CPU based on register settings.

Now an timer module calls the qemu_irq_pulse() to signal the Interrupt
Controller (IC). The interrupt handler in the IC is called with the correct
irq number with level 1 and immediately followed by level 0. The IC in turn
signals the CPU using qemu_set_irq with level 1 and 0.

In this case the ARM CPU is not interrupted at all and there is no
exception generated, because the irq is lowered before the CPU is
interrupted.

There is a delay between qemu_set_irq() and the ARM CPU getting interrupted.
I don't see any delay between timer and interrupt controller.

Any help will be much appreciated. Thank you.

Best regards,
Karthik

Re: [Qemu-devel] ARM IRQ Generation

[Peter Maydell]

On 25 May 2016 at 11:47, Karthik <karthikshanmugam@gmail.com> wrote:
> Hi,
>
> I am working on emulating an Spansion micro with ARM Cortex R5F Core.
>
> It has got an Interrupt Controller which accepts multiple interrupts and
> generates the IRQ to the CPU based on register settings.
>
> Now an timer module calls the qemu_irq_pulse() to signal the Interrupt
> Controller (IC). The interrupt handler in the IC is called with the correct
> irq number with level 1 and immediately followed by level 0. The IC in turn
> signals the CPU using qemu_set_irq with level 1 and 0.
>
> In this case the ARM CPU is not interrupted at all and there is no
> exception generated, because the irq is lowered before the CPU is
> interrupted.

This sounds like your interrupt controller model is buggy. The
IRQ and FIQ lines into the ARM CPU are level-triggered, so typically
for an edge-triggered interrupt the interrupt controller will
latch the fact that an interrupt has come in, and hold the IRQ
line to the CPU high until the CPU acknowledges the interrupt
in some way. Alternatively, your guest might be misconfiguring
the interrupt controller to say that this timer module's interrupt
is level-triggered when it's actually edge triggered. Or your
timer device model might be buggy and using edge-triggered
behaviour when it is supposed to be level-triggered.

You need to check the hardware specs for how these various
pieces are supposed to behave and see which one is out of
line with its spec.

thanks
-- PMM

Re: [Qemu-devel] ARM IRQ Generation

[Karthik]

Okay, understood. I`ll hold the IRQ line until CPU acknowledges the
interrupt.

By the way, is there a distinction between edge and level triggered
interrupt in the qemu or it is up to the emulation implementation?

Best regards,
Karthik






On Wed, May 25, 2016 at 6:04 PM, Peter Maydell <peter.maydell@linaro.org>
wrote:

> On 25 May 2016 at 11:47, Karthik <karthikshanmugam@gmail.com> wrote:
> > Hi,
> >
> > I am working on emulating an Spansion micro with ARM Cortex R5F Core.
> >
> > It has got an Interrupt Controller which accepts multiple interrupts and
> > generates the IRQ to the CPU based on register settings.
> >
> > Now an timer module calls the qemu_irq_pulse() to signal the Interrupt
> > Controller (IC). The interrupt handler in the IC is called with the
> correct
> > irq number with level 1 and immediately followed by level 0. The IC in
> turn
> > signals the CPU using qemu_set_irq with level 1 and 0.
> >
> > In this case the ARM CPU is not interrupted at all and there is no
> > exception generated, because the irq is lowered before the CPU is
> > interrupted.
>
> This sounds like your interrupt controller model is buggy. The
> IRQ and FIQ lines into the ARM CPU are level-triggered, so typically
> for an edge-triggered interrupt the interrupt controller will
> latch the fact that an interrupt has come in, and hold the IRQ
> line to the CPU high until the CPU acknowledges the interrupt
> in some way. Alternatively, your guest might be misconfiguring
> the interrupt controller to say that this timer module's interrupt
> is level-triggered when it's actually edge triggered. Or your
> timer device model might be buggy and using edge-triggered
> behaviour when it is supposed to be level-triggered.
>
> You need to check the hardware specs for how these various
> pieces are supposed to behave and see which one is out of
> line with its spec.
>
> thanks
> -- PMM
>

Re: [Qemu-devel] ARM IRQ Generation

[Peter Maydell]

On 25 May 2016 at 13:42, Karthik <karthikshanmugam@gmail.com> wrote:
> Okay, understood. I`ll hold the IRQ line until CPU acknowledges the
> interrupt.
>
> By the way, is there a distinction between edge and level triggered
> interrupt in the qemu or it is up to the emulation implementation?

In QEMU, if you call qemu_set_irq(irq, 1) this is equivalent to
the hardware taking the IRQ wire to logical 1. Calling
qemu_set_irq(irq, 0) is taking the wire to logical 0.
(qemu_irq_pulse() takes the wire very briefly to logical 1, and
is a bit of an odd thing to do.) You need to do what the hardware
does to the hardware irq wire in the same situations when the
hardware changes the irq wire state.

Edge vs level is about what a device does when it sees a change
in state on an an incoming interrupt wire. "Edge triggered" means
it cares about the 0->1 change, and implies that it has an
internal latch which is set when the edge is detected, so that
it doesn't matter if the incoming wire drops to 0 again. "Level
triggered" means that it is the level state of the incoming wire
that matters. This is again all about "how do you behave when
you see the wire state changing", and you need to do what the
hardware does. If the hardware is strictly edge-triggered then
your model should be also; if it is always level-triggered then
your model must do the same; if it is configurable then again
you need to model the configurability.

thanks
-- PMM

Re: [Qemu-devel] ARM IRQ Generation

[Karthik]

Okay. Thank you.

Best regards,
Karthik

On Wed, May 25, 2016 at 6:18 PM, Peter Maydell <peter.maydell@linaro.org>
wrote:

> On 25 May 2016 at 13:42, Karthik <karthikshanmugam@gmail.com> wrote:
> > Okay, understood. I`ll hold the IRQ line until CPU acknowledges the
> > interrupt.
> >
> > By the way, is there a distinction between edge and level triggered
> > interrupt in the qemu or it is up to the emulation implementation?
>
> In QEMU, if you call qemu_set_irq(irq, 1) this is equivalent to
> the hardware taking the IRQ wire to logical 1. Calling
> qemu_set_irq(irq, 0) is taking the wire to logical 0.
> (qemu_irq_pulse() takes the wire very briefly to logical 1, and
> is a bit of an odd thing to do.) You need to do what the hardware
> does to the hardware irq wire in the same situations when the
> hardware changes the irq wire state.
>
> Edge vs level is about what a device does when it sees a change
> in state on an an incoming interrupt wire. "Edge triggered" means
> it cares about the 0->1 change, and implies that it has an
> internal latch which is set when the edge is detected, so that
> it doesn't matter if the incoming wire drops to 0 again. "Level
> triggered" means that it is the level state of the incoming wire
> that matters. This is again all about "how do you behave when
> you see the wire state changing", and you need to do what the
> hardware does. If the hardware is strictly edge-triggered then
> your model should be also; if it is always level-triggered then
> your model must do the same; if it is configurable then again
> you need to model the configurability.
>
> thanks
> -- PMM
>