From: David Laight <David.Laight@ACULAB.COM>
To: "'Thomas Gleixner'" <tglx@linutronix.de>
Cc: "'Rahul Lakkireddy'" <rahul.lakkireddy@chelsio.com>,
"x86@kernel.org" <x86@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"hpa@zytor.com" <hpa@zytor.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
"ganeshgr@chelsio.com" <ganeshgr@chelsio.com>,
"nirranjan@chelsio.com" <nirranjan@chelsio.com>,
"indranil@chelsio.com" <indranil@chelsio.com>
Subject: RE: [RFC PATCH 0/3] kernel: add support for 256-bit IO access
Date: Mon, 19 Mar 2018 15:53:00 +0000 [thread overview]
Message-ID: <ba8ac1f8c1f444da857b6a46c4153672@AcuMS.aculab.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1803191625080.2010@nanos.tec.linutronix.de>
From: Thomas Gleixner
> Sent: 19 March 2018 15:37
...
> > If system call entry reset the AVX registers then any FP save/restore
> > would be faster because the AVX registers wouldn't need to be saved
> > (and the cpu won't save them).
> > I believe the instruction to reset the AVX registers is fast.
> > The AVX registers only ever need saving if the process enters the
> > kernel through an interrupt.
>
> Wrong. The x8664 ABI clearly states:
>
> Linux Kernel code is not allowed to change the x87 and SSE units. If
> those are changed by kernel code, they have to be restored properly
> before sleeping or leav- ing the kernel.
>
> That means the syscall interface relies on FPU state being not changed by
> the kernel. So if you want to clear AVX on syscall entry you need to save
> it first and then restore before returning. That would be a huge
> performance hit.
The x87 and SSE registers can't be changed - they can contain callee-saved
registers.
But (IIRC) the AVX and AVX2 registers are all caller-saved.
So the system call entry stub functions are allowed to change them.
Which means that the syscall entry code can also change them.
Of course it must not leak kernel values back to userspace.
It is a few years since I looked at the AVX and fpu save code.
David
next prev parent reply other threads:[~2018-03-19 15:52 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-19 14:20 Rahul Lakkireddy
2018-03-19 14:20 ` [RFC PATCH 1/3] include/linux: add 256-bit IO accessors Rahul Lakkireddy
2018-03-19 14:20 ` [RFC PATCH 2/3] x86/io: implement 256-bit IO read and write Rahul Lakkireddy
2018-03-19 14:43 ` Thomas Gleixner
2018-03-20 13:32 ` Rahul Lakkireddy
2018-03-20 13:44 ` Andy Shevchenko
2018-03-21 12:27 ` Rahul Lakkireddy
2018-03-20 14:40 ` David Laight
2018-03-21 12:28 ` Rahul Lakkireddy
2018-03-20 14:42 ` Alexander Duyck
2018-03-21 12:28 ` Rahul Lakkireddy
2018-03-22 1:26 ` Linus Torvalds
2018-03-22 10:48 ` David Laight
2018-03-22 17:16 ` Linus Torvalds
2018-03-19 14:20 ` [RFC PATCH 3/3] cxgb4: read on-chip memory 256-bits at a time Rahul Lakkireddy
2018-03-19 14:53 ` [RFC PATCH 0/3] kernel: add support for 256-bit IO access David Laight
2018-03-19 15:05 ` Thomas Gleixner
2018-03-19 15:19 ` David Laight
2018-03-19 15:37 ` Thomas Gleixner
2018-03-19 15:53 ` David Laight [this message]
2018-03-19 16:29 ` Linus Torvalds
2018-03-20 8:26 ` Ingo Molnar
2018-03-20 8:38 ` Thomas Gleixner
2018-03-20 9:08 ` Ingo Molnar
2018-03-20 9:41 ` Thomas Gleixner
2018-03-20 9:59 ` David Laight
2018-03-20 10:54 ` Ingo Molnar
2018-03-20 13:30 ` David Laight
2018-04-03 8:49 ` Pavel Machek
2018-04-03 10:36 ` Ingo Molnar
2018-03-20 14:57 ` Andy Lutomirski
2018-03-20 15:10 ` David Laight
2018-03-21 0:39 ` Andy Lutomirski
2018-03-20 18:01 ` Linus Torvalds
2018-03-21 6:32 ` Ingo Molnar
2018-03-21 15:45 ` Andy Lutomirski
2018-03-22 9:36 ` Ingo Molnar
2018-03-21 7:46 ` Ingo Molnar
2018-03-21 18:15 ` Linus Torvalds
2018-03-22 9:33 ` Ingo Molnar
2018-03-22 17:40 ` Alexei Starovoitov
2018-03-22 17:44 ` Andy Lutomirski
2018-03-22 10:35 ` David Laight
2018-03-22 12:48 ` David Laight
2018-03-22 17:07 ` Linus Torvalds
2018-03-19 15:27 ` Christoph Hellwig
2018-03-20 13:45 ` Rahul Lakkireddy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ba8ac1f8c1f444da857b6a46c4153672@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=ganeshgr@chelsio.com \
--cc=hpa@zytor.com \
--cc=indranil@chelsio.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=nirranjan@chelsio.com \
--cc=rahul.lakkireddy@chelsio.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®