wireguard-openbsd/sys/arch/i386, branch jd/queueboosts WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/sys/arch/i386?h=jd%2Fqueueboosts 2020-06-22T00:33:28Z enable nvme on i386. 2020-06-22T00:33:28Z dlg dlg@openbsd.org 2020-06-22T00:33:28Z urn:sha1:ef2947948c0c973b2d43f0c7f5c79852dcd78e1e ok deraadt@ fold the TSC value in fewer operations, same result; ok deraadt@ 2020-06-19T15:00:45Z naddy naddy@openbsd.org 2020-06-19T15:00:45Z urn:sha1:ec4ed3a25fb7ac5b9c5a9ed6b8e4afed25159ea3 add a dumb pci_intr_establish_cpu(). 2020-06-17T06:17:19Z dlg dlg@openbsd.org 2020-06-17T06:17:19Z urn:sha1:4213a3c3ba0dadbca73f5e8966737ed0e0c8e00a i386 doesnt support msix, and the interrupt code assumes that it only ties stuff to cpu0. this mostly exists so the api exists for multiq drivers to compile against, but fail with when they try to use it. tested with a hacked up vmx(4). Check rdrand for success and try up to ten times, as recommended by Intel. 2020-06-15T19:25:16Z naddy naddy@openbsd.org 2020-06-15T19:25:16Z urn:sha1:dd423e202033ea6a7a2ccc1435d3d86866bb60c5 Do the same for rdseed. ok deraadt@ do not need assym.h 2020-06-14T17:05:45Z deraadt deraadt@openbsd.org 2020-06-14T17:05:45Z urn:sha1:4bee3a37bc5180c87533c8789bb3e791529c7378 crank version number 2020-06-14T16:06:25Z deraadt deraadt@openbsd.org 2020-06-14T16:06:25Z urn:sha1:29c02c14e09366e368ddf37ede6a9862fbfa2d6b asm versions of mdrandom() no longer needed 2020-06-14T16:04:54Z deraadt deraadt@openbsd.org 2020-06-14T16:04:54Z urn:sha1:0ddce9b0f2fc6f6888445b201113be717de0ac28 rewrite mdrandom() in C. previously this XOR'd against rdrand if available, 2020-06-14T16:00:08Z deraadt deraadt@openbsd.org 2020-06-14T16:00:08Z urn:sha1:55f8664c3cb6c3d3b4f4fd806d3cc0a0106e6ba9 and alternatively XOR'd against TSC. now always run both sequences, and also support rdseed as a third procedure. ok kettenis naddy update drm to linux 5.7 2020-06-08T04:47:57Z jsg jsg@openbsd.org 2020-06-08T04:47:57Z urn:sha1:c349dbc7938c71a30e13c1be4acc1976165f4630 adds kernel support for amdgpu: vega20, raven2, renoir, navi10, navi14 inteldrm: icelake, tigerlake Thanks to the OpenBSD Foundation for sponsoring this work, kettenis@ for helping, patrick@ for helping adapt rockchip drm and many developers for testing. introduce "cpu_rnd_messybits" for use instead of nanotime in dev/rnd.c. 2020-05-31T06:23:56Z dlg dlg@openbsd.org 2020-05-31T06:23:56Z urn:sha1:01802d2cc63d886227ab3b39e923ff13cf516166 rnd.c uses nanotime to get access to some bits that change quickly between events that it can mix into the entropy pool. it doesn't use nanotime to get a monotonically increasing set or ordered and accurate timestamps, it just wants something with bits that change. there's been discussions for years about letting rnd use a clock that's super fast to read, but not necessarily accurate, but it wasn't until recently that i figured out it wasn't interested in time at all, so things like keeping a fast clock coherent between cpu cores or correct according to ntp is unecessary. this means we can just let rnd read the cycle counters on cpus and things will be fine. cpus with cycle counters that vary in their speed and arent kept consistent between cores may even be desirable in this context. so this is the first step in converting rnd.c to reading cycle counter. it copies the nanotime backend to each arch, and they can replace it with something MD as a second step later on. djm@ suggested rnd_messybytes, but we landed on cpu_rnd_messybits. thanks to visa for his eyes. ok deraadt@ visa@ deraadt@ says he will help handle any MD fallout that occurs.