Re: [pok-devel] [Discussion] IRQ handling: chaining && pending IRQs

[Philipp Eppelt <philipp.eppelt@xxxxxxxxxxxxxxxxxxxxx>]

Hi,

I am having problems with the interrupts. I will try to explain my
current working status. It has changed a lot in the last days.
It's compiling, but not running. But nevertheless I think it's a good
point to explain what I've been doing.

First I postponed the pending IRQ counting stuff. It's unnecessary now,
I first want to get it working.

I have a meta_handler type consisting of a vector number and an array of
function pointer of POK_CONFIG_NB_PARTITION length - one handler per
partition is possible.
Then there is an array of size 16 - PIC lines - containing one
meta_handler per entry.
What we have now is an array of one meta_handler for each interrupt
vector, containing up to one handler per partition.

Then I let me inspire by RTEMS and defined a IRQ_prologue handler for
each PIC line. This prologue is building up the interrupt_frame like the
interrupt_handler from arch/x86/interrupt.h and passing control to an
_ISR_handler, which in turn passes control on to _C_isr_handler(unsigned
vector, interrupt_frame *frame).
The prologue function is registered with the IDT for it's vector number.

Up to this point I think I am fine.

IRQ 0 occurs, prologue_0 from the IDT is invoked, the prologue function
builds the interrupt_frame, places the vector number in EAX and jumps to
_ISR_handler, which pushes EAX to the stack and invokes _C_isr_handler.
The _C_isr_handler checks the meta_handler array and invokes the handler
of the currently active partition, registered in the meta_handler's
handler array.

Now the fun begins. The handler functions for the 16 IRQ lanes take the
vector and the interrupt_frame*. In contrast to the former handler
functions, which only take the interrupt_frame*.
Due to the INTERRUPT_HANDLER macro pok_bsp_irq_register takes a 'void
(*handler)(void)' function pointer.
But I need the function pointer with (unsigned, interrupt_frame*).
Unfortunately, C is getting in my way again. No objects, no function
overloading, no fun. :P

I introduced another function pok_bsp_irq_register_hw( uint_8 irq, void
(*handler)(unsigned, interrupt_frame*). It checks if irq < 16, and then
registers the handler in the meta_handler table.

But after adding the function to bsp.h the compiler told me it doesn't
know the type interrupt_frame. But I can't just include x86/interrupt.h,
so I changed the type to void* and each interrupt_handler has to cast it
back, if it wants to use the frame.

So what I end up with, is two different ways to handler interrupts. One
for hardware interrupts, one for errors and system calls.

I changed pit.c to accommodate the changes and as a first run-time test.

Up next I have to investigate if I can pass a handler from the userland.

Can you follow my explanations?
Comments? Suggestions?

Cheers,
Philipp


On 08/02/2013 04:47 AM, Julien Delange wrote:
> Hi Philip,
> 
> I think your point makes sense. Also, there is no good implementation
> for what you need : the good implementation would be the first one that
> works :)
> On my side, I would say that it would make sense to have a interrupt
> vector for each partition so that each partition can register its
> callback function for each interrupt. After that, there are several
> questions that come into the picture such as the
> architecture-dependence, etc ... It seems that you are used to this type
> of thing so ... I would just suggest that you go ahead and as long as
> you do not break any existing function, go on and commit ! Your post is
> elaborated and shows you understand the implication of what you want so,
> I think you can proceed to the changes as long as there is no
> disturbance for the existing users.
> 
> Thanks again for your good work !
> 
> 
> On Thu, Aug 1, 2013 at 5:41 AM, Philipp Eppelt
> <philipp.eppelt@xxxxxxxxxxxxxxxxxxxxx
> <mailto:philipp.eppelt@xxxxxxxxxxxxxxxxxxxxx>> wrote:
> 
>     Hi,
> 
>     currently the interrupt handling does not support two features,
>     necessary for my GSoC project: interrupt chaining and delivering pending
>     interrupts.
> 
>     If one partition registers a handler for IRQ 0, then no other partition
>     is able to register a handler for the same interrupt line.
>     As I want to run several RTEMS instances in different partitions on POK
>     one day, I need to be able to pass the clock IRQ on to every partition
>     needing it.
> 
>     I come from the L4 microkernel world and are used to stuff like that,
>     but it might introduce an overhead you are not willing to pay for in the
>     embedded world. I appreciate a lively discussion about this change.
> 
>     I have put together a blog post, with a little bit of source code.
>     http://phipse.github.io/rtems/blog/2013/07/09/how-late-is-it/
> 
>     Here is a summary of the post.
> 
>     I propose a meta handler, registering the IRQ with POK. One meta handler
>     per IRQ vector. The meta handler is intercepting the current
>     registration process and stores the received handler in a array indexed
>     by the current partition number. If several partition want to acquire
>     the same IRQ vector, their handlers are stored in the array and get
>     invoked when the IRQ fires and they are currently running.
>     If they are not running the IRQ is stored in the pending array, also
>     indexed by the partition number. When the scheduler changes partition it
>     needs to check for pending interrupts for the selected partition on
>     every meta handler and deliver them.
> 
>     Open questions: Where to store the meta-handler table.
> 
> 
>     Cheers,
>     Philipp
> 
> 
>