> On Sep 26, 2018, at 4:12 AM, Sebastian Andrzej Siewior
> <[email protected]> wrote:
>
> On 2018-09-20 21:15:35 [-0700], Andy Lutomirski wrote:
>>> I mean the fpu.initialized variable entirely. AFAIK, its only use is for
>>> kernel threads — setting it to false lets us switch to a kernel thread and
>>> back without saving and restoring. But TIF_LOAD_FPU should be able to
>>> replace it: when we have FPU regs loaded and we switch to *any* thread,
>>> kernel or otherwise, we can set TIF_LOAD_FPU and leave the old regs loaded.
>>> So we don’t need the special case for kernel threads.
>>>
>>> Which reminds me: if you haven’t already done so, can you add a helper to
>>> sanity check the current context? It should check that the combination of
>>> owner_ctx, last_cpu, and TIF_LOAD_FPU is sane. For example, if owner_ctx or
>>> last_cpu is says the cpu regs are invalid for current but TIF_LOAD_FPU is
>>> clear, it should warn. I think that at least switch_fpu_finish should call
>>> it. Arguably switch_fpu_prepare should too, at the beginning.
>>
>> Looking some more, the “preload” variable needs to go away or be renamed. It
>> hasn’t had anything to do with preloading for some time.
> okay.
>
>> Also, the interaction between TIF_LOAD_FPU and FPU emulation needs to be
>> documented somewhere. Probably FPU-less systems should never have
>> TIF_LOAD_FPU set.
> Yes, they should not.
>
>> Or we could decide that no one uses FPU emulation any more.
>
> Oh. Removing unused code? I'm all yours.
> There is this Intel Quark thingy which comes to mind can still be
> bought. Its data sheet[0] has this:
> | 13.1 Features:
> | Note: The processor does not provide an x87 Floating Point Unit (FPU) and
> does
> | not support x87 FPU instructions
>
> so not only it does not support the lock prefix, no, it also relies on
> soft-FPU.
> The latest bsp release notes quotes a package named
> quark_linux_v3.14+v1.2.1.1.tar.gz
>
> so they still use v3.14 (which is not a supported kernel anymore).
> And then I took a look into their Yocto-BSP and found this:
> | $ fgrep -R MATH_EMULATION .
> | ./meta-intel-quark/recipes-kernel/linux/files/quark_3.14.cfg:#
> CONFIG_MATH_EMULATION is not set
>
> so they don't set this option. This is small SoC and does not run on any
> Distro due to the missing lock prefix. So if they use yocto to recompile
> everything, they can rebuild their toolchain with soft-fpu support which
> is more efficient than calling into the kernel for every opcode.
>
> So I *think* nobody relies on FPU-emulation anymore. I would suggest to
> get this patch set into shape and then getting rid of
> CONFIG_MATH_EMULATION?
I don’t think you can boot a kernel without math emulation on a no-FPU CPU. So
maybe we should table this particular idea. I didn’t realize there were Quark
CPUs without FPU.
