Received: by 10.213.65.68 with SMTP id h4csp1587219imn; Mon, 19 Mar 2018 08:07:24 -0700 (PDT) X-Google-Smtp-Source: AG47ELsKyQwlfYoywrKgesAkgZsSwUSu7UgUHjWJ/msMlHnoGHraZRsrWkez2dpSL2I7tDVGlnGr X-Received: by 10.98.57.143 with SMTP id u15mr10520433pfj.79.1521472044569; Mon, 19 Mar 2018 08:07:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521472044; cv=none; d=google.com; s=arc-20160816; b=xyB6+FN+k8GvA2uiKPgv2vEfH5AxvHKOwuK67DuX4Lso2HQdc8d6sFHe5AX8tTxZFh JIF4JeLEfnHvez8LnHDq1AUQxXMzUpeS/ymx/JdNeUS7yWUAqQ5rDfRtz1OfQYNLYOUz X/LRg8TpEscSXGvVtfxlew+GOor139FAuKc8tkA24ogcwWJ8ULQ4eVfxlE/eNYMXbCNh PRyKXGEilHo9oWK+rZgnqc9OQR33ipAeBfo7KwJYWZQYYXIDlyIHGE/ZDjUR+CGsWGNq YwpuSclZqLK5pggV+hfAaHE9b1Ludjmh8yHtpVVqgJ3+8rv1MA+C7Ma5bVAAL5du7RF2 8nZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=s2PxPx/92Z50s/mQ0ovx9a428kDH1uVEIpIts6I5B9U=; b=LkK96OhZF8Etsuw505G80a1yDrAESEXKOZLRJjgDL623k7CZbFrMf0A1IAjFaN9OK+ DLcyFc5qFvKQd9RUicDuPOvNmz9s+r2GY6Z03giPZFt0zKIOzBZwRuGXdlejjCFM1eht QrCu5iUJXBjfnWbnu73qaLT5qn3+sIqq9JFgzEJ21iNeODkTLJztkj8Bt+TowtDoLUX2 iLcV7jGv66vY9ksA3UDS+QUBpLRM2KUlmhWqnkQPhCWbjzb6ZjoYLIk5HoF0cq2rxBs/ WubLmTe+xRvX/86KpuiEMyTFf6G1dPCa4jLe6xzvWX7WkdZDlRacebyaHAb52xNjCEAS CkVQ== 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 t9-v6si119003plq.321.2018.03.19.08.07.09; Mon, 19 Mar 2018 08:07:24 -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 S1755601AbeCSPFe (ORCPT + 99 others); Mon, 19 Mar 2018 11:05:34 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:60479 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754731AbeCSPFb (ORCPT ); Mon, 19 Mar 2018 11:05:31 -0400 Received: from hsi-kbw-5-158-153-52.hsi19.kabel-badenwuerttemberg.de ([5.158.153.52] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1exwLk-0001AC-5I; Mon, 19 Mar 2018 16:05:24 +0100 Date: Mon, 19 Mar 2018 16:05:23 +0100 (CET) From: Thomas Gleixner To: David Laight cc: 'Rahul Lakkireddy' , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "netdev@vger.kernel.org" , "mingo@redhat.com" , "hpa@zytor.com" , "davem@davemloft.net" , "akpm@linux-foundation.org" , "torvalds@linux-foundation.org" , "ganeshgr@chelsio.com" , "nirranjan@chelsio.com" , "indranil@chelsio.com" Subject: RE: [RFC PATCH 0/3] kernel: add support for 256-bit IO access In-Reply-To: <7f0ddb3678814c7bab180714437795e0@AcuMS.aculab.com> Message-ID: References: <7f0ddb3678814c7bab180714437795e0@AcuMS.aculab.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 19 Mar 2018, David Laight wrote: > From: Rahul Lakkireddy > In principle it ought to be possible to get access to one or two > (eg) AVX registers by saving them to stack and telling the fpu > save code where you've put them. No. We have functions for this and we are not adding new ad hoc magic. > OTOH, for x86, if the code always runs in process context (eg from a > system call) then, since the ABI defines them all as caller-saved > the AVX(2) registers, it is only necessary to ensure that the current > FPU registers belong to the current process once. > The registers can be set to zero by an 'invalidate' instruction on > system call entry (hope this is done) and after use. Why would a system call touch the FPU registers? The kernel normally does not use FPU instructions and the code which explicitely does has to take care of save/restore. It would be performance madness to fiddle with the FPU stuff unconditionally if nothing uses it. Thanks, tglx