Re: [PATCH V3 1/2] MIPS: Loongson-3: Enable COP2 usage in kernel

[Jiaxun Yang <jiaxun.yang@flygoat.com>]

在 2020/8/7 下午9:25, Jiaxun Yang 写道:
>
>
> 在 2020/8/7 21:13, Thomas Bogendoerfer 写道:
>> On Wed, Aug 05, 2020 at 09:51:44PM +0800, Jiaxun Yang wrote:
>>>> yes there is. Since this COP2 is a total black box to me, it would be
>>>> really helpfull to get some docs for it or at least some 
>>>> information what
>>>> it exactly does and how you want to use it in kernel code.
>>> FYI:
>>> Loongson doesn't have any CU2 register. It just reused LWC2 & LDC2 
>>> opcode
>>> to define some load & store instructions (e.g. 128bit load to two 
>>> GPRs).
>>>
>>> I have a collection of these instructions here[1].
>>>
>>>  From GS464E (3A2000+), execuating these instruction won't produce COP2
>>> unusable
>>> exception. But older Loongson cores (GS464) will still produce COP2
>>> exception, thus
>>> we should have CU2 enabled in kernel. That would allow us use to these
>>> instructions
>>> to optimize kernel.
>> thank you that makes things a little bit clearer.
>>
>> How will this be used in kernel code ? Special assembler routines or
>> by enabling gcc options ?
>
> Via special assembly routines, as -msoft-float will disable generation of
> these instructions in GCC.
>
> I knew Huacai have out-of-tree memcpy optimization and Xuerui have
> RAID5 optimiztion with these instructions.
>
>>
>>>> And finally what I stil don't like is the splittering of more
>>>> #ifdef LOONGSON into common code. I'd prefer a more generic way
>>>> to enable COPx for in kernel usage. Maybe a more generic config option
>>>> or a dynamic solution like the one for user land.
>>> Agreed. some Kconfig options or cpuinfo_mips.options can be helpful.
>> let's see whether this really is needed.
>>
>> To me it looks like the COP2 exception support for loongson makes
>> thing worse than it helps. How about the patch below ? There is still
>> a gap between starting the kernel and COP2 enabled for which I'm not
>> sure, if we are hitting COP2 instructions.
>

I had a off-list discussion with Huacai and found it's not the case.

Some Loongson CU2 instructions (e.g. GSLQC1) uses FPU registers, and now 
we're uncoditionally
let the thread own FPU in cop2-ex handler when CU2 exception triggered.
However, if we enable CU2 all the time, than the FPU context of these 
instructions might be lost.
(Yes, these instructions won't generate CU1 unusable exception when CU2 
is enabled but not CU1,
it is likely to be a design fault.)

Thus we still need to enable CU2 with exception for user space, and we 
can always enable CU2 in
kernel since kernel won't be compiled with hard-float. :-)

Thanks.

- Jiaxun