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
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 an
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 comme
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 automaticall
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 implementati
On Thu, 2009-06-18 at 01:06 +0800, 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
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,
* 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 available.
>
>ahash instead of shash interface is used, because some hard
* 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.
>
>Signed-off-by: Huang Ying
>
>---
> crypto/Kconfig |7 +
> c
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)
* Huang Ying wrote:
> This is used by AES-NI accelerated AES implementation and PCLMULQDQ
> accelerated GHASH implementation.
>
> Signed-off-by: Huang Ying
>
> ---
> arch/x86/crypto/aesni-intel_glue.c |7 ---
> arch/x86/include/asm/i387.h|7 +++
> 2 files changed, 7 i
11 matches
Mail list logo
