Bug 252543 - armv8crypto doesn't announce it self in the dmesg output
Summary: armv8crypto doesn't announce it self in the dmesg output
Status: In Progress
Alias: None
Product: Base System
Classification: Unclassified
Component: arm (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: Mitchell Horne
Depends on:
Reported: 2021-01-09 10:45 UTC by Gordon Bergling
Modified: 2021-01-18 21:12 UTC (History)
2 users (show)

See Also:

Print message (446 bytes, patch)
2021-01-12 14:46 UTC, Mitchell Horne
no flags Details | Diff
dmesg of RPi4 with patch applied (15.35 KB, text/plain)
2021-01-15 13:52 UTC, Gordon Bergling
no flags Details
Print message (extra printf) (504 bytes, patch)
2021-01-15 15:29 UTC, Mitchell Horne
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Gordon Bergling freebsd_committer 2021-01-09 10:45:37 UTC
The kernel module armv8crypto doesn't announce it selfs in the dmesg output. Verified on RPi4B.

It would be very useful if a message like this from aesni could be printed.

Comment 1 Mitchell Horne freebsd_committer 2021-01-12 14:46:05 UTC
Created attachment 221494 [details]
Print message

Hi Gordon,

Plucking a random RPi4B dmesg:

It seems that the CPU lacks the AES instruction extension, and armv8crypto doesn't attach. For a supported CPU, we would expect to see "AES" or "AES+PMULL" listed under Instruction Set Attributes 0.

I've attached a patch that adds a message when the driver fails to attach. Note that on supported hardware, the driver announces itself as expected.
Comment 2 Gordon Bergling freebsd_committer 2021-01-15 13:52:42 UTC
Created attachment 221600 [details]
dmesg of RPi4 with patch applied
Comment 3 Gordon Bergling freebsd_committer 2021-01-15 14:01:46 UTC
I applied your patch, but I didn't see a positive or negative announcement of armv8crypto module, even if the RPi4B doesn't support the hardware acceleration.

Maybe D27454 improves the situation.

Add AES-GCM H/W acceleration for kTLS on ARMv8 architecture
Comment 4 Mitchell Horne freebsd_committer 2021-01-15 15:27:11 UTC
(In reply to Gordon Bergling from comment #3)

That's quite surprising, since the patch contains case statements for all three legal values. Which git revision did you build from? It should at least be newer than 074a91f746bd (Jan 13) for armv8crypto to be loaded automatically, otherwise you will need to kldload armv8crypto.
Comment 5 Mitchell Horne freebsd_committer 2021-01-15 15:29:11 UTC
Created attachment 221602 [details]
Print message (extra printf)

You might try this patch next, to ensure we get _something_ printed.
Comment 6 Gordon Bergling freebsd_committer 2021-01-15 15:52:01 UTC
(In reply to Mitchell Horne from comment #5)

Even with the latest patch applied, no value is printed. Please see


for a full dmesg output and local modifications. Besides your patch, I currently have a change in the tree regarding KTLS on the RPi4B, but I wouldn't think that this makes a difference.

The tree itself is 'git: b14cfecbf0ed - main - pkgfs_open: follow symlink' from today.
Comment 7 Mitchell Horne freebsd_committer 2021-01-15 16:08:55 UTC
(In reply to Gordon Bergling from comment #6)

> FreeBSD 13.0-ALPHA1 #12 main-c255973-gb14cfecbf0ed: Fri Jan 15 09:32:46 CET 2021

Are you sure that you built the kernel with the patches applied? I would expect to see "-dirty" appended to the version string if so, or a different hash if you applied them and made a local commit.

For example, the kernel I just built with the patch applied, uncommitted:

> FreeBSD 13.0-ALPHA1 #52 main-c255982-g0b92d1dd18c1-dirty: Fri Jan 15 11:59:47 AST 2021
Comment 8 Gordon Bergling freebsd_committer 2021-01-15 16:16:45 UTC
(In reply to Mitchell Horne from comment #7)

Yes I did. Please see the mentioned link above. I didn't have committed the patches locally, but appended a 'git diff' from /usr/src to the dmesg output.
Comment 9 Gordon Bergling freebsd_committer 2021-01-15 16:21:05 UTC
(In reply to Mitchell Horne from comment #7)

Mmhh, but if you see a -dirty applied to the uname output with a local non-committed change that is strange. I thought -dirty can only be work for local commits.
Comment 10 Gordon Bergling freebsd_committer 2021-01-16 08:29:37 UTC
(In reply to Mitchell Horne from comment #7)

Sorry, I messed up the obj directory.

dmesg shows now,
armv8crypto0: CPU lacks AES intrinsicsAES val: 0

Wish indicates that the RPi4B is missing the needed instructions.
Comment 11 Mitchell Horne freebsd_committer 2021-01-18 20:27:40 UTC
(In reply to Gordon Bergling from comment #10)

All good, thanks for confirming the patch. I will commit it shortly.
Comment 12 commit-hook freebsd_committer 2021-01-18 21:12:28 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=a520f5ca580fcff34fd0d9f0d64a4c165f57eb30

commit a520f5ca580fcff34fd0d9f0d64a4c165f57eb30
Author:     Mitchell Horne <mhorne@FreeBSD.org>
AuthorDate: 2021-01-18 20:59:21 +0000
Commit:     Mitchell Horne <mhorne@FreeBSD.org>
CommitDate: 2021-01-18 20:59:21 +0000

    armv8crypto: print a message on probe failure

    Similar to the message printed by aesni(4), let the user know if the
    driver is unsupported by their CPU.

    PR:             252543
    Reported by:    gbe
    MFC after:      3 days
    Sponsored by:   The FreeBSD Foundation

 sys/crypto/armv8/armv8_crypto.c | 3 +++
 1 file changed, 3 insertions(+)