[pok-devel] Re: [GSOC] POK+RTEMS interrupt status

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,

Cláudio

On Mon, Sep 16, 2013 at 2:41 PM, Philipp Eppelt <philipp.eppelt@xxxxxxxxxxxxxxxxxxxxx> 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