[GSOC] POK+RTEMS interrupt status
philipp.eppelt at mailbox.tu-dresden.de
Wed Sep 18 12:20:36 UTC 2013
On 09/18/2013 12:11 AM, Cláudio Silva wrote:
> 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.
I expanded the project's wiki page with an "Implementation" section and
updated some of the previous parts.
It would be a big help if you could point out the parts, which are not
clear to the reader.
> Best Regards,
> On Mon, Sep 16, 2013 at 2:41 PM, Philipp Eppelt
> <philipp.eppelt at mailbox.tu-dresden.de
> <mailto:philipp.eppelt at mailbox.tu-dresden.de>> wrote:
> 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?
More information about the devel