From:   "Bae, Chang Seok" <chang.seok.bae@intel.com>
To:     Ard Biesheuvel <ardb@kernel.org>
CC:     Eric Biggers <ebiggers@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Borislav Petkov <bp@suse.de>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        "mingo@kernel.org" <mingo@kernel.org>,
        "Lutomirski, Andy" <luto@kernel.org>,
        "x86@kernel.org" <x86@kernel.org>,
        "herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
        "Williams, Dan J" <dan.j.williams@intel.com>,
        "Gairuboyina, Charishma1" <charishma1.gairuboyina@intel.com>,
        "Dwarakanath, Kumar N" <kumar.n.dwarakanath@intel.com>,
        "Krishnakumar, Lalithambika" <lalithambika.krishnakumar@intel.com>,
        "Shankar, Ravi V" <ravi.v.shankar@intel.com>
Subject: Re: [PATCH v3 11/15] crypto: x86/aes-kl - Support AES algorithm using
 Key Locker instructions
Thread-Topic: [PATCH v3 11/15] crypto: x86/aes-kl - Support AES algorithm
 using Key Locker instructions
Thread-Index: AQHX4W/kZoA3rQNJf0mSmN0oRVVbp6wbd4YAgAA0pICACm46gIAADHwA
Date:   Mon, 6 Dec 2021 22:59:09 +0000
Message-ID: <1F509A28-1A49-4F60-9E96-B2AD9CC6E921@intel.com>
References: <20211124200700.15888-1-chang.seok.bae@intel.com>
 <20211124200700.15888-12-chang.seok.bae@intel.com>
 <YaWfKB+k66MzNtIi@sol.localdomain>
 <011B53ED-6D9E-41EB-834B-8A64485DBED5@intel.com>
 <CAMj1kXF1hoyW6fdidJ2Dt4R_qBv_QLNaowKf4LM5Oe3_zaJuTA@mail.gmail.com>
In-Reply-To: <CAMj1kXF1hoyW6fdidJ2Dt4R_qBv_QLNaowKf4LM5Oe3_zaJuTA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?kW5AqYLlIEu0Dt/kIr+C06EUHj2Q/mEI/RAWFMVSljWtTPPk246nzHOrTmWs?=
 =?us-ascii?Q?+XiDglk49d1RPbMXb4onhHd8oj7tgSW35toLggMir9Xib6sBBU87bDfGAXa5?=
 =?us-ascii?Q?PwB3gzn2ehLiJk+UbuQGYKR59Su7Ty6KkMWoHNh9Ob1dF+YCztBsfcfzYPMN?=
 =?us-ascii?Q?8UE+uXgpNJoET0gsLaK64FnZ0byqVGHWnr9tp2Vl7hkDg80i6YHszvSluM2b?=
 =?us-ascii?Q?gIUUXUQ8eb2VVvu+hq4nQT9sGXqltNH5w0WMPZUP5QPk16FeU1Mi9uq1R+dW?=
 =?us-ascii?Q?5cnilIQJqOeh7sfNPEV3du6OIF1mYvRuQM5McCWDm9vmfu2/EaaKVRIKg11f?=
 =?us-ascii?Q?DKn4v21Rr7M6AN9gmjNPqReB7QzNVMkEZgthLcJXlAl1RhY9TRkzc7yZIcI+?=
 =?us-ascii?Q?qDip43ilXIKhRNdaQlafJlAG49r5tC5FZIoL9VwmxMLvg9d+D8IxP9xBbJIB?=
 =?us-ascii?Q?UZMUiYOSv1A7/mHVtXTQcyVWyg6kRiAlV9tER0ZhEtdT/vYxZGb4uyXAi3Xj?=
 =?us-ascii?Q?MWlWGjIFhJ0nJ6rT/qde7dvWtahIUTntEwXRLi0hF/n8g8MmNGRpixMr43ka?=
 =?us-ascii?Q?ajJ2bATb5LLzYHeWqMWer7pAFF274hfZyZP/dUni3XCjFuiQiRZBg9uDSSrK?=
 =?us-ascii?Q?qmRDAyacI78ryl2j5S4h8dLHbnEGQ++YeeA+bWRvw1FHhu5MC0TEwjW7eEAQ?=
 =?us-ascii?Q?Uh/X6/L4m947RzkDX/f0/8qc1mojfCPCwcburEP9urX82wh7VDcud7Dz2IVp?=
 =?us-ascii?Q?lz88VdL++c59vKE2d9xA9QV1/iiaK93+4eZvjMCYKvfV5pcuaKp+u/YjD/Mj?=
 =?us-ascii?Q?JGP1A8lxFATBtphJeQtcGTguRHsgWlIFGMMQK7YohHrp60rLSH8+6iowylUN?=
 =?us-ascii?Q?KHyvUyp+AhMBfT8/bjtYMU/nSKMna5Im4ivz7w9DoOAtODW/pWkRtZpplEiw?=
 =?us-ascii?Q?Xq6MJ7g8lL9jZzgQFdo78efzrTvjl1vRRlOBrxmCMpNhqUrU6g9010TpibFg?=
 =?us-ascii?Q?HYUaPbY6HB1wA3oBelg71kODQk0X4maoVKA9WLb//VY39ToW90DUMJa0hmeo?=
 =?us-ascii?Q?gYjGNWttY7rG6nTyq1acxT4teXGUW2oFj1ZTC42qXwi4yl4szlO5ks3UsvLr?=
 =?us-ascii?Q?QR6h94E2+brWTzx+OPascbgacMVFN4Ryh10pujHWIfwqd9uY+CZCVO0UD0/Z?=
 =?us-ascii?Q?oJWJy8UQohZ4IyXXDnobNyQL0fSoQPNf/n8qxNkT8lCtW7kHrcMT4KDGqFQq?=
 =?us-ascii?Q?CDht1L7skMyfdxLaUXexd3xoY/5FvLwa0XaEsYyIwZFQLnUTTRtFzIGGY6BD?=
 =?us-ascii?Q?nxYUcb38akWP1k5iSxUIAghceHMiYMoWlNFZuvndVbQTXhr157y04UT+SM1M?=
 =?us-ascii?Q?E3CoTl2P2KKSJ4heVHT+1TeWv6V6i392GvFMfOfo6ka4hB54srk4Mv+dszTi?=
 =?us-ascii?Q?ySV7baC52xphFKTtHEzsv+2mMbTNrKy2FMOtShQ1/bN0Gjtb+AyqZ+qPs6YW?=
 =?us-ascii?Q?kHg3QEq0UOiOSQHykam4z3peW+vdY2OuQiBJX+SBJEWMjVK+HJ1gSzJV5zpe?=
 =?us-ascii?Q?BOyGSGYTMNLcLpHSNbea/WihGJymfF+AFgJZnFkv/lc7Mifknpl4x9LyWNk/?=
 =?us-ascii?Q?hkBpZlsLIwrMCsCnky3gCZOVtqNaWO60lLdRjSccpvSumZdd+05avz9aFrev?=
 =?us-ascii?Q?HYLLJe/9+xMIbkbYQKwuuayXur0=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <D55EC34D5B60BE4DBCAE4FB224996D41@namprd11.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4855.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 860d35c6-c846-4c52-ac0b-08d9b90c0395
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2021 22:59:09.8804
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: GgaHjpe7xmR1fzzxfGywCphy9wIyNO60x5ghMCBnlwyS3cFKvh8vpef2Fdltkn7XFt3TKXUIGIuL+9/pmuMVHgwLxqUXnSYRUthiv6fE4sk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB5863
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org

On Dec 6, 2021, at 14:14, Ard Biesheuvel <ardb@kernel.org> wrote:
> On Tue, 30 Nov 2021 at 07:57, Bae, Chang Seok <chang.seok.bae@intel.com> =
wrote:
>>=20
>>=20
>> No, these two instruction sets are separate. So I think no room to share=
 the
>> ASM code.
>=20
> On arm64, we have
>=20
> aes-ce.S, which uses AES instructions to implement the AES core transform=
s
>=20
> aes-neon.S, which uses plain NEON instructions to implement the AES
> core transforms
>=20
> aes-modes.S, which can be combined with either of the above, and
> implements the various chaining modes (ECB, CBC, CTR, XTS, and a
> helper for CMAC, CBCMAC and XMAC)
>=20
> If you have two different primitives for performing AES transforms
> (the original round by round one, and the KL one that does 10 or 14
> rounds at a time), you should still be able to reuse most of the code
> that implements the non-trivial handling of the chaining modes.

Yes, no question about this for maintainability.

However, besides the fact that a KL instruction takes multiple rounds, some
AES-KL instructions have register constraints. E.g. AESENCWIDE256KL always
uses XMM0-7 for input blocks.

Today, AES-NI code maintains 32-bit compatibility, e.g. clobbering XMM2-3 f=
or
key and input vector, so sharing the code makes the AES-KL code inefficient
and even ugly I think due to the register constraint. E.g. the AES-KL code
does use XMM9-10 for key and an input vector, but it has to move them aroun=
d
just for code sharing.

Thanks,
Chang=