Re: [RFC] x86: xsave/xrstor support, ucontext_t extensions

[Mikael Pettersson]

H. Peter Anvin writes:
 > Michael, you wrote:
 > 
 > > Hmm, right now it seems this field has a de-facto ABI of being
 > > either 0xffff (plain) or 0x0000 (fxsr). Using other values would
 > > confuse at least one application I know of. Sad.
 > 
 > ... could you share what application that is?  This otherwise would be 
 > ideal.

It's the virtual machine for the Erlang/OTP concurrent functional
language. It's open-source and used extensively for telecom and
internet server applications.

The language doesn't allow non-finite FP values, so FP ops must
be checked. As an optimisation, the virtual machine groups FP ops
into blocks, enables FP exceptions, and has a SIGFPE handler that
just records that an FP exception has occurred in a per-thread flag.
After each FP block there's a single check for this flag, which if
set triggers a language-level "badarith" exception.

In order to resume from an SSE2 exception the SIGFPE handler must
update some parts of the sigcontext. But first the handler must detect
if the exception came from x87 or SSE2, which requires looking at the
mxcsr field, which requires looking at the magic field to detect the
fpstate's layout.

The magic field is described as follows in sigcontext.h:

>struct _fpstate {
>	...
>        unsigned short  magic;          /* 0xffff = regular FPU data only */
>	...
>};
>
>#define X86_FXSR_MAGIC          0x0000

While this in theory allows for other values than -1 and 0 in magic,
any such value would be != FXSR_MAGIC and therefore would not trigger
the application's "inspect the fxsr layout" logic.

/Mikael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/