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: <20180926153229.n5rwlfhuqu42ds6v@linutronix.de>
Date:   Wed, 26 Sep 2018 09:24:38 -0700
Cc:     Bryan O'Donoghue <pure.logic@nexus-software.ie>,
        Denys Vlasenko <dvlasenk@redhat.com>, Ong@linutronix.de,
        Boon Leong <boon.leong.ong@intel.com>,
        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: <176B4B39-6471-401C-A1E1-4B6B3FF157C3@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> <59E2EBC5-C483-4788-B490-4A3770DBB993@amacapital.net> <20180926153229.n5rwlfhuqu42ds6v@linutronix.de>
To:     Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Sep 26, 2018, at 8:32 AM, Sebastian Andrzej Siewior <bigeasy@linutronix=
.de> wrote:
>=20
> On 2018-09-26 07:34:09 [-0700], Andy Lutomirski wrote:
>>> 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?
>=20
> Bryan, Denys, does anyone of you rely on CONFIG_MATH_EMULATION?
> The manual for Quark claims that the CPU has no FPU and yet the current
> kernel (or the yocto v3.14) does not select this option.
> Denys added support for some opcodes in 2015 but I didn't figure out
> *why* or which CPU in particular requires this.

Certainly the early Quark CPUs were, um, crappy. They had so many terrifying=
 errata that I=E2=80=99m surprised anyone is willing to use them.

I would *hope* that all supported Quark CPUs support FPU instructions even i=
f they=E2=80=99re microcoded and run extremely slowly.