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

[Philipp Eppelt <philipp.eppelt@xxxxxxxxxxxxxxxxxxxxx>]

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.

http://wiki.rtems.org/wiki/index.php/GSOC_2013_-_Paravirtualization_of_RTEMS#Questionable_parts

It would be a big help if you could point out the parts, which are not
clear to the reader.

Cheers,
Philipp

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