Re: [PATCH 2/3] x86_64: Define 128-bit memory-mapped I/O operations

From: Ben Hutchings <redacted>
Date: Wed, 22 Aug 2012 03:04:11 +0100

On Tue, 2012-08-21 at 18:37 -0700, H. Peter Anvin wrote:

quoted

On 08/21/2012 06:23 PM, Ben Hutchings wrote:

quoted

Define reado(), writeo() and their raw counterparts using SSE.

Based on work by Stuart Hodgson [off-list ref].

It would be vastly better if we explicitly controlled this with
kernel_fpu_begin()/kernel_fpu_end() rather than hiding it in primitives
than might tempt the user to do very much the wrong thing.

Also, it needs to be extremely clear to the user that these operations
use the FPU, and all the requirements there need to be met, including
not using them at interrupt time.

Well we can sometimes use the FPU state at IRQ time, can't we
(irq_fpu_usable())?   So we might need, say, try_reado() and
try_writeo() with callers expected to fall back to alternatives.  (Which
they must have anyway for any architecture that doesn't support this.)

I really hope we eventually get rid of this rediculous restriction the
x86 code has.

It really needs a proper stack of FPU state saves like sparc64 has.

Half of the code and complexity in arch/x86/crypto/ would just
disappear, because most of it has to do with handling this obtuse
FPU usage restriction which shouldn't even be an issue in the first
place.

I continually see more and more code that has to check this
irq_fpu_usable() thing, and have ugly fallback code, and therefore is
a sign that this really needs to be fixed properly.