context switch code question

context switch code question

[Robert Schweikert]

Can someone please point me to the context switching code. I am
interested in the context switch structure and the values that are
saved. I am chasing a weird problem with some numerical code that uses
mmx instructions to get flush to zero to work. Specifically I am calling
the

_MM_SET_FLUSH_TO_ZERO_MODE

macro which in turn ends up calling _mm_setcsr(), wherever that might be
implemented.

What I am trying to figure out is a.) is this register value properly
set/reset during context switch and b.) is this particular register
properly transfered when the process gets moved to another CPU. 

I assume that this is a configurable option in the kernel since PII and
Pentium do not have this instruction, and thus it could just be that my
kernel is not configured correctly.

I tried to find this type of info without posting but failed.

Thanks,
Robert
-- 
Robert Schweikert <Robert.Schweikert@abaqus.com>
ABAQUS

Re: context switch code question

[Gabriel Paubert]

On Thu, Apr 17, 2003 at 05:19:32PM -0400, Robert Schweikert wrote:
> Can someone please point me to the context switching code. I am
> interested in the context switch structure and the values that are
> saved. I am chasing a weird problem with some numerical code that uses
> mmx instructions to get flush to zero to work. Specifically I am calling
> the
> 
> _MM_SET_FLUSH_TO_ZERO_MODE
> 
> macro which in turn ends up calling _mm_setcsr(), wherever that might be
> implemented.
> 
> What I am trying to figure out is a.) is this register value properly
> set/reset during context switch and b.) is this particular register
> properly transfered when the process gets moved to another CPU. 

Well, there is at least one bug in arch/i386/kernel/i387.c regarding the
handling of mxcsr on processors with SSE2 extensions. A new mxcsr bit 
(bit 6, denormals are zero or DAZ) was defined by Intel which will be 
cleared under you when you get a signal and with some ptrace operations.

The following patch should fix this, but I'm not sure that it is your
problem, and the behaviour of SSE code will vary depending on whether
the processor has SSE2 (but blame Intel for that, not me ;-)). You don't
say which kernel you are using, so I made the patch against a very
recent pull from the from 2.5 tree, but it is trivially portable to 2.4 
and might even apply as is.


===== arch/i386/kernel/i387.c 1.16 vs edited =====
--- 1.16/arch/i386/kernel/i387.c	Wed Apr  9 07:45:37 2003
+++ edited/arch/i386/kernel/i387.c	Thu Apr 24 09:52:42 2003
@@ -25,6 +25,12 @@
 #define HAVE_HWFP 1
 #endif
 
+/* mxcsr 31-16 must be zero for security reasons,
+ * bit 6 unfortunately depends on cpu features...
+ */
+#define MXSCR_MASK (cpu_has_sse2 ? 0xffff : 0xffbf )
+
+
 /*
  * The _current_ task is using the FPU for the first time
  * so initialize it and set the mxcsr to its default
@@ -208,7 +214,7 @@
 void set_fpu_mxcsr( struct task_struct *tsk, unsigned short mxcsr )
 {
 	if ( cpu_has_xmm ) {
-		tsk->thread.i387.fxsave.mxcsr = (mxcsr & 0xffbf);
+		tsk->thread.i387.fxsave.mxcsr = (mxcsr & MXCSR_MASK);
 	}
 }
 
@@ -356,8 +362,7 @@
 	clear_fpu( tsk );
 	err = __copy_from_user( &tsk->thread.i387.fxsave, &buf->_fxsr_env[0],
 				sizeof(struct i387_fxsave_struct) );
-	/* mxcsr bit 6 and 31-16 must be zero for security reasons */
-	tsk->thread.i387.fxsave.mxcsr &= 0xffbf;
+	tsk->thread.i387.fxsave.mxcsr &= MXCSR_MASK;
 	return err ? 1 : convert_fxsr_from_user( &tsk->thread.i387.fxsave, buf );
 }
 
@@ -455,8 +460,7 @@
 	if ( cpu_has_fxsr ) {
 		__copy_from_user( &tsk->thread.i387.fxsave, buf,
 				  sizeof(struct user_fxsr_struct) );
-		/* mxcsr bit 6 and 31-16 must be zero for security reasons */
-		tsk->thread.i387.fxsave.mxcsr &= 0xffbf;
+		tsk->thread.i387.fxsave.mxcsr &= MXCSR_MASK;
 		return 0;
 	} else {
 		return -EIO;

The code in arch/x86-64/ia32/fpu32.c also has a couple of 0xffbf
masks, maybe they should really be 0xffff. But I lost my x86-64 doc
in a disk crash and have not yet downloaded it again.

	Regards,
	Gabriel

Re: context switch code question

[Robert Schweikert]

Gabriel,

I am using the 2.4.20 kernel and will apply the patch and test the code.
The problem is twofold.

First bit for bit repeatability when running an application that
produces denormalized numbers. By setting flush to zero these should all
be zero and thus rounding in the least significant bit should not effect
us.

Second the following test case fails

#define FPE_SMALL_VALUE        5e-21

float sqrd(float v) { return v*v; }

int main (int argc, char** argv)
{
  _MM_SET_FLUSH_ZERO_MODE(_MM_FLUSH_ZERO_ON);
  dumm = sqrd(FPE_SMALL_VALUE);
  cerr << " before dumm = " << dumm << '\n';
}

dumm is not zero

dumm = 2.50006e-41

If I print the bit pattern I get the following

dumm hex = 0x45B1

This is compiled with the Intel compiler, although that should not make
a difference here.

Thanks,
Robert

On Thu, 2003-04-24 at 04:11, Gabriel Paubert wrote:
> On Thu, Apr 17, 2003 at 05:19:32PM -0400, Robert Schweikert wrote:
> > Can someone please point me to the context switching code. I am
> > interested in the context switch structure and the values that are
> > saved. I am chasing a weird problem with some numerical code that uses
> > mmx instructions to get flush to zero to work. Specifically I am calling
> > the
> > 
> > _MM_SET_FLUSH_TO_ZERO_MODE
> > 
> > macro which in turn ends up calling _mm_setcsr(), wherever that might be
> > implemented.
> > 
> > What I am trying to figure out is a.) is this register value properly
> > set/reset during context switch and b.) is this particular register
> > properly transfered when the process gets moved to another CPU. 
> 
> Well, there is at least one bug in arch/i386/kernel/i387.c regarding the
> handling of mxcsr on processors with SSE2 extensions. A new mxcsr bit 
> (bit 6, denormals are zero or DAZ) was defined by Intel which will be 
> cleared under you when you get a signal and with some ptrace operations.
> 
> The following patch should fix this, but I'm not sure that it is your
> problem, and the behaviour of SSE code will vary depending on whether
> the processor has SSE2 (but blame Intel for that, not me ;-)). You don't
> say which kernel you are using, so I made the patch against a very
> recent pull from the from 2.5 tree, but it is trivially portable to 2.4 
> and might even apply as is.
> 
> 
> ===== arch/i386/kernel/i387.c 1.16 vs edited =====
> --- 1.16/arch/i386/kernel/i387.c	Wed Apr  9 07:45:37 2003
> +++ edited/arch/i386/kernel/i387.c	Thu Apr 24 09:52:42 2003
> @@ -25,6 +25,12 @@
>  #define HAVE_HWFP 1
>  #endif
>  
> +/* mxcsr 31-16 must be zero for security reasons,
> + * bit 6 unfortunately depends on cpu features...
> + */
> +#define MXSCR_MASK (cpu_has_sse2 ? 0xffff : 0xffbf )
> +
> +
>  /*
>   * The _current_ task is using the FPU for the first time
>   * so initialize it and set the mxcsr to its default
> @@ -208,7 +214,7 @@
>  void set_fpu_mxcsr( struct task_struct *tsk, unsigned short mxcsr )
>  {
>  	if ( cpu_has_xmm ) {
> -		tsk->thread.i387.fxsave.mxcsr = (mxcsr & 0xffbf);
> +		tsk->thread.i387.fxsave.mxcsr = (mxcsr & MXCSR_MASK);
>  	}
>  }
>  
> @@ -356,8 +362,7 @@
>  	clear_fpu( tsk );
>  	err = __copy_from_user( &tsk->thread.i387.fxsave, &buf->_fxsr_env[0],
>  				sizeof(struct i387_fxsave_struct) );
> -	/* mxcsr bit 6 and 31-16 must be zero for security reasons */
> -	tsk->thread.i387.fxsave.mxcsr &= 0xffbf;
> +	tsk->thread.i387.fxsave.mxcsr &= MXCSR_MASK;
>  	return err ? 1 : convert_fxsr_from_user( &tsk->thread.i387.fxsave, buf );
>  }
>  
> @@ -455,8 +460,7 @@
>  	if ( cpu_has_fxsr ) {
>  		__copy_from_user( &tsk->thread.i387.fxsave, buf,
>  				  sizeof(struct user_fxsr_struct) );
> -		/* mxcsr bit 6 and 31-16 must be zero for security reasons */
> -		tsk->thread.i387.fxsave.mxcsr &= 0xffbf;
> +		tsk->thread.i387.fxsave.mxcsr &= MXCSR_MASK;
>  		return 0;
>  	} else {
>  		return -EIO;
> 
> The code in arch/x86-64/ia32/fpu32.c also has a couple of 0xffbf
> masks, maybe they should really be 0xffff. But I lost my x86-64 doc
> in a disk crash and have not yet downloaded it again.
> 
> 	Regards,
> 	Gabriel