cvs commit: src/sys/i386/isa npx.c

[David Xu]

On Sunday 28 May 2006 21:58, Bruce Evans wrote:

> OK if it is correct to not copy the environment.
>
I will revert changes, I think I should keep it safe as before.

> BTW, your other patch that masks the top 16 bits in mxcsr needs to be
> extended to sometimes mask 0x40 (DAZ).  The amd64 arch manual says to
> mask with mxcsr_mask which is in the fxsave image.  Cleared bits in
> mxcsr_mask indicate reserved bits in a future-proof way.  Unfortunately,
> this isn't past-proof so the following complications are needed: if
> the CPU stores 0 in mxcsr_mask, it means that mxcsr_mask is not
> supported; old CPUs (at least amd64 ones) that don't support mxcsr_mask
> also don't support DAZ, so the correct mask for them is 0xFFBF.  These
> complications are implemented in Linux's i386 so I suppose they are
> no-ops at worst for non-amd64 CPUs.  Linux stores the mask in a global
> variable.  I think this breaks the asymmetric SMP case more than
> necessary. 
process migrates from one CPU to another, I don't think you can use such 
CPUs in same system if they are different in this case.

> FreeBSD's amd64 uses mxcsr_mask without fixing up the case 
> where it is 0.  So does Linux-2.6.10's x86_64 (it Initializes the
> global variable but doesn't use it).
>
> Behaviour of mxcsr and DAZ on some CPUs:
>
> AXP2600 (Barton): mxcsr_mask = 0; attempting to set DAZ traps
> P3-800 (freefall): same as AXP2600
> A64 (Id0xf48 stepping 8): mxcsr_mask = 0xFFFF; setting DAZ works
>
> > 	} else
> > +#endif

I haven't tried DAZ bit, will you fix it ?

>
> vm_machdep.c is missing a DEV_NPX ifdef around the call here.  Of course,
> lots of things would break if the option to not use npx were exercised.
> CPU_ENABLE_SSE is a silly option too.
>
yes, silly.

> > 		state->sv_87.sv_env.en_cw = cw;
> > 	newtd->td_pcb->pcb_flags |= PCB_NPXINITDONE;
> > }
>
> Bruce