Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752357AbYLOFPT (ORCPT ); Mon, 15 Dec 2008 00:15:19 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750823AbYLOFPF (ORCPT ); Mon, 15 Dec 2008 00:15:05 -0500 Received: from mga02.intel.com ([134.134.136.20]:16445 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750746AbYLOFPD (ORCPT ); Mon, 15 Dec 2008 00:15:03 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.36,221,1228118400"; d="asc'?scan'208";a="370874642" Subject: Re: [RFC PATCH crypto] AES: Add support to Intel AES-NI instructions From: Huang Ying To: Herbert Xu Cc: "Siddha, Suresh B" , Sebastian Andrzej Siewior , "akpm@linux-foundation.org" , "linux-kernel@vger.kernel.org" , "linux-crypto@vger.kernel.org" , "mingo@elte.hu" , "tglx@linutronix.de" In-Reply-To: <20081215033842.GA28499@gondor.apana.org.au> References: <1229054926.5936.160.camel@yhuang-dev.sh.intel.com> <20081212195722.GA24489@Chamillionaire.breakpoint.cc> <1229307542.5936.204.camel@yhuang-dev.sh.intel.com> <20081215033842.GA28499@gondor.apana.org.au> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-3knk14zbL8iGHq744xav" Date: Mon, 15 Dec 2008 13:14:59 +0800 Message-Id: <1229318099.5936.224.camel@yhuang-dev.sh.intel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2073 Lines: 62 --=-3knk14zbL8iGHq744xav Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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: > >=20 > > 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, >=20 > Why is that? The VIA PadLock also "touches" the SSE state but we still > use it on softirq paths. >=20 > In fact Suresh told me earlier that your AES instruction wasn't > going to have the SSE problems that VIA had, is this not the case? 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 following situation: 1. In kernel, code path using SSE registers are executed, user space SSE state is saved if necessary. 2. An interrupt/soft_irq comes, and encrypt/decrypt with AES-NI is executed. The SSE state of code path 1 is destroyed. To solve the above issue, the following methods can be used: 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. Best Regards, Huang Ying --=-3knk14zbL8iGHq744xav Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAklF59EACgkQKhFGF+eHlpgjVQCgmjx4n+Vqzx/CO7UJeiSBqp3k X3MAniUEuXswKYo2uRjLE1P1K+QMU2YD =xQ4I -----END PGP SIGNATURE----- --=-3knk14zbL8iGHq744xav-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/