Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (1.0)
Subject: Re: [RFC PATCH 10/10] x86/fpu: defer FPU state load until return to userspace
From:   Andy Lutomirski <luto@amacapital.net>
In-Reply-To: <20180926111222.hihueuagmb4qfmtz@linutronix.de>
Date:   Wed, 26 Sep 2018 07:34:09 -0700
Cc:     linux-kernel@vger.kernel.org, x86@kernel.org,
        Andy Lutomirski <luto@kernel.org>,
        Paolo Bonzini <pbonzini@redhat.com>,
        =?utf-8?Q?Radim_Kr=C4=8Dm=C3=A1=C5=99?= <rkrcmar@redhat.com>,
        kvm@vger.kernel.org, "Jason A. Donenfeld" <Jason@zx2c4.com>,
        Rik van Riel <riel@surriel.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <59E2EBC5-C483-4788-B490-4A3770DBB993@amacapital.net>
References: <20180912133353.20595-1-bigeasy@linutronix.de> <20180912133353.20595-11-bigeasy@linutronix.de> <650FC457-7E4C-473A-9E5F-EAFC74F6444B@amacapital.net> <20180919170515.ptqmmpsxrdjsi64j@linutronix.de> <D5D1FB08-9CE8-498B-9636-C0390153814A@amacapital.net> <A5B266A3-1EF7-44A4-9AAF-1AA1858CEFCF@amacapital.net> <20180926111222.hihueuagmb4qfmtz@linutronix.de>
To:     Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Sep 26, 2018, at 4:12 AM, Sebastian Andrzej Siewior <bigeasy@linutronix=
.de> wrote:
>=20
> 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 =E2=80=94 setting it to false lets us switch to a kernel thr=
ead and back without saving and restoring. But TIF_LOAD_FPU should be able t=
o replace it: when we have FPU regs loaded and we switch to *any* thread, ke=
rnel or otherwise, we can set TIF_LOAD_FPU and leave the old regs loaded.  S=
o we don=E2=80=99t need the special case for kernel threads.
>>>=20
>>> Which reminds me: if you haven=E2=80=99t already done so, can you add a h=
elper to sanity check the current context?  It should check that the combina=
tion 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_FP=
U is clear, it should warn.  I think that at least switch_fpu_finish should c=
all it.  Arguably switch_fpu_prepare should too, at the beginning.
>>=20
>> Looking some more, the =E2=80=9Cpreload=E2=80=9D variable needs to go awa=
y or be renamed. It hasn=E2=80=99t had anything to do with preloading for so=
me time.
> okay.
>=20
>> Also, the interaction between TIF_LOAD_FPU and FPU emulation needs to be d=
ocumented somewhere.  Probably FPU-less systems should never have TIF_LOAD_FP=
U set.
> Yes, they should not.
>=20
>> Or we could decide that no one uses FPU emulation any more.
>=20
> 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) an=
d does
> | not support x87 FPU instructions
>=20
> 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
>=20
> 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_MA=
TH_EMULATION is not set
>=20
> 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.
>=20
> 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=E2=80=99t think you can boot a kernel without math emulation on a no-FP=
U CPU. So maybe we should table this particular idea.  I didn=E2=80=99t real=
ize there were Quark CPUs without FPU.