Re: [RFC 6/7] x86: Move kernel_fpu_using to asm/i387.h

2009-06-17 Thread Ingo Molnar
* Huang Ying ying.hu...@intel.com wrote: This is used by AES-NI accelerated AES implementation and PCLMULQDQ accelerated GHASH implementation. Signed-off-by: Huang Ying ying.hu...@intel.com --- arch/x86/crypto/aesni-intel_glue.c |7 --- arch/x86/include/asm/i387.h|

Re: [RFC 6/7] x86: Move kernel_fpu_using to asm/i387.h

2009-06-17 Thread H. Peter Anvin
Ingo Molnar wrote: +static inline int kernel_fpu_using(void) +{ +if (in_interrupt() !(read_cr0() X86_CR0_TS)) +return 1; +return 0; +} + Looks sane to me. Herbert, do you ack it? Although I have to say, the structure of: if (boolean test) return 1;

Re: [RFC 6/7] x86: Move kernel_fpu_using to asm/i387.h

2009-06-17 Thread Herbert Xu
On Wed, Jun 17, 2009 at 10:06:44AM -0700, H. Peter Anvin wrote: Ingo Molnar wrote: +static inline int kernel_fpu_using(void) +{ + if (in_interrupt() !(read_cr0() X86_CR0_TS)) + return 1; + return 0; +} + Looks sane to me. Herbert, do you ack it? Ack. Please

Re: [RFC 1/7] crypto: Add GHASH digest algorithm for GCM

2009-06-17 Thread Huang Ying
On Thu, 2009-06-18 at 04:04 +0800, Sebastian Andrzej Siewior wrote: * Huang Ying | 2009-06-11 15:10:26 [+0800]: GHASH is implemented as a shash algorithm. The actual implementation is copied from gcm.c. This makes it possible to add architecture/hardware accelerated GHASH implementation.

Re: [RFC 2/7] crypto: Use GHASH digest algorithm in GCM

2009-06-17 Thread Huang Ying
On Thu, 2009-06-18 at 04:47 +0800, Sebastian Andrzej Siewior wrote: * Huang Ying | 2009-06-11 15:10:28 [+0800]: Remove the dedicated GHASH implementation in GCM, and uses the GHASH digest algorithm instead. This will make GCM uses hardware accelerated GHASH implementation automatically if

Re: [RFC 1/7] crypto: Add GHASH digest algorithm for GCM

2009-06-17 Thread Herbert Xu
On Thu, Jun 18, 2009 at 10:08:27AM +0800, Huang Ying wrote: Unless I'm mistaken, this is called once on allocation and this ctx is allocated via kzalloc(). Yes. it is alloced via kzalloc. Can we just rely on this? Should we add that assumption to somewhere such as document of comments.

Re: [RFC 6/7] x86: Move kernel_fpu_using to asm/i387.h

2009-06-17 Thread H. Peter Anvin
Herbert Xu wrote: On Wed, Jun 17, 2009 at 10:06:44AM -0700, H. Peter Anvin wrote: Huang: if I recall correctly, these functions were originally designed to deal with the fact that VIA processors generate spurious #TS faults due to broken design of the Padlock instructions. The AES and

Re: [RFC 6/7] x86: Move kernel_fpu_using to asm/i387.h

2009-06-17 Thread H. Peter Anvin
Huang Ying wrote: After some thinking, I think something as follow may be more appropriate: /* This may be useful for someone else */ static inline bool fpu_using(void) { return !(read_cr0() X86_CR0_TS); } static inline bool irq_fpu_using(void) { return in_interrupt()