[patch][5/5] powerpc: Add the general support for Embedded Floating-Point instructions

[Zhu Ebony-r57400]

> >>
> >> Why do we need a separate ret_from_except_spe_full?
> >
> > I'm not sure if the kernel will return from exception in a multi- 
> > thread way, but the truth is if restoring EVRs in exsiting 
> > ret_from_except_full, some non-SPE exception will try to 
> retore EVR. 
> > At that time, the MSR[SPE] may not be enabled, which will 
> cause error.
> 
> Well, with EE disabled nothing is going to interrupt the 
> exception thread, so you can do all this in C code.

Do you mean disabling MSR[EE] in handler C code before calling
ret_from_except_full?


> >>> diff --git a/arch/powerpc/kernel/traps.c
> >> b/arch/powerpc/kernel/traps.c
> >>> index 535f506..68407d4 100644
> >>> --- a/arch/powerpc/kernel/traps.c
> >>> +++ b/arch/powerpc/kernel/traps.c
> >>> @@ -986,6 +986,22 @@ #endif /* CONFIG_FSL_BOOKE */  #ifdef
> >> CONFIG_SPE
> >>> void SPEFloatingPointException(struct pt_regs *regs)  {
> >>> +#ifdef CONFIG_E500
> >>> +	extern int sigfpe_handler(struct pt_regs *regs);
> >>> +	int err;
> >>> +	if (current->thread.spefscr & ~0x3f) {
> >>> +		err = sigfpe_handler(regs);
> >>> +		if (err == 0) {
> >>> +			regs->nip += 4;
> >>> +			return;
> >>> +		} else {
> >>> +			current->thread.spefscr = 0x0;
> >>
> >> Why do clear spefscr and re-execute?
> >
> > I tried to make the code more robust here. Currently, all the SPE 
> > instructions that may cause execption are handled. But 
> someday if the 
> > instruction set is extended and not supported by software, 
> this code 
> > can make sure we handle it with powerpc default value, which won't 
> > make kernel crash.
> 
> Lets worry about that when it occurs, its probably better 
> that the apps crash and we fixup the kernel when it happens.

Currently err != 0 won't happen on PQ3/PQ38 cores. So does it mean
that we can simplify the code here?


> 
> >>> +			return;
> >>> +		}
> >>> +	} else {
> >>> +		return;
> >>
> >> How else would we get here if not by having spefscr bit set?
> >
> > As above, I want to make it more robust. If no unexpected condition 
> > would happen, we can remove this off.
> 
> Lets remove it since it shouldn't happen
> 
OK, I will.

> >>> +	current->thread.spefscr &= 0x3f;
> >>
> >> can't clear spefscr this way.
> >>
> >> Need to do what the existing handler was doing here.
> >
> > Do you mean I need to do it like this:
> >
> > 	unsigned long spefscr;
> > 	spefscr = current->thread.spefscr;
> > 	spefscr = 0x3f;
> > 	current->spefscr = spefscr ;
> >
> > I'm not really understand...
> 
> What I meant is the existing handler uses the 
> thread.fpexc_mode to keep track of the "exception" flags that 
> an application may want to enable as part of the STND-C fpenv 
> support (find a copy of the ANSI spec and read up on 
> Floating-point Environment).  The std c-lib provides 
> functions like fesetexceptflag(), fetestexcept(), fesetround (), etc..
> 
> Some of this will end up calling into set_fpexc_mode() in the 
> kernel via the prctl system call.
> 
> The idea was we use thread.fpexc_mode to keep track of what 
> the C runtime env wants the flags to be, than in the 
> exception handler we can use those flags to decide if we 
> should raise an software SIGFPE exception on the process.
> 
> So when you emulate the instructions you need to handle 
> determining if a software SIGFPE should be sent or not.
> 
> I hope that makes sense.
> 
> - k
> 

I see. By this way we can synchronize kernel and runtime environment
for floating point flags.  Is it a correct way that we use the existing
handler
to track exception flags and set current->thread.spefscr, then entering
sigfpe_handler()?