Re: VIA Padlock on AMD64

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Mon, 20 Jul 2020 08:16:34 +0300
> From: Andrius V <vezhlys%gmail.com@localhost>
> 
> Considering it is limited usage isn't the kernel module actually more
> useful, since you can add it to boot config once you really need it?
> Unless, in-kernel functionality won't work with the kernel module for some
> reason. Regardless, I was simply looking from the perspective of i386,
> since it has the module available, why not just to move config for both? I
> can agree though, that probably there were close to zero users utilizing
> padlock over the years. Nevertheless, I have two VIA Nano boards, both
> successfully booted with a padlock engine attached.

The code is just not worth much, and I kind of plan to delete it
altogether once a few other things in the kernel AES stack are fixed.
If you're not doing in-kernel IPsec it's really not worth anything.

> Unfortunately, testing on three different boards didn't show much
> difference, even when specifically openssl's padlock engine was used
> (actually it showed worse results on bigger blocks). Seems like padlock
> instructions were not utilized in any case, at least if compared to some
> results posted on the internet. Either I was doing something wrong or
> openssl needs special patches. It was consistent with Linux results though.

You can tell whether openssl is doing the cryptography in the kernel
via /dev/crypto (and therefore potentially using the via_padlock.c
module) as follows:

% openssl speed aes-256-cbc
Doing aes-256 cbc for 3s on 16 size blocks: 14899528 aes-256 cbc's in 2.98s
Doing aes-256 cbc for 3s on 64 size blocks: 4030412 aes-256 cbc's in 2.97s
[...]
% openssl speed -evp aes-256-cbc
Doing aes-256-cbc for 3s on 16 size blocks: 1732147 aes-256-cbc's in 0.76s
Doing aes-256-cbc for 3s on 64 size blocks: 1373417 aes-256-cbc's in 0.43s
[...]

Note that the real time is about three seconds for each line, but the
last number shows user time -- it's about three seconds _without_
`-evp', but under one second _with_ `-evp', which means that the
computation is happening in the kernel.

Of course, you will probably find that the throughput is not actually
improved -- that's because the /dev/crypto userland interface is a
piece of garbage that's useful only to check the results of crypto
devices.  Which is why I said that the module is useful only for
in-kernel IPsec.

> > > > On the side note, same goes to viadrmums module (it's i386 only now)
> > > > but at least on VX900 I ended up with the crash, so I guess it may be
> > > > incompatible with amd64 (though it builds successfully). Will try to
> > > > test VX800 later on.
> >
> > I haven't tried viadrmums in a while.  What was the crash?
> 
> I am planning to submit PR once I will retest the driver with the latest
> images. Actually, it may not be amd64 specific after all. Crash happens
> during boot on match function, likely newer graphics are unsupported and
> triggers some kassert?

Can't say without the specific kassert (and ideally stack trace too).
I don't see anything obvious in viadrm_match that would be
problematic.