ia32/exceptions: improve FPU exceptions

[badochov]

Description

This PR aims to resolve improve situation with exceptions caused by FPU on Intel.

FIrst commit resolves issue where recently instead of a triple fault on FPU error exception 16 got presented on the screen, due to wrong instruction setting flag.
The next commit fixes saving context in exceptions.
Following commit changes fsave in context saving procedure to fnsave to prevent infinite recursion on FPU exception causing a triple fault. Due to this change exception 16 is reported correctly as exception 16 not as tripple fault. Thus, exception 16 is excepted to appear not Triple fault.

The following commits are optimizations.

I tried to dig into the root cause, here are my findings:
In my testing I have found:

• the fail always happens after first schedule of the program after returning from the program handler/
• the context on the user stack in affected runs is corrupted just after entering the _signal_trampoline, I have confirmed it is correct in

  phoenix-rtos-kernel/proc/threads.c

  Line 1503 in e2a6b1f

  hal_spinlockClear(&threads_common.spinlock, &sc);

• the corruption affects two fields savesp and cr0Bits. In affected runs the cr0Bits is corrupted to hold the same value as eax.

The fail occurs due to bad cr0Bits as we remove the TS flag from cr0 without initializing the FPU.

Additionally, I have noticed that in

phoenix-rtos-kernel/hal/ia32/_exceptions.S

Line 103 in e2a6b1f

movl %eax, FPU_CONTEXT_SIZE(%esp)

and

phoenix-rtos-kernel/hal/ia32/_interrupts.S

Line 118 in e2a6b1f

movl %eax, FPU_CONTEXT_SIZE(%esp)

cr0Bits is temporarily replaced with eax. Additionally ia32 is the only platform not disabling iterrupts during context restoration.

Unfortunatelly, I was not able to understand the real reason behind it. Initially this PR got a commit with potential solution by disabling interrupts during stack restoration, sadly insufficient. Initially I thought that it worked but it didn't as the interrupts were not properly reenabled before passing control to the user space.

Perhaps interleave causing problems is timer interrupt just after iret instruction passsing control to the user in hal_jmp.

Motivation and Context

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Chore (refactoring, style fixes, git/CI config, submodule management, no code logic changes)

How Has This Been Tested?

• Already covered by automatic testing.
• New test added: (add PR link here).
• Tested by hand on: ia32-generic-qemu

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing linter checks and tests passed.
• My changes generate no new compilation warnings for any of the targets.

Special treatment

• This PR needs additional PRs to work (list the PRs, preferably in merge-order).
• I will merge this PR by myself when appropriate.

[github-actions]

Unit Test Results

7 949 tests  ±0   7 231 ✅ ±0   40m 11s ⏱️ +2s
  461 suites ±0     718 💤 ±0 
    1 files   ±0       0 ❌ ±0 

Results for commit 1967f0f. ± Comparison against base commit e2a6b1f.

♻️ This comment has been updated with latest results.