[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <176B4B39-6471-401C-A1E1-4B6B3FF157C3@amacapital.net>
Date: Wed, 26 Sep 2018 09:24:38 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: Bryan O'Donoghue <pure.logic@...us-software.ie>,
Denys Vlasenko <dvlasenk@...hat.com>, Ong@...utronix.de,
Boon Leong <boon.leong.ong@...el.com>,
linux-kernel@...r.kernel.org, x86@...nel.org,
Andy Lutomirski <luto@...nel.org>,
Paolo Bonzini <pbonzini@...hat.com>,
Radim Krčmář <rkrcmar@...hat.com>,
kvm@...r.kernel.org, "Jason A. Donenfeld" <Jason@...c4.com>,
Rik van Riel <riel@...riel.com>
Subject: Re: [RFC PATCH 10/10] x86/fpu: defer FPU state load until return to userspace
> On Sep 26, 2018, at 8:32 AM, Sebastian Andrzej Siewior <bigeasy@...utronix.de> wrote:
>
> 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?
>
> 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’m surprised anyone is willing to use them.
I would *hope* that all supported Quark CPUs support FPU instructions even if they’re microcoded and run extremely slowly.
Powered by blists - more mailing lists