Re: VIA Padlock on AMD64
Error message is gone, so I assume it fixes the issue. On Sun, Jul 26, 2020 at 8:22 AM Taylor R Campbell wrote: > > > Date: Fri, 24 Jul 2020 00:35:19 +0300 > > From: Andrius V > > > > > > Cool! Is it reproducible? You can trigger reading from the RNG with: > > > > > > > > sysctl kern.entropy.gather=1 > > > > Tested, no messages are triggered for amd64, but sysctl > > kern.entropy.gather value is always 0: > > sysctl -w kern.entropy.gather=1 > > kern.entropy.gather: 0 -> 1 > > > > For i386, same, no messages, but kern.entropy.gather always has > > changing negative numbers. > > kern.entropy.gather is just a trigger that you can write to in order > to cause an effect; the number read out of it is meaningless. > > I committed a change to fix the interpretation of the status code > returned according to the documentation: > > https://mail-index.NetBSD.org/source-changes/2020/07/25/msg119718.html > > Let me know if you see the symptom again! > > (I should maybe do some more diagnostic tests on real hardware to > verify how it behaves in case the code was mostly right before and the > documentation is wrong.)
Re: VIA Padlock on AMD64
> Date: Fri, 24 Jul 2020 00:35:19 +0300 > From: Andrius V > > > > Cool! Is it reproducible? You can trigger reading from the RNG with: > > > > > > sysctl kern.entropy.gather=1 > > Tested, no messages are triggered for amd64, but sysctl > kern.entropy.gather value is always 0: > sysctl -w kern.entropy.gather=1 > kern.entropy.gather: 0 -> 1 > > For i386, same, no messages, but kern.entropy.gather always has > changing negative numbers. kern.entropy.gather is just a trigger that you can write to in order to cause an effect; the number read out of it is meaningless. I committed a change to fix the interpretation of the status code returned according to the documentation: https://mail-index.NetBSD.org/source-changes/2020/07/25/msg119718.html Let me know if you see the symptom again! (I should maybe do some more diagnostic tests on real hardware to verify how it behaves in case the code was mostly right before and the documentation is wrong.)
Re: VIA Padlock on AMD64
> > Cool! Is it reproducible? You can trigger reading from the RNG with: > > > > sysctl kern.entropy.gather=1 > > Tested, no messages are triggered for amd64, but sysctl kern.entropy.gather value is always 0: sysctl -w kern.entropy.gather=1 kern.entropy.gather: 0 -> 1 For i386, same, no messages, but kern.entropy.gather always has changing negative numbers.
Re: VIA Padlock on AMD64
On Wed, Jul 22, 2020 at 4:34 AM Taylor R Campbell wrote: > > Is there any documentation for the graphics hardware? Is hardware > available on the market in the US? (Can you send me any?) > Seems like required graphics datasheets are available here: https://www.x.org/docs/via/ and chipset manuals can be found here http://linux.via.com.tw/support/downloadFiles.action (by choosing "OS independant" and specific chipset options). Guess Linux drivers can provide some additional info. Regarding hardware, it is slowly becoming scarce, there are few options available in ebay and other online stores but many of them are overpriced. Zotac ZBOXNANO-VD01-U is quite a good option for VX900 I guess. VX800/VX855 are harder to find. I am based in Europe myself, so sending can be a little bit tricky, but I can definitely send a VX900 based VIA EPIA-M900 board, since it is not very actively used. The VX800 based one is my current NAS server though. > > Cool! Is it reproducible? You can trigger reading from the RNG with: > > sysctl kern.entropy.gather=1 > > I don't think I've changed anything in the past month or so that would > affect it -- more likely, this is a stochastic (and perhaps transient) > failure of the RNG hardware. I also see a likely bug in the VIA > cpu_rng code judging by the Padlock documentation -- should be easy to > fix, once the air here cools down enough to boot up my VIA laptop > without setting fire to the table. I will test later this week, including i386. It may not be necessarily very recent changes, sometimes I fail to notice changes in dmesg, and also didn't update current system for a while.
Re: VIA Padlock on AMD64
> Date: Wed, 22 Jul 2020 03:17:21 +0300 > From: Andrius V > > Not sure how useful to work on this though. Linux doesn't seem to have > newer graphics IDs in VIA DRM driver too (possibly abandoned over new > effort?). Currently Xorg server starts on VX900, but screen complains > with "Input signal is out of range" error with or without viadrmums > driver, so I can't see anything on the screen (maybe I need some > manual xorg configuration). I don't remember if it was the case > before, I usually used console only. Is there any documentation for the graphics hardware? Is hardware available on the market in the US? (Can you send me any?) > Unrelated, but I think it appeared pretty recently in dmesg logs and > related to your changes: > [ 4.0518619] aes: VIA ACE > > [ 11.7018582] cpu_rng via: failed repetition test > T[ 12.4718583] entropy: ready > > Before it was: > cpu_rng: VIA > rnd: seeded with 256 bits Cool! Is it reproducible? You can trigger reading from the RNG with: sysctl kern.entropy.gather=1 I don't think I've changed anything in the past month or so that would affect it -- more likely, this is a stochastic (and perhaps transient) failure of the RNG hardware. I also see a likely bug in the VIA cpu_rng code judging by the Padlock documentation -- should be easy to fix, once the air here cools down enough to boot up my VIA laptop without setting fire to the table.
Re: VIA Padlock on AMD64
On Tue, Jul 21, 2020 at 12:31 AM Taylor R Campbell wrote:
>
> > Date: Tue, 21 Jul 2020 00:16:16 +0300
> > From: Andrius V
> >
> > After a bit more investigation, yes, it is kassert (kernel diagnostic
> > assertion "viadrm_pci_ids[i].subvendor == PCI_ANY_ID" ), doesn't
> > matter amd64/i386.
>
> Panic should be fixed in via_pci 1.3.
>
Thank you for the quick fix. It works.
I agree regarding padlock that it is not useful. On the other hand,
viadrmums driver potentially can be useful as a module for amd64
platform, since (at least) the first generation of VIA Nano based
boards used some supported chipset graphics, for example the one in
CN896 chipset (don't have hardware to test though) and driver is
disabled in GENERIC by default.
>
> Can you share dmesg?
>
Portion of dmesg related to viadrmums once I included VX900 ID
(haven't tested VX800): {0x1106, 0x7122, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
VIA_DX9_0}:
[ 1.2754981] vga0 at pci0 dev 1 function 0: VIA Technologies VX900
Graphics [Chrome9 HD] (rev. 0x00)
[ 1.2754981] wsdisplay0 at vga0 kbdmux 1
[ 1.2754981] wsmux1: connecting to wsdisplay0
[ 1.2754981] viadrmums0 at vga0pci_mem_find: void region
[ 1.2754981] pci_mem_find: void region
[ 1.2754981] pci_mem_find: void region
[ 1.2754981] pci_mem_find: void region
[ 1.2754981] viadrmums0: map 3 failed
[ 1.2754981] pci_mem_find: void region
[ 1.2754981] viadrmums0: map 4 failed
[ 1.2754981] pci_mem_find: void region
[ 1.2754981] viadrmums0: map 5 failed
[ 1.2754981] DRM debug in drm_minor_register:
[ 1.2754981] DRM debug in drm_minor_register:
[ 1.2754981] DRM debug in drm_minor_register:
[ 1.2754981] DRM debug in drm_minor_register: new minor registered 0
[ 1.2754981] kern info: [drm] Supports vblank timestamp caching Rev
2 (21.10.2013).
[ 1.2754981] kern info: [drm] No driver support for vblank timestamp query.
Not sure how useful to work on this though. Linux doesn't seem to have
newer graphics IDs in VIA DRM driver too (possibly abandoned over new
effort?). Currently Xorg server starts on VX900, but screen complains
with "Input signal is out of range" error with or without viadrmums
driver, so I can't see anything on the screen (maybe I need some
manual xorg configuration). I don't remember if it was the case
before, I usually used console only.
Unrelated, but I think it appeared pretty recently in dmesg logs and
related to your changes:
[ 4.0518619] aes: VIA ACE
[ 11.7018582] cpu_rng via: failed repetition test
T[ 12.4718583] entropy: ready
Before it was:
cpu_rng: VIA
rnd: seeded with 256 bits
> Do you have any older 32-bit VIA hardware to compare to see whether it
> works better there? (Haven't tried it on my 32-bit VIA laptop in a
> while, and right now it's too hot to power that little space heater
> on!)
Yes, I do have an old 2xVIA Eden-N based board with CN400 chipset. The
driver was working pretty well on it (tested relatively recently).
Re: VIA Padlock on AMD64
On Sun, Jul 19, 2020 at 6:00 PM Taylor R Campbell wrote: > > I guess we could do that. It's not really that useful -- the only > application it's good for is in-kernel IPsec. OpenSSL should already > be able to take advantage of the CPU support in userland -- no kernel > driver needed. > > (I also don't have any 64-bit VIA hardware to test it on, which is why > I added it only to amd64/ALL to make compile-testing easier.) > 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. P.S. distrib/sets/lists/modules/md.amd64 also needs to include it, in case module is added. > > Try comparing > > openssl speed aes-256-cbc > openssl speed -evp aes-256-cbc > > and particularly note the user time spent. > 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. I think I was even trying to test ssh with no luck to see tangible improvements. Gave up after a while, not using such this functionality directly, out of curiosity only. > > > 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?
Re: VIA Padlock on AMD64
> Date: Mon, 20 Jul 2020 21:31:20 + > From: Taylor R Campbell > > > Date: Tue, 21 Jul 2020 00:16:16 +0300 > > From: Andrius V > > > > After a bit more investigation, yes, it is kassert (kernel diagnostic > > assertion "viadrm_pci_ids[i].subvendor == PCI_ANY_ID" ), doesn't > > matter amd64/i386. > > Panic should be fixed in via_pci 1.3. ...excuse me, that's supposed to read: via_pci.c 1.4.
Re: VIA Padlock on AMD64
> Date: Tue, 21 Jul 2020 00:16:16 +0300 > From: Andrius V > > After a bit more investigation, yes, it is kassert (kernel diagnostic > assertion "viadrm_pci_ids[i].subvendor == PCI_ANY_ID" ), doesn't > matter amd64/i386. Panic should be fixed in via_pci 1.3. >The cause seems pretty obvious: viadrv_PCI_IDS > doesn't include some chrome graphics like 0x7122 from VX900 or 0x122 > from VX800, thus subvendor value is 0 by default, PCI_ANY_ID is 1 on > the other hand, if I am not mistaken. Adding 0x7122 to the list allows > viadrmums to attach and boot, but with some errors in the logs. Can you share dmesg? Do you have any older 32-bit VIA hardware to compare to see whether it works better there? (Haven't tried it on my 32-bit VIA laptop in a while, and right now it's too hot to power that little space heater on!)
Re: VIA Padlock on AMD64
On Mon, Jul 20, 2020 at 8:38 AM Taylor R Campbell wrote: > > > > 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. After a bit more investigation, yes, it is kassert (kernel diagnostic assertion "viadrm_pci_ids[i].subvendor == PCI_ANY_ID" ), doesn't matter amd64/i386. The cause seems pretty obvious: viadrv_PCI_IDS doesn't include some chrome graphics like 0x7122 from VX900 or 0x122 from VX800, thus subvendor value is 0 by default, PCI_ANY_ID is 1 on the other hand, if I am not mistaken. Adding 0x7122 to the list allows viadrmums to attach and boot, but with some errors in the logs. Crash log: [ 1.2755067] vga0 at pci0 dev 1 function 0: VIA Technologies VX900 Graphics [Chrome9 HD] (rev. 0x00) [ 1.2755067] wsdisplay0 at vga0 kbdmux 1 [ 1.2755067] wsmux1: connecting to wsdisplay0 [ 1.2755067] panic: kernel diagnostic assertion "viadrm_pci_ids[i].subvendor == PCI_ANY_ID" failed: file "/home/andriusv/workspace/netbsd-src/sys/e [ 1.2755067] cpu0: Begin traceback... [ 1.2755067] vpanic() at netbsd:vpanic+0x152 [ 1.2755067] __x86_indirect_thunk_rax() at netbsd:__x86_indirect_thunk_rax [ 1.2755067] viadrm_lookup.isra.0() at netbsd:viadrm_lookup.isra.0+0xf0 [ 1.2755067] viadrm_match() at netbsd:viadrm_match+0x1e [ 1.2755067] mapply() at netbsd:mapply+0x3f [ 1.2755067] config_search_loc() at netbsd:config_search_loc+0xfd [ 1.2755067] config_found_sm_loc() at netbsd:config_found_sm_loc+0x2b [ 1.2755067] config_attach_loc() at netbsd:config_attach_loc+0x182 [ 1.2755067] pci_probe_device() at netbsd:pci_probe_device+0x574 [ 1.2755067] pci_enumerate_bus() at netbsd:pci_enumerate_bus+0x1b7 [ 1.2755067] pcirescan() at netbsd:pcirescan+0x4e [ 1.2755067] pciattach() at netbsd:pciattach+0x186 [ 1.2755067] config_attach_loc() at netbsd:config_attach_loc+0x182 [ 1.2755067] mp_pci_scan() at netbsd:mp_pci_scan+0xa4 [ 1.2755067] amd64_mainbus_attach() at netbsd:amd64_mainbus_attach+0x237 [ 1.2755067] mainbus_attach() at netbsd:mainbus_attach+0x83 [ 1.2755067] config_attach_loc() at netbsd:config_attach_loc+0x182 [ 1.2755067] cpu_configure() at netbsd:cpu_configure+0x38 [ 1.2755067] main() at netbsd:main+0x2ec [ 1.2755067] cpu0: End traceback... [ 1.2755067] fatal breakpoint trap in supervisor mode [ 1.2755067] trap type 1 code 0 rip 0x80221a25 cs 0x8 rflags 0x202 cr2 0 ilevel 0x8 rsp 0x81d028b0 [ 1.2755067] curlwp 0x8188d740 pid 0.0 lowest kstack 0x81cfd2c0 Stopped in pid 0.0 (system) at netbsd:breakpoint+0x5: leave breakpoint() at netbsd:breakpoint+0x5 vpanic() at netbsd:vpanic+0x152 __x86_indirect_thunk_rax() at netbsd:__x86_indirect_thunk_rax viadrm_lookup.isra.0() at netbsd:viadrm_lookup.isra.0+0xf0 viadrm_match() at netbsd:viadrm_match+0x1e mapply() at netbsd:mapply+0x3f config_search_loc() at netbsd:config_search_loc+0xfd config_found_sm_loc() at netbsd:config_found_sm_loc+0x2b config_attach_loc() at netbsd:config_attach_loc+0x182 pci_probe_device() at netbsd:pci_probe_device+0x574 pci_enumerate_bus() at netbsd:pci_enumerate_bus+0x1b7 pcirescan() at netbsd:pcirescan+0x4e pciattach() at netbsd:pciattach+0x186 config_attach_loc() at netbsd:config_attach_loc+0x182 mp_pci_scan() at netbsd:mp_pci_scan+0xa4 amd64_mainbus_attach() at netbsd:amd64_mainbus_attach+0x237 mainbus_attach() at netbsd:mainbus_attach+0x83 config_attach_loc() at netbsd:config_attach_loc+0x182 cpu_configure() at netbsd:cpu_configure+0x38 main() at netbsd:main+0x2ec ds 28c0 es 2870 fs 28b0 gs 10 rdi 8 rsi 0 rbp 81d028b0 rbx 104 rdx 1 rcx 8 rax 1 r8 104 r9 0 r10 r11 0 r12 81348170ostype+0xa90 r13 81d028f8 r14 81d02b7c r15 0 rip 80221a25breakpoint+0x5 cs 8 rflags 202 rsp 81d028b0 ss 10 netbsd:breakpoint+0x5: leave
Re: VIA Padlock on AMD64
> Date: Mon, 20 Jul 2020 08:16:34 +0300 > From: Andrius V > > 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.
Re: VIA Padlock on AMD64
> Date: Sun, 19 Jul 2020 14:16:25 +0300 > From: Andrius V > > I just noticed that padlock driver was made to compile on amd64 > recently. I believe it should be included in modules Makefile > (/sys/modules/Makefile) as well (as per my git diff in previous > messages). I guess we could do that. It's not really that useful -- the only application it's good for is in-kernel IPsec. OpenSSL should already be able to take advantage of the CPU support in userland -- no kernel driver needed. (I also don't have any 64-bit VIA hardware to test it on, which is why I added it only to amd64/ALL to make compile-testing easier.) > > I created a patch to show the intention. It builds and "padlock" > > attaches to the CPU. On another hand, I failed to find any application > > which would be taking advantage of padlock (including i386). Neither > > openssl (tried speed tests), nor openssh (some commands I found in > > internet) showed any difference with padlock module or without it. > > Maybe some patching is needed but it seems hardware acceleration is > > ignored with these apps. If somebody know a good way to test it on > > NetBSD, I would be glad to hear it. Try comparing openssl speed aes-256-cbc openssl speed -evp aes-256-cbc and particularly note the user time spent. > > 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?
Re: VIA Padlock on AMD64
Hi,
I just noticed that padlock driver was made to compile on amd64
recently. I believe it should be included in modules Makefile
(/sys/modules/Makefile) as well (as per my git diff in previous
messages).
Index: sys/modules/Makefile
==
--- sys/modules/Makefile
+++ sys/modules/Makefile
@@ -318,11 +318,10 @@
SUBDIR+= ati_pcigart
SUBDIR+= compat_freebsd
SUBDIR+= mach64drm
SUBDIR+= mgadrm
SUBDIR+= nsclpcsio
-SUBDIR+= padlock
SUBDIR+= r128drm
SUBDIR+= radeondrm
SUBDIR+= savagedrm
SUBDIR+= sisdrm
SUBDIR+= tdfxdrm
@@ -339,10 +338,11 @@
SUBDIR+= drmkms_linux
SUBDIR+= drmkms_pci
SUBDIR+= i915drm
SUBDIR+= i915drmkms
SUBDIR+= pad
+SUBDIR+= padlock
#
# ISA modules
#
SUBDIR+= aps
SUBDIR+= finsio
On Sun, Apr 5, 2020 at 2:41 PM Andrius V wrote:
>
> I created a patch to show the intention. It builds and "padlock"
> attaches to the CPU. On another hand, I failed to find any application
> which would be taking advantage of padlock (including i386). Neither
> openssl (tried speed tests), nor openssh (some commands I found in
> internet) showed any difference with padlock module or without it.
> Maybe some patching is needed but it seems hardware acceleration is
> ignored with these apps. If somebody know a good way to test it on
> NetBSD, I would be glad to hear it.
>
> 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.
>
> diff --git a/distrib/sets/lists/modules/md.amd64
> b/distrib/sets/lists/modules/md.amd64
> index 1ab3209f278..bd4752d4a53 100644
> --- a/distrib/sets/lists/modules/md.amd64
> +++ b/distrib/sets/lists/modules/md.amd64
> @@ -193,6 +193,8 @@
> ./@MODULEDIR@/odcm/odcm.kmod modules-base-kernel kmod
> ./@MODULEDIR@/pad modules-base-kernel kmod
> ./@MODULEDIR@/pad/pad.kmod modules-base-kernel kmod
> +./@MODULEDIR@/padlock modules-base-kernel kmod
> +./@MODULEDIR@/padlock/padlock.kmod modules-base-kernel kmod
> ./@MODULEDIR@/powernow modules-base-kernel kmod
> ./@MODULEDIR@/powernow/powernow.kmod modules-base-kernel kmod
> ./@MODULEDIR@/pwdogmodules-base-kernel kmod
> diff --git a/sys/arch/amd64/conf/GENERIC b/sys/arch/amd64/conf/GENERIC
> index 44a0d35b400..c556feb5618 100644
> --- a/sys/arch/amd64/conf/GENERIC
> +++ b/sys/arch/amd64/conf/GENERIC
> @@ -86,6 +86,7 @@ coretemp* at cpu? # Intel on-die thermal sensor
> est0 at cpu0 # Intel Enhanced SpeedStep (non-ACPI)
> hyperv0at cpu0 # Microsoft Hyper-V
> #odcm0 at cpu0 # On-demand clock modulation
> +padlock0 at cpu0 # VIA Padlock
> powernow0 at cpu0 # AMD PowerNow! and Cool'n'Quiet (non-ACPI)
> vmt0 at cpu0 # VMware Tools
>
> diff --git a/sys/arch/x86/x86/via_padlock.c b/sys/arch/x86/x86/via_padlock.c
> index f23f891a642..e9d5f812f17 100644
> --- a/sys/arch/x86/x86/via_padlock.c
> +++ b/sys/arch/x86/x86/via_padlock.c
> @@ -341,7 +341,7 @@ via_padlock_cbc(void *cw, void *src, void *dst,
> void *key, int rep,
> lcr0(cr0 & ~(CR0_EM|CR0_TS));
>
> /* Do the deed */
> - __asm __volatile("pushfl; popfl"); /* force key reload */
> + __asm __volatile("pushf; popf");/* force key reload */
> __asm __volatile(".byte 0xf3, 0x0f, 0xa7, 0xd0" : /* rep xcrypt-cbc */
> : "a" (iv), "b" (key), "c" (rep), "d" (cw),
> "S" (src), "D" (dst)
> : "memory", "cc");
>
> diff --git a/sys/modules/Makefile b/sys/modules/Makefile
> index 4a29a4a23cd..3595b37f246 100644
> --- a/sys/modules/Makefile
> +++ b/sys/modules/Makefile
> @@ -321,7 +321,6 @@ SUBDIR+=compat_freebsd
> SUBDIR+= mach64drm
> SUBDIR+= mgadrm
> SUBDIR+= nsclpcsio
> -SUBDIR+= padlock
> SUBDIR+= r128drm
> SUBDIR+= radeondrm
> SUBDIR+= savagedrm
> @@ -342,6 +341,7 @@ SUBDIR+=drmkms_pci
> SUBDIR+= i915drm
> SUBDIR+= i915drmkms
> SUBDIR+= pad
> +SUBDIR+= padlock
> #
> # ISA modules
> #
>
> On Tue, Mar 24, 2020 at 10:57 AM Andrius V wrote:
> >
> > Hi,
> >
> > I accidentally noticed that padlock engine is not included on AMD64
> > port (neither as module or built-in). Is there any reason it excluded
> > from it? The build currently fails because inline asm code is using
> > pushl, popl instructions in the code in via_padlock_cbc method, but
> > replacing them with pushf, popf seemingly fixes the build and padlock
> > attaches. Since VIA has x86-64 based
VIA Padlock on AMD64
Hi, I accidentally noticed that padlock engine is not included on AMD64 port (neither as module or built-in). Is there any reason it excluded from it? The build currently fails because inline asm code is using pushl, popl instructions in the code in via_padlock_cbc method, but replacing them with pushf, popf seemingly fixes the build and padlock attaches. Since VIA has x86-64 based CPUs and all of them has the engine, probably it makes sense to include it? Regards, Andrius V
