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

[Joel Sherrill <Joel.Sherrill@xxxxxxxxxxx>]

The most important things at this point are

+ to ensure your status, next steps, etc are documented
+ capture thoughts on doing another architecture or hypervisor
+ ensure all patches are merged and you are happy with things
When checking the code out again
+ ensure others can reproduce what you have. This is merging
plus documentation.

And we hope you stay involved. Seriously!! This is an area with lots of work left to be done and multiple open source communities to benefit.

I plan to try to reproduce your work as soon as I can.

Philipp Eppelt <philipp.eppelt@xxxxxxxxxxxxxxxxxxxxx> wrote:


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
>
>

_______________________________________________
rtems-devel mailing list
rtems-devel@xxxxxxxxx
http://www.rtems.org/mailman/listinfo/rtems-devel