Re: [ECOS] On demand FP context switch major problem.

[Nick Garnett <nickg at cygnus dot co dot uk>]

Sergei Organov <osv@javad.ru> writes:

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


This is one of the annoying features of the PowerPC, and other RISC
processors, that "global" state and "per-thread" state are mixed up in
the same register.

One option would be to always clear the FP enable bit in
HAL_DISABLE_INTERRUPTS (probably HAL_ENABLE_INTERRUPTS and
HAL_RESTORE_INTERRUPTS too). This would make your described scenario
work correctly since you would get an FP exception at step 7. In the
simple case you would also get an FP trap on the next FP instruction,
which would see that the current thread is already the FPU owner and
just set the FP enable bit.

Taking the extra trap is unpleasant, but with a suitable fast path it
should not be too expensive. It is unlikely that code which plays with
the interrupt enable is also doing a lot of floating point, and the
thread may well be timesliced or preempted before moving from one to
the other anyway. So the chances are that this will not result in any
more FP traps than before. There has to be a FP trap per thread switch
anyway, and changing the interrupt enable should be a lot less common
than that.



-- 
Nick Garnett
Cygnus Solutions, a Red Hat Company
Cambridge, UK