[VirtLayer] Changes to the interrupt handling in POK
Philipp Eppelt
philipp.eppelt at mailbox.tu-dresden.de
Mon Aug 19 07:32:52 UTC 2013
The dual handler design wasn't done at the point of writing. I noticed
the kernel handler get's overwritten by my implementation, because
POK_SCHED_CURRENT_PARTITION equals zero at startup, when the kernel
registers handlers, and during runtime, when the first partititon is
registering it's handlers.
How is this transition done? I guess I have to do this transition for
all handlers other than the kernel ones?
On 08/18/2013 09:17 PM, Cláudio Silva wrote:
> That's it! I didn't get that dual handler design from the implementation
> on your blog.
> You should also transition to "user mode" before calling the RTEMS handler.
>
>
>
> On Sun, Aug 18, 2013 at 7:33 PM, Philipp Eppelt
> <philipp.eppelt at mailbox.tu-dresden.de
> <mailto:philipp.eppelt at mailbox.tu-dresden.de>> wrote:
>
> 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>
> > <mailto: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>>
> > > <mailto: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>>
> > <mailto: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
> > >
> > >
> >
> >
>
>
More information about the devel
mailing list