[GSOC] POK+RTEMS interrupt status

Cláudio Silva claudiodcsilva at gmail.com
Tue Sep 17 22:11:39 UTC 2013

Hello Philipp,

Good Job.This interrupt virtualization part is probably the hardest to
implement in the Hypervisor and it's very dependent on the underlying
architecture. Actually, I think this is even harder to implement in intel
architectures due to its interrupt model and limitations on the ISA.
In some architectures you can simply return into the partition ISR handler
from the kernel handler, and it's the partition handler responsibility to
save its own task context and later return into the task.

Anyway, as Cynthia said, document what you have learned so that others (or
even yourself) can pick up where you left.

Best Regards,

On Mon, Sep 16, 2013 at 2:41 PM, Philipp Eppelt <
philipp.eppelt at mailbox.tu-dresden.de> wrote:

> Hi,
> it's suggested pencils down today and I have still trouble with the
> interrupt handling.
> I have this functionality:
> - enable/disable interrupts for a partition
> - register a handler for a partition
> - partition needs to acknowledge the interrupt before more a send
> The kernel handler sends the EOI signal to the pic, but interrupts are
> not opened before either the user space handler is called (iret) or the
> interrupt handler returns(sti).
> The transition from kernel to user space is the hacky part. I copy the
> interrupted context from the kernel to the user stack. Unfortunately,
> stack offset for the data isn't constant so I insert a magic value to
> find the beginning of the data.
> Then I modify the eip to point to the user space handler.
> The user space handler recovers the vector number and executes the RTEMS
> interrupt dispatch routine. Afterwards it sends a system call
> POK_SYSCALL_IRQ_PARTITION_ACK to signal the kernel, to send further
> clock interrupts. Then it restores the interrupted context and returns
> to the point of interruption.
> Well, it doesn't work. When I enable interrupts through the EFLAGS
> register and return to the user land, the handler isn't executing.
> Instead another clock interrupt occurs and we are back in the kernel.
> Although this interrupt should be very fast (no user handler as there
> was no ack), it still fires and fires and fires and fires ....
> So the user space handler isn't making any progress.
> I acknowledge the clock irq (0x0) during the kernel handler, because
> clock ticks invoke pok_sched() and a descheduling of the current task
> will result in an unacknowledged interrupt.
> If I leave the interrupts disabled after the iret the RTEMS
> C_dispatch_isr is called which doesn't result in a missing handler
> error, so I think my clock driver works.
> I am out of ideas by now.
> Looks this reoccurring interrupt behaviour familiar to someone? Any
> ideas where it comes from? How to fix it?
> Cheers,
> Philipp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20130917/ff49faec/attachment-0001.html>

More information about the devel mailing list