Add support to Intel AES-NI instructions for x86_64 platform.
Intel AES-NI is a new set of Single Instruction Multiple Data (SIMD)
instructions that are going to be introduced in the next generation of
Intel processor, as of 2009. These instructions enable fast and secure
data encryption and decry
* Huang Ying | 2008-12-12 12:08:46 [+0800]:
>Add support to Intel AES-NI instructions for x86_64 platform.
>
>Intel AES-NI is a new set of Single Instruction Multiple Data (SIMD)
>instructions that are going to be introduced in the next generation of
>Intel processor, as of 2009. These instruction
On Sat, 2008-12-13 at 03:57 +0800, Sebastian Andrzej Siewior wrote:
> * Huang Ying | 2008-12-12 12:08:46 [+0800]:
>
> >Add support to Intel AES-NI instructions for x86_64 platform.
> >
> >Intel AES-NI is a new set of Single Instruction Multiple Data (SIMD)
> >instructions that are going to be intr
On Mon, Dec 15, 2008 at 10:19:02AM +0800, Huang Ying wrote:
>
> The general x86 implementation is used as the fall back for new AES-NI
> based implementation. Because AES-NI can not be used in kernel soft_irq
> context. If crypto layer is used to access general x86 implementation,
Why is that? Th
On Mon, 2008-12-15 at 11:38 +0800, Herbert Xu wrote:
> On Mon, Dec 15, 2008 at 10:19:02AM +0800, Huang Ying wrote:
> >
> > The general x86 implementation is used as the fall back for new AES-NI
> > based implementation. Because AES-NI can not be used in kernel soft_irq
> > context. If crypto layer
On Mon, Dec 15, 2008 at 01:14:59PM +0800, Huang Ying wrote:
>
> The PadLock instructions don't use/touch SSE registers, but might cause
> DNA fault when CR0.TS is set. So it is sufficient just to clear CR0.TS
> before executed.
>
> The AES-NI instructions do use SSE registers. Considering the fol
On Mon, 2008-12-15 at 13:21 +0800, Herbert Xu wrote:
> On Mon, Dec 15, 2008 at 01:14:59PM +0800, Huang Ying wrote:
> >
> > The PadLock instructions don't use/touch SSE registers, but might cause
> > DNA fault when CR0.TS is set. So it is sufficient just to clear CR0.TS
> > before executed.
> >
>
* Huang Ying | 2008-12-15 10:19:02 [+0800]:
>> Nice work. A few things:
>> - Did you rename the "old" x86 functions to avoid a clash?
>> So you bypass the crypto layer in case you can't handle the operation.
>> Does this improve the performace or just saves key strokes? Not sure
>> what the
On Mon, Dec 15, 2008 at 10:07:45AM +0100, Sebastian Andrzej Siewior wrote:
>
> You have to it if you want to bypass the crypto layer and call asm
> functions directly and I'm not sure whether bypassing the crypto layer
> is a good thing. Both asm routines (the 32bit and 64bit) assume that
> keylen
On Mon, Dec 15, 2008 at 04:21:06PM +1100, Herbert Xu wrote:
>
> > a. Do not touch SSE state in soft_irq
> > b. Disable/restore soft_irq in kernel_fpu_begin/kernel_fpu_end
> > c. Use a per-CPU data structure to save kernel FPU state during
> > soft_irq.
> >
> > The mothod a is used in patch.
>
> C
On Sun, Dec 14, 2008 at 07:38:42PM -0800, Herbert Xu wrote:
> On Mon, Dec 15, 2008 at 10:19:02AM +0800, Huang Ying wrote:
> >
> > The general x86 implementation is used as the fall back for new AES-NI
> > based implementation. Because AES-NI can not be used in kernel soft_irq
> > context. If crypto
On Mon, Dec 15, 2008 at 11:38:01PM +1100, Herbert Xu wrote:
> On Mon, Dec 15, 2008 at 04:21:06PM +1100, Herbert Xu wrote:
> >
> > > a. Do not touch SSE state in soft_irq
> > > b. Disable/restore soft_irq in kernel_fpu_begin/kernel_fpu_end
> > > c. Use a per-CPU data structure to save kernel FPU sta
On Wed, 2008-12-17 at 07:31 +0800, Herbert Xu wrote:
> On Mon, Dec 15, 2008 at 11:38:01PM +1100, Herbert Xu wrote:
> > On Mon, Dec 15, 2008 at 04:21:06PM +1100, Herbert Xu wrote:
> > >
> > > > a. Do not touch SSE state in soft_irq
> > > > b. Disable/restore soft_irq in kernel_fpu_begin/kernel_fpu_e
Huang Ying wrote:
>
> f. if TS is clear, then use x86_64 implementation. Otherwise if
> user-space has touched the FPU, we save the state, if not then simply
> clear TS.
Well I'd rather avoid using the x86_64 implementation ever because
unless the chip guys have really screwed up we should be loo
On Wed, 2008-12-17 at 09:26 +0800, Herbert Xu wrote:
> Huang Ying wrote:
> >
> > f. if TS is clear, then use x86_64 implementation. Otherwise if
> > user-space has touched the FPU, we save the state, if not then simply
> > clear TS.
>
> Well I'd rather avoid using the x86_64 implementation ever b
On Wed, Dec 17, 2008 at 11:33:39AM +0800, Huang Ying wrote:
>
> - Now an AES core block algorithm is implemented with AES-NI as
> CRYPTO_ALG_TYPE_CIPHER, which can benefit all modes (CBC, LRW, etc). But
> because it seems that there is no asynchronous interface for
> CRYPTO_ALG_TYPE_CIPHER, the AE
16 matches
Mail list logo
