qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [SPARC] question on LEON IRQMP interrupt controller.


From: jcd
Subject: Re: [Qemu-devel] [SPARC] question on LEON IRQMP interrupt controller.
Date: Wed, 03 Jan 2018 10:23:32 +0100
User-agent: Roundcube Webmail/1.1.2

Le 2018-01-02 19:58, Fabien Chouteau a écrit :
Hello Jean-Christophe,

I'm the original author of this patch and I add in copy my colleague
Frederic.

On 02/01/2018 12:13, Jean-Christophe DUBOIS wrote:
I am wondering if the IRQMP code in hw/intc/grlib_irqmp.c is correct
when it comes to acknowledging interrupts.

With the actual code an interrupt can be lowered/acked only by an
"ack" from the processor which means that the trap handler related to
this external interrupt needs to be run for the ack to happen.

In particular this means that the interrupt cannot be acked only by
software. Even if the software clears the "pending" interrupts (by
writing to the CLEAR_OFFSET register before the interrupt handler is
run) this does not clear the interrupt to the processor (which is kept
asserted until the handler is run and the interrupt acked by the
processor). Do you know if this is indeed the intended behavior (I
understand that for most operating system the interrupt handler will
be run at last and this does not make a difference)?

I would expect that clearing interrupt through software (by writing to
the CLEAR_OFFSET register) would have the same effect as the processor
acknowledgment (and could avoid to run the interrupt handler if things
have already been taken care of by software).

Unfortunately the documentation I got (on the web) on the IRQMP is not
very clear on the topic.


I don't remember all the details of this CPU on top of my head, I worked
on this years ago.

If you have access to a real board the best would be to compare the
behavior of the CPU on it.

Unfortunately I don't have a real board (yet).

There's also a cycle accurate simulator of
Leon3, you can download an evaluation version here:
http://www.gaisler.com/index.php/downloads/simulators

OK, I will try the tsim simulator from Gaisler as a reference.


Anyway you can find below the patch I'd like to provide for IRQMP.


Can you explain the reason for this change? Why can't you use the
current interrupt handling?

I am working on a cooperative multitasking kernel (with no preemption). So the kernel is not handling interrupt related traps (actually the kernel is not handling the interrupt controller). All interrupts are masked at all time for all application or kernel so no interrupt trap handler is ever going to trigger (except for IRQ 15 which is not maskable).

When the tasks have nothing to do the kernel goes to sleep using ASR19 on LEON. So the system is awaken by next interrupt and the kernel will schedule the task handling the interrupt controller.

On LEON, I can go to sleep until the first interrupt. Once the first interrupt has been raised the LEON will never be able to get to sleep/idle again through ASR19 (it exists immediately) even if the interrupt controller handling task clears the interrupt (writing to CLEAR_OFFSET register). And this is because, in the actual Qemu implementation, the interrupt can only be acknowledged in the interrupt controller by the CPU through the triggering of the related trap handler.

So I am wondering if this is indeed the expected behavior in real hardware/life (interrupts can only be acked by processor and not by software).

Note: On a related subject I am wondering if the system (put in idle/sleep through ASR19) would woke up on interrupt if the interrupts are all masked through PSR (PIL) (it does wake up in Qemu for now). I will also test this on tsim before trying it on real hardware someday.


Regards,




reply via email to

[Prev in Thread] Current Thread [Next in Thread]