linux-kernel - Re: PPC_FPU, ALTIVEC: enable_kernel_fp, put_vr, get

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 19 Apr 2021 23:16:18 +1000
From:   Michael Ellerman <mpe@...erman.id.au>
To:     Randy Dunlap <rdunlap@...radead.org>,
        Segher Boessenkool <segher@...nel.crashing.org>,
        Christophe Leroy <christophe.leroy@...roup.eu>
Cc:     PowerPC <linuxppc-dev@...ts.ozlabs.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: PPC_FPU, ALTIVEC: enable_kernel_fp, put_vr, get_vr

Randy Dunlap <rdunlap@...radead.org> writes:
> On 4/18/21 10:46 AM, Segher Boessenkool wrote:
>> On Sun, Apr 18, 2021 at 06:24:29PM +0200, Christophe Leroy wrote:
>>> Le 17/04/2021 à 22:17, Randy Dunlap a écrit :
>>>> Should the code + Kconfigs/Makefiles handle that kind of
>>>> kernel config or should ALTIVEC always mean PPC_FPU as well?
>>>
>>> As far as I understand, Altivec is completely independant of FPU in Theory. 
>> 
>> And, as far as the hardware is concerned, in practice as well.
>> 
>>> So it should be possible to use Altivec without using FPU.
>> 
>> Yup.
>> 
>>> However, until recently, it was not possible to de-activate FPU support on 
>>> book3s/32. I made it possible in order to reduce unneccessary processing on 
>>> processors like the 832x that has no FPU.
>> 
>> The processor has to implement FP to be compliant to any version of
>> PowerPC, as far as I know?  So that is all done by emulation, including
>> all the registers?  Wow painful.
>> 
>>> As far as I can see in cputable.h/.c, 832x is the only book3s/32 without 
>>> FPU, and it doesn't have ALTIVEC either.
>> 
>> 602 doesn't have double-precision hardware, also no 64-bit FP registers.
>> But that CPU was never any widely used :-)
>> 
>>> So we can in the future ensure that Altivec can be used without FPU 
>>> support, but for the time being I think it is OK to force selection of FPU 
>>> when selecting ALTIVEC in order to avoid build failures.
>> 
>> It is useful to allow MSR[VEC,FP]=1,0 but yeah there are no CPUs that
>> have VMX (aka AltiVec) but that do not have FP.  I don't see how making
>> that artificial dependency buys anything, but maybe it does?
>> 
>>>> I have patches to fix the build errors with the config as
>>>> reported but I don't know if that's the right thing to do...
>> 
>> Neither do we, we cannot see those patches :-)
>
> Sure.  I'll post them later today.
> They keep FPU and ALTIVEC as independent (build) features.

Those patches look OK.

But I don't think it makes sense to support that configuration, FPU=n
ALTVEC=y. No one is ever going to make a CPU like that. We have enough
testing surface due to configuration options, without adding artificial
combinations that no one is ever going to use.

IMHO :)

So I'd rather we just make ALTIVEC depend on FPU.

cheers