slight problem with r254457 (kthread_add fix)

[Chris Torek]

>The kernel-FPU code only exists for x86.

I'm a bit surprised kernel-mode FPU is not supported on sparc64,
but that does seem to be the case.  (Surprising since there *is*
code to use the VIS block-copy instructions, which use the FPU
registers.  This seems to be handled as a *very* special case
though: it is called only through cpu_block_copy, and only for
pmap_copy_page, which cannot be re-entered.  So it's OK, if
suboptimal.  Using the VIS block-copy for other large copies
should be a performance win, but this requires the ability to
re-enter the routine.)

Anyway, I'm mostly just saying that I can't check the remaining
architectures as I don't know them well enough to tell.  If you
do, all is well there.  :-)

>Did you tested the patch I posted, for your situation ?

It took a while to get back to, but yes, it works fine.

[On cpu_throw:]

>It seems that you formulation somewhat contradictory.  The cpu_throw
>is used only to do the last switch out of the exiting thread.

Ah, I was thinking of the code paths that get there by calling
sched_throw() with NULL, in the various mp_machdep.c files.
You're looking at the one other code path that reaches
sched_throw() (with a non-NULL argument), in thread_exit():

>And indeed, I think that there is a bug, on x86.  The CR0.TS must be
>cleared, and fpcurthread must be reset if current cpu still carries
>FPU state of the curthread.  At least, I do not see anything which
>would guarantee that CLTS was done before cpu_throw.

It turns out this is OK because of this:

	cpu_thread_exit(td);	/* XXXSMP */

cpu_thread_exit() does an fpudrop if needed.

(I don't think this is a particularly clean design, but it
does work.)

Chris