During the break at your course, I mentioned a bug in the floating point context switching functionality in some operating systems running on PPC. Here is a slightly more detailed description. I tried to remember the details, but it's been over 4 years. It's hairy, so I suggest you get a cup of coffee before you start reading.

*** The symptoms ***
The system we were running used multiple processes running in different protected address spaces on a single CPU power pc based chip (MPC8360 e300). The problem rarely manifested itself. But occasionally after running for a few weeks, some floating point operations would give results that didn't make any sense. What was most puzzling is this issue did not happen at the same place or in the same module, but at various places in the code.

*** Reproducing the problem ***
I somehow managed to reproduce the issue by running multiple instances of a test program simultaneously. The test program was simple, it ran in a while(1) loop, incremented a floating point value and then verified that the result incremented correctly. The only unusual thing was that it disabled interrupts during the increment and verify section, and it re-enabled them after:
while 1:
   a- Disable Interrupts
   b- Increment my floating point variable
   c- Check that my variable incremented
   d- Enable Interrupts
When I ran 1 instance of this program, it would run fine. If I ran 10 simultaneous instances of this program, within 15 minutes, one of the processes would detect an error in the floating point increment operation.

Disabling interrupts is usually bad practice for real time systems, but this was legacy code and it was a little risky to remove it all. Also, in your course, you talked about the correct way to restore interrupts, which restores the previous interrupt state before your critical section.

But aside from these issues, my simple program should not result in any memory or register corruption.

*** Root cause ***
Digging deeper, it turned out that the floating registers of one of the processes were not being restored by the OS after a context switch. This was triggered by an OS optimization in combination with a race condition:
  - The race condition was in the enable/disable interrupt call (lines a and d above).
  - The optimization was the use of a technique called lazy floating point restore. This technique does not restore the floating point registers immediately after a context switch, but waits until the first floating point instruction is executed.

*** Disable/Enable Interrupt Race Condition *** The disable/enable interrupt call was not atomic on this HW architecture and required a read/modify/write to set or clear a single bit.

To disable interrupts, you had to clear a bit (EE - External Interrupt Enabled) in the MSR (machine state register).
To read and write the MSR, there were two instructions: mfmsr and mtmsr (Move From and Move To) So, disabling interrupts required three separate instructions:
1- mfmsr RegX # Move MSR to RegX
2- clear the interrupt enable bit in RegX
3- mtmsr RegX # Write the modified RegX back to MSR with Interrupts disabled If your process gets pre-empted by the OS after instruction 1, but before instruction 3, we would lose any changes that the OS had made to our MSR.

*** Lazy floating point restore ***
When switching processes, the OS saves all registers of the outgoing process in the process's context structure and loads the incoming processes' registers. In many applications, the floating point registers are not used. Saving and restoring these floating point registers could be time consuming. As an optimization, the lazy floating point mechanism allows the OS to switch processes without saving or restoring the FP registers immediately, but instead to wait until right before the first floating point instruction is executed.

To implement this, the processor can generate an interrupt to the OS when a floating point instruction is executed. This interrupt is controlled by the FP bit of the MSR: FP is floating point available state. If this bit is 0, then a special FP interrupt is triggered when a floating point instruction is executed. If it is 1, the floating point instruction executes as usual and no interrupt is generated.

The idea is that on context switch the OS switches all registers except the floating point ones, and sets FP to 0. If the OS gets an FP interrupt, that means the new process needs its floating point registers restored.  At that time, we save the existing floating point registers to the previous process context struct and restore the active process' floating point registers. Then we set FP to 1 so that subsequent floating operations execute normally.

This clearing of FP to 0 repeats every time a process is switched by the OS to delay swapping the floating point registers until they are needed by the active process.

*** The bug ***
Going back to my test program:
while 1:
   a- Disable Interrupts:
       i-   mfmsr Rx
       ii-  Clear bit EE in Rx
       iii- mtmsr Rx
   b- Increment my floating point variable
   c- Check that my variable incremented
   d- Enable Interrupts

If we get pre-empted between a-i and a-iii, we saved MSR to a Register for the purposes of clearing the interrupt enable bit. Unfortunately, as part of reading the MSR, it also read the FP bit.

The problem would arise when the FP bit is set to 1 and we get pre-empted. When the OS gives us back CPU focus, it clears the FP bit and does not immediately restore the floating point registers.

We resume execution at a-iii. This clobbers the MSR register with what was there before we got pre-empted. This means that the MSR:FP bit will be set to 1, even though the OS cleared it when giving us CPU focus. As a result, the OS will NOT get notification when we execute our first floating point instruction, and will not restore our floating point registers. We end up using floating point registers from the previously running process. Ouch.

A couple of non-ideal workarounds were:
   - Always set FP to 0 after enabling or disabling interrupts
   - Disable the lazy floating point context switch optimization

Technically, any modification of the MSR could cause problems during context switches, but in this case, it was the FP bit that got clobbered.