Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   "Elliott, Robert (Servers)" <elliott@hpe.com>
To:     Herbert Xu <herbert@gondor.apana.org.au>
CC:     "tim.c.chen@linux.intel.com" <tim.c.chen@linux.intel.com>,
        "davem@davemloft.net" <davem@davemloft.net>,
        "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
        "mingo@redhat.com" <mingo@redhat.com>,
        "bp@alien8.de" <bp@alien8.de>,
        "dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
        "x86@kernel.org" <x86@kernel.org>,
        "Kani, Toshi" <toshi.kani@hpe.com>,
        "Wright, Randy (HPE Servers Linux)" <rwright@hpe.com>
Subject: RE: [PATCH] crypto: x86/sha512 - load based on CPU features
Thread-Topic: [PATCH] crypto: x86/sha512 - load based on CPU features
Thread-Index: AQHYr2k4ae1ddXSOmky6WV6b3Lh2Q622GE6AgAC77WA=
Date:   Fri, 19 Aug 2022 22:36:53 +0000
Message-ID: <MW5PR84MB18425E5211BD4EAF09D0CE3EAB6C9@MW5PR84MB1842.NAMPRD84.PROD.OUTLOOK.COM>
References: <20220813230431.2666-1-elliott@hpe.com>
 <Yv9ubekvQiL3UGwd@gondor.apana.org.au>
In-Reply-To: <Yv9ubekvQiL3UGwd@gondor.apana.org.au>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?l5RphB/xp73AKYz/K6aUM7VMpMCwqBmb1YRTHsD1AXerBQbxkE7Hc9qRj4Q6?=
 =?us-ascii?Q?FpTHTlovYFbvXr0D/AYb1AGT372fgZn874t0kqHPUAIG1TNgqTjpqMpZ1IrN?=
 =?us-ascii?Q?dZ2sD0CDLRThNFQVYddLns7l0wtcmiXGpbLKtDTRv5YZTUWmImHoar8jN/BW?=
 =?us-ascii?Q?oGOcEJIR4tHcuKGo3jUlx6hdRzN0jpzjnR4bI8ouFN+Er+xmLXU9lzCUvpoC?=
 =?us-ascii?Q?xVMX7PHOajs0rigTJxsnCdiQ07uUeWxDOQviGz3ezIuX+t1Nw8ALs3+E6iyW?=
 =?us-ascii?Q?t8+2vpoATKIkt+m4iTAiQpYpzc99D12Ui7d9uLsR4Gt5SAkgiqVXQ5mk2OUY?=
 =?us-ascii?Q?Gzk45PL8rLVBk4CKoG9rkhHqlwap6Gq6u2kxdkQRHsvJG7CLxI/LGj0/utLM?=
 =?us-ascii?Q?2v2//GaSe74G6PypcALG7+NWJEvEevAOLtSr5xdszMZBvTvCu5P6c0kFXBXp?=
 =?us-ascii?Q?VVGydL0M5YyW80d3oR3bu+TY71qYOSu8dp5mdhfGQ1OiBJxwWZNSyEWQKIs6?=
 =?us-ascii?Q?cZUPnlmn1GZnGDiBwmq6xARmMv97967+ngC0wTWTHV+R4uNC4jJdtfLWmF9E?=
 =?us-ascii?Q?M4F5uv15HeIM/92c352rg4OJU+HM8zwrI3p66+mcrAhjm7JUSrGEy+yFflqU?=
 =?us-ascii?Q?gGezr2IxT/CzJg7Fn9Baxq3w+yTctLGZ5snocYPAdeJPd/GvqpB1qZuwoOwK?=
 =?us-ascii?Q?jSyoNDzieM5KCKcYXgLddILC0SZF+OLNYNUhSUhrJUy7dV+WjSbaUXfTLZYE?=
 =?us-ascii?Q?AlmvD6Qh2WMTYzDTJJMcyXWqzTOU9+SFQ9yvnwbSmNShtVEm/cRs/KAEAaH1?=
 =?us-ascii?Q?ZLcktHUqLHUzHl5jnuclo40DAGCFwds+aH7ZsQcbKS6OyHd1ZKXUF6GptfyD?=
 =?us-ascii?Q?cL01LNgf7+6n6FPLIoqDNJSSEkiZ1UvztXho4Rr7eKTh5nH7AXeQ+7X1ei6n?=
 =?us-ascii?Q?Ef+a//dtBQcYjbvaQ2Ifr1/J/5h0ZRpUXTwU6odZm1bJzJGuzNta1qaCpNmB?=
 =?us-ascii?Q?aYGWcNGY2HTVmq5/jBOcKETHIfc+UuoF0JtNTrjQAWK9/B2H35oP2sFFvpN4?=
 =?us-ascii?Q?E4Zlu48mb9+bbloXrmSc1GGqvqjve+PAOzwABJonlQI1qlpgnB0zJU515Mij?=
 =?us-ascii?Q?Wi7qQL/1fAKik80LUQIgI7/mXysDtx3+5MEYtXzNU7IOzsJQLVAxgzQI6Fi2?=
 =?us-ascii?Q?d/kfx+ARsTcxPzQgrfKR/wOEW67EkovwcxHnkGTXuclx9L21nWLgKl3/TjOy?=
 =?us-ascii?Q?Eqh48AKhtBU1kuvJia+IAlfWC0IOTOBRcRRhChi1GuBnLxQJhKKMB1mxkmXS?=
 =?us-ascii?Q?dbRKS51kMYfm9if/BZCS+DebpjA3KE9DJrpexGeb8fA9QVNREyZ+Vv/Dwz0w?=
 =?us-ascii?Q?POvlEGjte0TQWbcC4HOlsGS76q/N3Rrsn5AXUbsgdb+ovepnTEpdo1UjvP8+?=
 =?us-ascii?Q?dzgTN0Y5Qprx+1KlmJje/2LrwNhQVe0JiZn4uGyr4/6DAIOC4vAwbGFfOht8?=
 =?us-ascii?Q?Fmuyu2l2Oo/GwdyRzpUOUlRXFZ10D1Ego6bEtozWJ+EoJilLQgwP9XygjRRC?=
 =?us-ascii?Q?Ghc3poc1t0ekZG5dqkM=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MW5PR84MB1842.NAMPRD84.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 7b08550b-60cb-420f-5acc-08da823350fe
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2022 22:36:53.9667
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: lYpbWojVasK2JA1qxFkQZZdo/gqBfnAxWBD6yJdVNRzyMoT5NyF4hWOPtbC+yVCp
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR84MB3029
X-OriginatorOrg: hpe.com
X-Proofpoint-GUID: 63MOomNw-XEiDI7mBGwlnztYY4Iq-92B
X-Proofpoint-ORIG-GUID: 63MOomNw-XEiDI7mBGwlnztYY4Iq-92B
X-HPE-SCL: -1
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.517,FMLib:17.11.122.1
 definitions=2022-08-19_12,2022-08-18_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0
 lowpriorityscore=0 mlxscore=0 spamscore=0 malwarescore=0 impostorscore=0
 mlxlogscore=999 priorityscore=1501 adultscore=0 phishscore=0
 suspectscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx
 scancount=1 engine=8.12.0-2207270000 definitions=main-2208190084
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org


> -----Original Message-----
> From: Herbert Xu <herbert@gondor.apana.org.au>
> Sent: Friday, August 19, 2022 6:05 AM
> Subject: Re: [PATCH] crypto: x86/sha512 - load based on CPU features
>=20
> Robert Elliott <elliott@hpe.com> wrote:
> > x86 optimized crypto modules built as modules rather than built-in
> > to the kernel end up as .ko files in the filesystem, e.g., in
> > /usr/lib/modules. If the filesystem itself is a module, these might
> > not be available when the crypto API is initialized, resulting in
> > the generic implementation being used (e.g., sha512_transform rather
> > than sha512_transform_avx2).
> >
> > In one test case, CPU utilization in the sha512 function dropped
> > from 15.34% to 7.18% after forcing loading of the optimized module.
> >
> > Add module aliases for this x86 optimized crypto module based on CPU
> > feature bits so udev gets a chance to load them later in the boot
> > process when the filesystems are all running.
> >
> > Signed-off-by: Robert Elliott <elliott@hpe.com>
> > ---
> > arch/x86/crypto/sha512_ssse3_glue.c | 10 ++++++++++
> > 1 file changed, 10 insertions(+)
>=20
> Patch applied.  Thanks.

I'll post a series that applies this technique to all the other
x86 modules, if there are no problems reported with sha512.

Do other architectures have the same issue, or is something else done
to ensure that modules are loaded?

MODULE_DEVICE_TABLE() is used by three other architecture-specific
modules:

1. One arm (32-bit) module, matching on certain Arm extensions:
  arch/arm/crypto/crc32-ce-glue.c:MODULE_DEVICE_TABLE(cpu, crc32_cpu_featur=
e);

2. One arm64 module, matching on certain Arm extensions:
  arch/arm64/crypto/ghash-ce-glue.c:MODULE_DEVICE_TABLE(cpu, ghash_cpu_feat=
ure);

3. All of the sparc modules share a global solution:
  arch/sparc/crypto/crop_devid.c:MODULE_DEVICE_TABLE(of, crypto_opcode_matc=
h);

/* This is a dummy device table linked into all of the crypto
 * opcode drivers.  It serves to trigger the module autoloading
 * mechanisms in userspace which scan the OF device tree and
 * load any modules which have device table entries that
 * match OF device nodes.
 */

Each module .c file includes that .c file:
  aes_glue.c:#include "crop_devid.c"
  camellia_glue.c:#include "crop_devid.c"
  crc32c_glue.c:#include "crop_devid.c"
  des_glue.c:#include "crop_devid.c"
  md5_glue.c:#include "crop_devid.c"
  sha1_glue.c:#include "crop_devid.c"
  sha256_glue.c:#include "crop_devid.c"
  sha512_glue.c:#include "crop_devid.c"