| Message ID | 20240123022852.2475-2-TonyWWang-oc@zhaoxin.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Herbert Xu |
| Headers | show |
| Series | Add Zhaoxin hardware engine driver support for SHA | expand |
On 1/22/24 18:28, Tony W Wang-oc wrote: > Updates the supporting qualification for packlock-sha driver, making > it support CPUs whose vendor ID is Centaur and Famliy is 6. This changelog isn't telling us very much. *Why* is this a good change? > diff --git a/drivers/crypto/padlock-sha.c b/drivers/crypto/padlock-sha.c > index 6865c7f1fc1a..2e82c5e77f7a 100644 > --- a/drivers/crypto/padlock-sha.c > +++ b/drivers/crypto/padlock-sha.c > @@ -491,7 +491,7 @@ static struct shash_alg sha256_alg_nano = { > }; > > static const struct x86_cpu_id padlock_sha_ids[] = { > - X86_MATCH_FEATURE(X86_FEATURE_PHE, NULL), > + X86_MATCH_VENDOR_FAM_FEATURE(CENTAUR, 6, X86_FEATURE_PHE, NULL), > {} > }; Logically, this is saying that there are non-CENTAUR or non-family-6 CPUs that set X86_FEATURE_PHE, but don't support X86_FEATURE_PHE. Is that the case? The one Intel use of X86_MATCH_VENDOR_FAM_FEATURE() also looks a bit suspect, btw.
On 2024/1/24 00:33, Dave Hansen wrote: > > [这封邮件来自外部发件人 谨防风险] > > On 1/22/24 18:28, Tony W Wang-oc wrote: >> Updates the supporting qualification for packlock-sha driver, making >> it support CPUs whose vendor ID is Centaur and Famliy is 6. > This changelog isn't telling us very much. *Why* is this a good change? > >> diff --git a/drivers/crypto/padlock-sha.c b/drivers/crypto/padlock-sha.c >> index 6865c7f1fc1a..2e82c5e77f7a 100644 >> --- a/drivers/crypto/padlock-sha.c >> +++ b/drivers/crypto/padlock-sha.c >> @@ -491,7 +491,7 @@ static struct shash_alg sha256_alg_nano = { >> }; >> >> static const struct x86_cpu_id padlock_sha_ids[] = { >> - X86_MATCH_FEATURE(X86_FEATURE_PHE, NULL), >> + X86_MATCH_VENDOR_FAM_FEATURE(CENTAUR, 6, X86_FEATURE_PHE, NULL), >> {} >> }; > Logically, this is saying that there are non-CENTAUR or non-family-6 > CPUs that set X86_FEATURE_PHE, but don't support X86_FEATURE_PHE. Is > that the case? Not exactly. Zhaoxin CPU supports X86_FEATURE_PHE and X86_FEATURE_PHE2. We expect the Zhaoxin CPU to use the zhaoxin_sha driver introduced in the third patch of this patch set. Without this patch Zhaoxin CPU will also match the padlock-sha driver too. > The one Intel use of X86_MATCH_VENDOR_FAM_FEATURE() also looks a bit > suspect, btw.
On 1/31/24 01:45, Tony W Wang-oc wrote: >>> static const struct x86_cpu_id padlock_sha_ids[] = { >>> - X86_MATCH_FEATURE(X86_FEATURE_PHE, NULL), >>> + X86_MATCH_VENDOR_FAM_FEATURE(CENTAUR, 6, X86_FEATURE_PHE, NULL), >>> {} >>> }; >> Logically, this is saying that there are non-CENTAUR or non-family-6 >> CPUs that set X86_FEATURE_PHE, but don't support X86_FEATURE_PHE. Is >> that the case? > > Not exactly. > > Zhaoxin CPU supports X86_FEATURE_PHE and X86_FEATURE_PHE2. > > We expect the Zhaoxin CPU to use the zhaoxin_sha driver introduced in > the third patch of this patch set. > > Without this patch Zhaoxin CPU will also match the padlock-sha driver too. I honestly have no idea what this is saying. Could you try again, please?
On 2024/1/31 23:33, Dave Hansen wrote: > > [这封邮件来自外部发件人 谨防风险] > > On 1/31/24 01:45, Tony W Wang-oc wrote: >>>> static const struct x86_cpu_id padlock_sha_ids[] = { >>>> - X86_MATCH_FEATURE(X86_FEATURE_PHE, NULL), >>>> + X86_MATCH_VENDOR_FAM_FEATURE(CENTAUR, 6, X86_FEATURE_PHE, NULL), >>>> {} >>>> }; >>> Logically, this is saying that there are non-CENTAUR or non-family-6 >>> CPUs that set X86_FEATURE_PHE, but don't support X86_FEATURE_PHE. Is >>> that the case? >> Not exactly. >> >> Zhaoxin CPU supports X86_FEATURE_PHE and X86_FEATURE_PHE2. >> >> We expect the Zhaoxin CPU to use the zhaoxin_sha driver introduced in >> the third patch of this patch set. >> >> Without this patch Zhaoxin CPU will also match the padlock-sha driver too. > I honestly have no idea what this is saying. > > Could you try again, please? Sorry. It should be said that there are non-CENTAUR or non-family-6 CPUs that set X86_FEATURE_PHE, and also set the new X86_FEATURE_PHE2. For these CPUs, we expect to use a new driver that supports both X86_FEATURE_PHE and X86_FEATURE_PHE2. So we make the driver padlock-sha to matches CENTAUR Family-6 CPU explicitly.
On 1/31/24 18:37, Tony W Wang-oc wrote: > Sorry. It should be said that there are non-CENTAUR or non-family-6 CPUs > that set X86_FEATURE_PHE, > > and also set the new X86_FEATURE_PHE2. For these CPUs, we expect to use > a new driver that supports > > both X86_FEATURE_PHE and X86_FEATURE_PHE2. > > So we make the driver padlock-sha to matches CENTAUR Family-6 CPU > explicitly. Could you please take a look at how this is done for the existing crypto algorithms? This doesn't seem horribly new. We have AVX-512-based algorithms that somehow work on systems that also have AVX and AVX2 support. Yet, there are no other vendor or family matches in the x86_cpu_id arrays for them. Why?
diff --git a/drivers/crypto/padlock-sha.c b/drivers/crypto/padlock-sha.c index 6865c7f1fc1a..2e82c5e77f7a 100644 --- a/drivers/crypto/padlock-sha.c +++ b/drivers/crypto/padlock-sha.c @@ -491,7 +491,7 @@ static struct shash_alg sha256_alg_nano = { }; static const struct x86_cpu_id padlock_sha_ids[] = { - X86_MATCH_FEATURE(X86_FEATURE_PHE, NULL), + X86_MATCH_VENDOR_FAM_FEATURE(CENTAUR, 6, X86_FEATURE_PHE, NULL), {} }; MODULE_DEVICE_TABLE(x86cpu, padlock_sha_ids);
Updates the supporting qualification for packlock-sha driver, making it support CPUs whose vendor ID is Centaur and Famliy is 6. Signed-off-by: Tony W Wang-oc <TonyWWang-oc@zhaoxin.com> --- drivers/crypto/padlock-sha.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)