294 | | = Issues = |
295 | | |
296 | | This section deals with implementation issues, which occurred during the implementation process. |
297 | | * No console write in POK. |
| 294 | = Virtualization layer (POK) = |
| 295 | |
| 296 | The virt. layer is implemented in the user code part of the partitions code. |
| 297 | Mostly, it only makes a syscall and passes the arguments through. |
| 298 | |
| 299 | = libpart.a creation (POK) = |
| 300 | |
| 301 | libpart.a is build after libpok.a but with the same makefile rule. |
| 302 | libpart.a consists of libpok.a plus the objects from the user code files. |
| 303 | |
| 304 | = Interrupt design (POK) = |
| 305 | |
| 306 | I redesigned the interrupt handling in POK. |
| 307 | Previously there was no way of knowing which interrupt number occurred, as the IDT directly invoked the corresponding handler. |
| 308 | I replaced all 16 hardware interrupt handlers with predefined handlers, which know their interrupt number. |
| 309 | Then a meta handler is called to look up the registered handlers for this vector number and invokes first a kernel handler and then the partition handlers. |
| 310 | The lookup table is an array consisting of objects which have fields for the vector number, the handler list for the number of configured partitions plus one (kernel) and a list to indicate if the partition is waiting for an interrupt. |
| 311 | The waiting flag is necessary, because a partition needs to process the interrupt before a new one can be delivered. |
| 312 | |
| 313 | To register a handler I introduced new syscalls with POK to register and unregister a handler, to enable and disable interrupt delivery to the partition and to acknowledge an interrupt. |
| 314 | The acknowledge syscall sets the waiting flag mentioned above. |
| 315 | |
| 316 | The functions corresponding to these syscalls are implemented in the x86 bsp.c file. |
| 317 | There is a new pok_bsp_irq_register_hw function, which is only accepting IRQ values for the hardware IRQ lines (0-15). |
| 318 | pok_bsp_irq_register cannot be used to register IRQ handlers for hardware IRQs. |
| 319 | |
| 320 | = Remaining Issues = |
| 321 | == Forwarding interrupts to user space handlers == |
| 322 | |
| 323 | |
| 324 | The transition to user space proved very challenging. |
| 325 | I was not able to implement it in a reliable way. |
| 326 | In my design I will only make the transition to user space once. |
| 327 | The kernel stack will be cleaned up, after the transition, so no memory leaks will occur there. |
| 328 | To make this transition the interrupted context and the vector is passed to the user space handler, which is responsible to find the right handler for this interrupt number and before it returns to the point of interruption it has to restore the register and stack state. |
| 329 | The return instruction of the handler is used to pop the interrupted EIP from the stack. |
| 330 | Then the user space shall proceed like no interrupt occurred. |
| 331 | |
| 332 | This doesn't work well. |
| 333 | This is implemented with manual stack manipulation and magic values to find the data on the stack. |
| 334 | This leads to GPF (0xd) as the EIP is pointing to invalid instructions. |
| 335 | This needs debugging - but GDB is of no help, because it can't handle segmentation. |
| 336 | At time of writing, I need to write documentation before I can go back to debugging. |