caps(2) and FPU

[Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>]

Hi Matt, hi all,
how do you plan to support the FPU in user mode threads?
Do you agree that we want to keep the lazy context switch?

I had the following idea:
(1) the kernel continues to use lazy FPU context switches
(2) the FPU context is saved in user space to an address
    provided by the process (or the emulation layer)
(3) there is a flag (in the user space) which is set by
    the kernel at the activation time of that FPU context
    and reset afterwards
(4) a process can use a syscall/sysmessage to set the active
    FPU context. This means: If it is the real loaded FPU context,
    because e.g. no other processes/thread wanted the FPU, nothing
    happens. Otherwise the FPU is marked as invalid and the FPU
    context is loaded at the next FPU fault.
(5) a process can "free" a FPU context. That means the kernel forces
    a FPU save, if that context is loaded, otherwise it is a no-op.

The kernel has to keep the loaded and the wanted FPU context
in the virtual CPU structure, but no actual FPU context.i

This increases the user space thread switch by one syscall
and a FPU fault at the first FPU operation. It is fast in
situations where the scheduler switches to a new process
and a FPU switch is running at that moment.

The syscall in (5) can avoided in most situations, when it is not
needed, by actually checking that there is an active context.
There is no race, since worst that can happen is an unneeded syscall.

Joerg