Re: [RFC PATCH 10/10] x86/fpu: defer FPU state load until return to userspace

[Andy Lutomirski <luto@amacapital.net>]

> On Sep 26, 2018, at 4:12 AM, Sebastian Andrzej Siewior <bigeasy@linutronix.de> 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.