Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp904128imm; Wed, 26 Sep 2018 08:33:12 -0700 (PDT) X-Google-Smtp-Source: ACcGV606TJoD8MGZro4OavUTLHGFVgPnpQ4yiBFGEusd7FCIlcLhLNEFNNZgeSVYlsRqW/bhxgvK X-Received: by 2002:a63:144b:: with SMTP id 11-v6mr6030904pgu.219.1537975992191; Wed, 26 Sep 2018 08:33:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537975992; cv=none; d=google.com; s=arc-20160816; b=G3RlkzOT+VC29JqBUa2A5Vm1wLKkWziuj9Ot08V1AgbABGfKaeRwbx09l2b3a8fT2U tLAkzKH4JMQKwYtHH6GVzqaD5yF43VgSLj5TMw9nt68xvcCpPFYGr2HH5WDMReZv/Meo LE22tFjYhPByAN7z5I2C5r98pzi3khlEPhro5ENxVmoLkI8lC8N5cffz1ww9M6Os/2s4 F6Lt5h24QxYcp62MkOsK11xIa74emiJNxJDAXyzx/G7DQUl/pUCBHG/001LQOs830NXE 0uLpYaGqEKrsx83zceDZ4eYSrRexlnD44RGs7JTQ+Txl1fvuSTXpwSa24gorkfNUkhjO VdVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=i/coV9U/5HfCv5BCZ1DzqCxRkJUcIbHQzSFlLq7q8cw=; b=Pids+67XOpyQNfWjBP/MtTQeBGiRRupF04A/tTJoi0RdMks/soZCWw2oAA0+E3afaE ZydO/PuKl6UyhuTZ9PaKmt1HnhVxK58/wTqHGNiYSBV+qOtm2l5kNZRcbVDM2zI1/XxQ RpeNu1RRdW+a33k7OuWwCP5tIKMg/mjNQCPh9m+ijb09NSHMRh7kRJ//h30K/P8SNM0o Y+SA0cvCV/vCIJ1SWKa7uBVNGcS65TGgKng/WyjmOVyfcWOiTTxVAbO6gnX0vrLxbpA1 MKPs7O7g679KzInfRD4YcWH5DUDuBY/UKJJbImtiAVB99UzeoHY6FlhtGix0arHYIhKN ucjg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g21-v6si648906plq.242.2018.09.26.08.32.56; Wed, 26 Sep 2018 08:33:12 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728233AbeIZVqL convert rfc822-to-8bit (ORCPT + 99 others); Wed, 26 Sep 2018 17:46:11 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:49899 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727250AbeIZVqL (ORCPT ); Wed, 26 Sep 2018 17:46:11 -0400 Received: from bigeasy by Galois.linutronix.de with local (Exim 4.80) (envelope-from ) id 1g5Bni-0001nJ-8c; Wed, 26 Sep 2018 17:32:30 +0200 Date: Wed, 26 Sep 2018 17:32:30 +0200 From: Sebastian Andrzej Siewior To: Bryan O'Donoghue , Denys Vlasenko , Ong@linutronix.de, Boon Leong Cc: linux-kernel@vger.kernel.org, x86@kernel.org, Andy Lutomirski , Paolo Bonzini , Radim =?utf-8?B?S3LEjW3DocWZ?= , kvm@vger.kernel.org, "Jason A. Donenfeld" , Rik van Riel , Andy Lutomirski Subject: Re: [RFC PATCH 10/10] x86/fpu: defer FPU state load until return to userspace Message-ID: <20180926153229.n5rwlfhuqu42ds6v@linutronix.de> References: <20180912133353.20595-1-bigeasy@linutronix.de> <20180912133353.20595-11-bigeasy@linutronix.de> <650FC457-7E4C-473A-9E5F-EAFC74F6444B@amacapital.net> <20180919170515.ptqmmpsxrdjsi64j@linutronix.de> <20180926111222.hihueuagmb4qfmtz@linutronix.de> <59E2EBC5-C483-4788-B490-4A3770DBB993@amacapital.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8BIT In-Reply-To: <59E2EBC5-C483-4788-B490-4A3770DBB993@amacapital.net> User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > 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. Okay. Sebastian