MIPS: Fix MIPS_O32_FP64_SUPPORT for 64bit CPUs before R2

  MIPS_O32_FP64_SUPPORT enables possibility of using all 32 FPRs on 32bit
kernel in case CPU implemented FR1. As FR1 is present on all 64bit CPUs
following R4000's priviliged spec, there is no reason to limit such support
to R2+ CPUs.

Fix it by remove architecture reversion conditions in FR1 context switch
code and enable relevant bits in kernel's FIR copy.

Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
---
 arch/mips/include/asm/asmmacro.h |  6 ++----
 arch/mips/include/asm/fpu.h      |  3 +--
 arch/mips/kernel/elf.c           |  5 ++---
 arch/mips/kernel/fpu-probe.c     | 17 +++++++++++++++++
 arch/mips/kernel/r4k_fpu.S       | 16 ++++++----------
 5 files changed, 28 insertions(+), 19 deletions(-)
  

On Fri, 19 May 2023, Jiaxun Yang wrote:

> MIPS_O32_FP64_SUPPORT enables possibility of using all 32 FPRs on 32bit
> kernel in case CPU implemented FR1. As FR1 is present on all 64bit CPUs
> following R4000's priviliged spec, there is no reason to limit such support
> to R2+ CPUs.

 I guess one can do it and still run FPXX software, but I fail to see what 
gain it provides.  For FP32 it breaks things as accesses to odd-numbered 
FPRs will no longer get at the high part of a double value and for FP64 
there are no MTHC1/MFHC1 instructions required to access the high part.

 What problem are you trying to solve?  And how did you verify this patch?

> --- a/arch/mips/kernel/fpu-probe.c
> +++ b/arch/mips/kernel/fpu-probe.c
> @@ -289,6 +289,23 @@ void cpu_set_fpu_opts(struct cpuinfo_mips *c)
>  			c->options |= MIPS_CPU_FRE;
>  	}
>  
> +	/* Fix up FIR for FPU earlier than R2 */
> +	if (!cpu_has_mips_r2_r6) {
> +		c->fpu_id |= MIPS_FPIR_S;
> +#ifdef CONFIG_CPU_R4K_FPU
> +		/* All known R4000 class FPU implemented double */
> +		c->fpu_id |= MIPS_FPIR_D;
> +#endif

 Currently all FPUs we support implement double and we require that, so no 
need to make this piece conditional (I would use IS_ENABLED otherwise, so 
as not to clutter the source with #ifdef), but `c->fpu_id' is also exposed 
to the user via ptrace(2), so this has to reflect hardware and not give a 
synthesized value.

  Maciej
  

> 2023年5月19日 21:10，Maciej W. Rozycki <macro@orcam.me.uk> 写道：
> 
> On Fri, 19 May 2023, Jiaxun Yang wrote:
> 
>> MIPS_O32_FP64_SUPPORT enables possibility of using all 32 FPRs on 32bit
>> kernel in case CPU implemented FR1. As FR1 is present on all 64bit CPUs
>> following R4000's priviliged spec, there is no reason to limit such support
>> to R2+ CPUs.
> 
> I guess one can do it and still run FPXX software, but I fail to see what 
> gain it provides.  For FP32 it breaks things as accesses to odd-numbered 
> FPRs will no longer get at the high part of a double value and for FP64 
> there are no MTHC1/MFHC1 instructions required to access the high part.

Actually software may access the high part by SDC1/LDC1.
FP32 binaries are still going to run at FR0 mode.

> 
> What problem are you trying to solve?  And how did you verify this patch?

Was trying to deal a proprietary JIT software who want to enable FR1 via prctl
on Loongson-2F with 32 bit kernel.

> 
>> --- a/arch/mips/kernel/fpu-probe.c
>> +++ b/arch/mips/kernel/fpu-probe.c
>> @@ -289,6 +289,23 @@ void cpu_set_fpu_opts(struct cpuinfo_mips *c)
>> c->options |= MIPS_CPU_FRE;
>> }
>> 
>> + /* Fix up FIR for FPU earlier than R2 */
>> + if (!cpu_has_mips_r2_r6) {
>> + c->fpu_id |= MIPS_FPIR_S;
>> +#ifdef CONFIG_CPU_R4K_FPU
>> + /* All known R4000 class FPU implemented double */
>> + c->fpu_id |= MIPS_FPIR_D;
>> +#endif
> 
> Currently all FPUs we support implement double and we require that, so no 
> need to make this piece conditional (I would use IS_ENABLED otherwise, so 
> as not to clutter the source with #ifdef), but `c->fpu_id' is also exposed 
> to the user via ptrace(2), so this has to reflect hardware and not give a 
> synthesized value.

Alas, I thought R2030 class FPU does not have double? Since MIPS-IV spec
says SDC1 is introduced in MIPS II.

Thanks
Jiaxun

> 
>  Maciej
  

On Fri, 19 May 2023, Jiaxun Yang wrote:

> > I guess one can do it and still run FPXX software, but I fail to see what 
> > gain it provides.  For FP32 it breaks things as accesses to odd-numbered 
> > FPRs will no longer get at the high part of a double value and for FP64 
> > there are no MTHC1/MFHC1 instructions required to access the high part.
> 
> Actually software may access the high part by SDC1/LDC1.

 I'm aware of that, but you'd need a new psABI variation really to handle 
such an arrangement.  None of the existing FP32, FP64, FPXX handles it.

> > What problem are you trying to solve?  And how did you verify this patch?
> 
> Was trying to deal a proprietary JIT software who want to enable FR1 via prctl
> on Loongson-2F with 32 bit kernel.

 There may be a better way: rather than avoiding MTHC1/MFHC1, handle them 
in the FPU emulator where unavailable in FR=1 mode while leaving the rest 
to hardware.  That would make regular FR64 software work.

 I'd expect such a JIT to have other issues with pre-R2 hardware though, 
with missing machine instructions.  I had a similar situation a few years 
ago with FireFox's JIT making assumptions above the MIPS ISA level the 
piece of software was itself compiled for and opted for just disabling the 
JIT, as fixing FireFox and rebuilding it would be more effort than it was 
worth in my view.

 This might be the best way for you to move forward too, and I'm all but 
enthusiastic about adding a workaround in the kernel for a broken piece of 
proprietary user software.  Sorry.

 Also I seem to remember there was a pitfall with running 32-bit software 
on pre-R2 hardware in the FR=1 mode, but maybe I'm making up things here.  
It's been so long since I last looked into this.

 In any case you do need to verify this somehow, like by running the math 
part of the glibc testsuite with o32 in the FR=1 mode on pre-R2 hardware.  
Running the GDB test suite to make sure ptrace(2) works fine with the new 
FPU configuration would make sense too.

> > Currently all FPUs we support implement double and we require that, so no 
> > need to make this piece conditional (I would use IS_ENABLED otherwise, so 
> > as not to clutter the source with #ifdef), but `c->fpu_id' is also exposed 
> > to the user via ptrace(2), so this has to reflect hardware and not give a 
> > synthesized value.
> 
> Alas, I thought R2030 class FPU does not have double? Since MIPS-IV spec
> says SDC1 is introduced in MIPS II.

 There's no SDC1/LDC1, but the usual MIPS I FP machine instructions (of 
which there are fewer than in MIPS II, e.g. there's no SQRT.fmt or direct 
conversions) do support the double format/encoding.  It's just that double 
FP data has to be transferred piecemeal; other supported operations will 
execute just fine.  Otherwise the existence of the odd-numbered FPRs would 
make no sense in the first place.

 Plain single floating-point units are extremely rare, e.g. the R4650 has 
one (it does support CP0.Status.FR though, for 32 singles), and we do not 
support them (e.g. the R4650 has a simple base-bounds MMU only, no TLB).  
Another one is the R5900, but its FPU is not an IEEE 754 device even.

  Maciej
  

> 2023年5月20日 21:32，Maciej W. Rozycki <macro@orcam.me.uk> 写道：
> 
> On Fri, 19 May 2023, Jiaxun Yang wrote:
> 
>>> I guess one can do it and still run FPXX software, but I fail to see what 
>>> gain it provides.  For FP32 it breaks things as accesses to odd-numbered 
>>> FPRs will no longer get at the high part of a double value and for FP64 
>>> there are no MTHC1/MFHC1 instructions required to access the high part.
>> 
>> Actually software may access the high part by SDC1/LDC1.
> 
> I'm aware of that, but you'd need a new psABI variation really to handle 
> such an arrangement.  None of the existing FP32, FP64, FPXX handles it.
> 
>>> What problem are you trying to solve?  And how did you verify this patch?
>> 
>> Was trying to deal a proprietary JIT software who want to enable FR1 via prctl
>> on Loongson-2F with 32 bit kernel.
> 
> There may be a better way: rather than avoiding MTHC1/MFHC1, handle them 
> in the FPU emulator where unavailable in FR=1 mode while leaving the rest 
> to hardware.  That would make regular FR64 software work.
> 
> I'd expect such a JIT to have other issues with pre-R2 hardware though, 
> with missing machine instructions.  I had a similar situation a few years 
> ago with FireFox's JIT making assumptions above the MIPS ISA level the 
> piece of software was itself compiled for and opted for just disabling the 
> JIT, as fixing FireFox and rebuilding it would be more effort than it was 
> worth in my view.
> 
> This might be the best way for you to move forward too, and I'm all but 
> enthusiastic about adding a workaround in the kernel for a broken piece of 
> proprietary user software.  Sorry.

Thanks for all those information. I was just entertaining by poking around some
old software blobs from Loongson so I’d give up upstreaming those changes.

My limited test works fine with this patch though.

- Jiaxun

> 
> Also I seem to remember there was a pitfall with running 32-bit software 
> on pre-R2 hardware in the FR=1 mode, but maybe I'm making up things here.  
> It's been so long since I last looked into this.
> 
> In any case you do need to verify this somehow, like by running the math 
> part of the glibc testsuite with o32 in the FR=1 mode on pre-R2 hardware.  
> Running the GDB test suite to make sure ptrace(2) works fine with the new 
> FPU configuration would make sense too.
> 
>>> Currently all FPUs we support implement double and we require that, so no 
>>> need to make this piece conditional (I would use IS_ENABLED otherwise, so 
>>> as not to clutter the source with #ifdef), but `c->fpu_id' is also exposed 
>>> to the user via ptrace(2), so this has to reflect hardware and not give a 
>>> synthesized value.
>> 
>> Alas, I thought R2030 class FPU does not have double? Since MIPS-IV spec
>> says SDC1 is introduced in MIPS II.
> 
> There's no SDC1/LDC1, but the usual MIPS I FP machine instructions (of 
> which there are fewer than in MIPS II, e.g. there's no SQRT.fmt or direct 
> conversions) do support the double format/encoding.  It's just that double 
> FP data has to be transferred piecemeal; other supported operations will 
> execute just fine.  Otherwise the existence of the odd-numbered FPRs would 
> make no sense in the first place.
> 
> Plain single floating-point units are extremely rare, e.g. the R4650 has 
> one (it does support CP0.Status.FR though, for 32 singles), and we do not 
> support them (e.g. the R4650 has a simple base-bounds MMU only, no TLB).  
> Another one is the R5900, but its FPU is not an IEEE 754 device even.
> 
>  Maciej