[intel-platform-discuss] Intel Platform optimised software crypto algorithms

[Michael Corcoran]

Bill Holler's having problems sending to the alias and he has a much
more detailed reply:

> Kernel threads do not save XMM state, so disabling preemption as
> this code does is necessary.  This may not be ideal if algorithms
> that wants to store a lot of data in the 16 available 128-bit
> XMM registers for longer periods of time.
> 
> There has been some discussion in the Intel project of adding
> XMM context save to kernel threads.  Perhaps there could be
> a flag per kernel thread that specifies it is using XMM state,
> so only those threads would have their XMM context saved.
> There could also be policies regarding which priority levels
> could use the registers.  I would like to do this as part of
> the Intel platform Performance project.
> 
> What would *really* help get the above project (In Kernel
> XMM context) going is if we knew the need for this and had
> examples of algorithms that will use this feature.  IIRC
> ZFS compression/encryption, crypto, and a sound driver would
> like to use XMM register context in kernel.  We do not want
> to write these algorithms using SSE, but would like to enable
> others to.  We are hoping to receive SSE2/SSE3 code examples
> from Intel or the open source community.  Our initial
> request from Intel did not get far.
> 
> If we don't form a community for this, everyone will end
> up doing it there own way....
> 
> Regards,
> Bill

=== end of Bill's reply

On Thu, 2007-03-15 at 10:29 -0700, Michael Corcoran wrote:
> On Thu, 2007-03-15 at 17:00 +0000, Darren J Moffat wrote:
> > Sherry Moore wrote:
> > >> On Thu, Mar 15, 2007 at 01:48:53PM +0000, Darren J Moffat wrote:
> > >>> All the algorithms listed above are build for userland and kernel
> > >>> from the same algorithm source code but with slightly different
> > >>> "plumbing".
> > >> What are the restrictions on using (say) SSE instructions in the
> > >> kernel?
> > > 
> > > There aren't any kernel specific restrictions.  Just the general: the
> > > FPU has to be enabled, the processor has to support SSE.
> > 
> > So is this code we have in our bignum implementation not required ?
> > 
> I don't know this for a fact, but I thought (fuzzy memory) we didn't
> save fp registers by default on a context switch/interrupt and thus if
> you didn't disable preemption, you'd run the risk of those registers
> getting corrupted.  If we can guarantee that there will be no fp ops in
> an interrupt handler, then it probably doesn't make a difference if an
> interrupt occurs.  For userland, I think we are smarter about saving off
> the fp registers if a program is using them.
> 
> --Mike
> 
> > 
> > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/common/bignum/i386/bignum_i386_asm.s#110
> > 
> > 
--