[coyotos-dev] Issue with FXSAVE/FNSAVE

[Jonathan S. Shapiro]

An issue arises in working out what to do about FNSAVE/FXSAVE.

In a conventional OS, the floating point save area is private to the
kernel. Applications that rely on the SSE2/SSE3/SSSE3 state fail on
earlier processors when they go to execute their instructions, but
applications that use only FPU or MMX instructions proceed unmolested
back and forth between old and new processors. The application is
completely oblivious to whether FNSAVE or FXSAVE is used to save the FPU
state.

Unfortunately, this isn't the case in Coyotos:

  1. The UPCB exposes the save area to user-mode view.
  2. FNSAVE and FXSAVE use different layouts for the subset of
     registers that they save in common.

This raises the question: if an application needs to manipulate the
saved floating point image in the UPCB, how does it know which format
was saved?

Actually, it raises another question as well: is there any scenario in
which an application can/should manipulate that state, and what
interaction occurs between this behavior and lazy save/restore of that
state?

My current thinking is as follows:


1. FLUSH, not GET/SET

If save/restore is lazy, the application cannot rely on the fact that
the floating state has been saved to the UPCB unless it does something
explicit to force the save. Some sort of trap is required for this. Once
we are entering the kernel anyway, should we just use get/set operations
on the floating state?

I believe not, because these would be the only kernel ops that
accept/return strings, and it is better to avoid that. I therefore think
that we need a "flush" operation that fully flushes all register state
to the UPCB. On architectures that can do lazy reload, the application
can rely on the laziness of the reload. That is: after a flush, the
floating point state remains in the UPCB until the next floating point
instruction.

2. FLUSH behavior

The flush operation will use the FXSAVE instruction whenever the
hardware architecture supports it. In addition to executing
FXSAVE/FNSAVE, it will update a bit somewhere in the UPCB to say what
was saved.

The alternative is to save an FXSAVE-compatible structure by hand on
legacy machines. This is a little slower, but possibly cleaner.


Opinions? Should the implementation on older hardware simulate the
FXSAVE-style save area?

-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC
+1 443 927 1719 x5100