aesni: Switch to using FPU_KERN_NOCTX.

[markj]

So the tradeoff here is that now we can end up with long critical sections. That's probably ok for in-kernel consumers since their request sizes will be fairly small. Do we have any limit on the size of requests sent via /dev/crypto?

[kib]

I believe eventually we want to be able to specify which subset of FPU state we want to use in fpu_kern_enter().

[jhb]

In D41577#947593, @markj wrote:

So the tradeoff here is that now we can end up with long critical sections. That's probably ok for in-kernel consumers since their request sizes will be fairly small. Do we have any limit on the size of requests sent via /dev/crypto?

We do, it's limited to 256k I think, but it's also little used. OpenSSL doesn't make any meaningful use of it, and for software crypto /dev/crypto doesn't make sense (and isn't enabled by default) since you are better off just using the accelerated software crypto in userland. Note that ossl(4) already uses FPU_KERN_NOCTX.

[jhb]

In D41577#947694, @kib wrote:

I believe eventually we want to be able to specify which subset of FPU state we want to use in fpu_kern_enter().

I think that will be orthogonal to FPU_KERN_NOCTX (the current manpage implies that would be part of the flags passed in)

[kib]

In D41577#947707, @jhb wrote:

In D41577#947694, @kib wrote:

I believe eventually we want to be able to specify which subset of FPU state we want to use in fpu_kern_enter().

I think that will be orthogonal to FPU_KERN_NOCTX (the current manpage implies that would be part of the flags passed in)

Initial intent was that context created would be prepared for specific extension usage, if needed. Other extension's save area could be left as default (bit set to 0 in xstate_bv).

[jhb]

In D41577#947763, @kib wrote:

In D41577#947707, @jhb wrote:

In D41577#947694, @kib wrote:

I believe eventually we want to be able to specify which subset of FPU state we want to use in fpu_kern_enter().

I think that will be orthogonal to FPU_KERN_NOCTX (the current manpage implies that would be part of the flags passed in)

Initial intent was that context created would be prepared for specific extension usage, if needed. Other extension's save area could be left as default (bit set to 0 in xstate_bv).

So I actually think what crypto drivers at least want for that might be a way to create a template context, and pass it to fpu_kern_enter, but only as a way to initialize the context, that is something like:

sc->ctx = fpu_kern_alloc_ctx(FPU_KERN_FOO);

during attach and then for each operation:

fpu_kern_enter(td, &sc->ctx, FPU_KERN_NOCTX);
...
fpu_kern_leave(td, NULL);

Where you would use the passed in context in place of fpu_initialstate when calling fpurestore() in fpu_kern_enter.

[kib]

May be, yes. This also has something to do with XSAVES which we still did not needed.