[VirtLayer] Changes to the interrupt handling in POK

[Philipp Eppelt]

Hi,

why only talking about it and not implementing it right away? ;)

POK administers now one meta_handler per HW IRQ line. Each meta_handler
consists of a vector number and table of the size
POK_CONFIG_NB_PARTITION + 1. So the meta_handler can administer one
handler per partition and one handler for the kernel. The clock tick,
for instance, needs a kernel handler and can now be forwarded to a
partition.
The kernel handler is invoked on each interrupt before the partition
handler is called.
So there is no overruling of the POK kernel.

As far as I tested it, the partition handler runs side by side with the
kernel handler with a constant offset, as it is registered later in time.

Cheers,
Philipp




On 08/18/2013 08:01 PM, Cláudio Silva wrote:
> Ok. That clarifies the next steps.
> You are correct;  POK should be tested first without RTEMS integration.
> My question was more about the separation between the RTEMS part of the
> interrupt handler and the POK part. If RTEMS registers a handler it will
> monopolize it; i.e. there is no possibility to run a POK handler and
> then an RTEMS handler. This is required to maintain segregation and to
> prevent RTEMS from interfering with POK. If RTEMS registers a handler
> for a vector already user by POK (e.g. clock tick interrupt), POK cannot
> be overruled and be dependent on RTEMS to run its own code. But for a
> first iteration it's OK to ignore this.
> 
> 
> Cláudio
> 
> 
> 
> On Sun, Aug 18, 2013 at 3:03 PM, Philipp Eppelt
> <philipp.eppelt at mailbox.tu-dresden.de
> <mailto:philipp.eppelt at mailbox.tu-dresden.de>> wrote:
> 
>     Hi,
> 
>     currently I have no RTEMS partition running on POK, as these changes
>     must first be validated with pure POK partitions. Also I haven't written
>     the code to get a interrupt handler through the partition abstraction.
>     CLOCK_HANDLER is a macro which is incrementing the tick counter and
>     invoking the scheduler in the POK kernel.
> 
>     To register IRQ handlers from a partition, e.g. an RTEMS partition, I
>     need to create a new syscall first, to get the callback function into
>     the meta_handler list.
> 
>     So when RTEMS tries to attach to an interrupt, the virtualization layer
>     implementation of POK is invoked and registers a predefined handler via
>     a syscall with the meta_handler for this irq number. When the interrupt
>     occurs the registered handler is invoked with the vector number as an
>     argument. Then the handler invokes C_dispatch_isr() in RTEMS passing the
>     vector number along.
> 
>     That's the plan, for the next week.
> 
>     Cheers,
>     Philipp
> 
> 
>     On 08/18/2013 02:45 PM, Cláudio Silva wrote:
>     > Good job Philipp. It seems a nice first iteration for interrupt
>     > virtualization. Did you get to try it?
>     > If I got it right, the POK part of the interrupt handler
>     (CLOCK_HANDLER
>     > ??) is running after the virtualized RTEMS handler?
>     >
>     > Regards,
>     > Cláudio
>     >
>     >
>     > On Sun, Aug 18, 2013 at 12:18 AM, Philipp Eppelt
>     > <philipp.eppelt at mailbox.tu-dresden.de
>     <mailto:philipp.eppelt at mailbox.tu-dresden.de>
>     > <mailto:philipp.eppelt at mailbox.tu-dresden.de
>     <mailto:philipp.eppelt at mailbox.tu-dresden.de>>> wrote:
>     >
>     >     Hi,
>     >
>     >     lately I worked a lot to extend POK with necessary features to
>     >     accommodate an RTEMS partition.
>     >     Since hello world works, I need a way to pass clock ticks to
>     the RTEMS
>     >     partition running on POK. Therefore the interrupt handling
>     needs to
>     >     support custom handlers.
>     >
>     >     If everything works out, I can enable the virtualization layer to
>     >     register an interrupt vector and if it occurs RTEMS is notified by
>     >     invoking C_dispatch_isr().
>     >
>     >     Blog:
>     >    
>     http://phipse.github.io/rtems/blog/2013/08/17/pok-hardware-interrupt-handling/
>     >
>     >     Source:
>     >     https://github.com/phipse/pok
>     >
>     >     Cheers,
>     >     Philipp
>     >     _______________________________________________
>     >     rtems-devel mailing list
>     >     rtems-devel at rtems.org <mailto:rtems-devel at rtems.org>
>     <mailto:rtems-devel at rtems.org <mailto:rtems-devel at rtems.org>>
>     >     http://www.rtems.org/mailman/listinfo/rtems-devel
>     >
>     >
> 
>