[patch] Adding optimized kernel copying support - Part III

[Matthew Dillon]

:AFAIR the DFly FPU rework allows to use FPU/XMM instructions in their  
:kernel without the need to do some manual state preserving (it's done  
:...
:
:Bye,
:Alexander.

    That actually isn't quite how it works.  If the userland had active
    FP state then the kernel still has to save it before it can use the
    FP registers.  The kernel does not have to restore it, however (that is,
    it can just let userland take a fault to restore its FP state).  
    However, the kernel still has to mess around with CR0_TS when pushing
    and popping an FP context / save area.

    The FP state reworking in DragonFly had the following effects:

    * We now have a save area pointer instead of a fixed, static save area.
      This allows FP state to be 'stacked' without having to play weird
      games with a static save area.

    * The standard FP restoration fault is no longer limited to userland.
      The kernel can push its own state, switch away to another thread,
      switch back, and take a fault to restore it, independant of the
      user FP state.

    --

    It would be possible to simplify matters and actually implement what
    you say... the ability to use FP registers without any manual state
    preserving.  That is, to be able to treat the FP registers just like
    normal registers.  It would require saving and restoring a great deal
    more state in the interrupt/exception frame push code and the
    thread switch code, though.  It could be conditionalized based CR0_TS
    or it could just be done unconditionally.  I'm not sure it would yield
    any improvement in performance, though.

    There is also the problem of the storage required to manage multiple
    save areas.  It's something like, what, 512 bytes on the stack?  Because
    of that DragonFly still implements an FPU interlock so the kernel
    doesn't stack more then one additional save area due to FAST interrupts,
    stacked exceptions, etc.

					-Matt