[ECOS] On demand FP context switch major problem.

[Sergei Organov <osv at javad dot ru>]

Hello,

I've almost finished the "on demand" FP context switch support in the PowerPC
HAL, but at the end faced with a problem for which I don't see a reasonable
solution. Here is the description of the problem.

To switch FP context on demand we need to disable FP in the usual context
switch routine by means of clearing the "FP enable" bit in the MSR. It means
that at thread level of execution the FP bit in the MSR could be cleared any
time if scheduler isn't locked and/or interrupts aren't disabled. It in turn
means that in thread code we can safely change MSR only if above condition(s)
is(are) met. But the EE (external interrupt enable) bit is also located in the
MSR, so it's unsafe to disable interrupts if scheduler isn't locked!

The above has unfortunate consequences for the code in the
HAL_DISABLE_INTERRUPTS macro. With "on demand" FP context switch is used, this
macro should somehow lock the scheduler before reading the MSR and then unlock
it back after writing the MSR :-(

The above discussion didn't take into consideration support for the use of FPU
in the interrupt handlers (ISRs/DSRs). If this support is added, then even
locking of the scheduler doesn't help. In this case only disabling of
interrupts gives us a safe way to change MSR, but once again disabling of
interrupts needs changing of MSR :-(

Any suggestions? Hopefully I'm just missing something obvious.

If above explanation of the problem isn't clear, here is a possible scenario:

1. Assume Thread1 is running with FP enable bit set (it owns FP context) and
   invokes HAL_DISABLE_INTERRUPTS macro.
2. HAL_DISABLE_INTERRUPTS macro reads current MSR value to a GPR, saves it
   into memory and clears EE bit in the GPR.
3. Thread1 is preempted by Thread2 that executes FP instruction and thus
   receives ownership of the FP context.
4. Thread2 is put to the waiting state and execution returns to the Thread1.
5. Thread1 continues execution but now FP enable bit in the MSR is cleared,
   because FP context is owned by the Thread2.
6. HAL_DISABLE_INTERRUPTS macro writes the GPR with EE bit cleared to the
   MSR and thus effectively sets the FP bit in the MSR!
7. Thread1 continues to execute with interrupts disabled and executes floating
   point instruction. As the FP enable bit is set, this doesn't produce "FP
   unavailable" exception and thus FP context isn't switched. As a result, the
   FP context of the Thread2 is clobbered by the Thread1 :-(

BR,
Sergei.