wireguard-openbsd/sys/arch/arm, branch jd/queueboostsWireGuard implementation for the OpenBSD kernelhttps://git.zx2c4.com/wireguard-openbsd/atom/sys/arch/arm?h=jd%2Fqueueboosts2020-05-31T06:23:56Zintroduce "cpu_rnd_messybits" for use instead of nanotime in dev/rnd.c.2020-05-31T06:23:56Zdlgdlg@openbsd.org2020-05-31T06:23:56Zurn: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.
Oops, DDB wrapper around setjmp/longjmp was misplaced2020-05-18T17:24:03Zderaadtderaadt@openbsd.org2020-05-18T17:24:03Zurn:sha1:6a7860a40a831ea0f2b2937b0392cbcd0f7a9347Add machdep.compatible.2020-05-17T15:36:50Zketteniskettenis@openbsd.org2020-05-17T15:36:50Zurn:sha1:c5c0009c6b631723b5fb95feae57638eaf156035
ok jsg@
Put setjmp+longjmp inside #ifdef DDB the only kernel-side user.2020-05-17T13:48:29Zderaadtderaadt@openbsd.org2020-05-17T13:48:29Zurn:sha1:be7994c5120c6f906321c4b77341c04fcaa65b03
This shrinks the ramdisks a tiny bit.
Fix WITNESS build2020-05-17T11:12:55Zknkn@openbsd.org2020-05-17T11:12:55Zurn:sha1:e1ce6058128bbedce7f4d8f766a5a82a09a46cc3
sparc64 (and arm mem.c) are the only architectures/places where
RWLOCK_INITIALIZER() is used with static function variables, all other
(mem.c) usages place it into the global scope.
Fix builds with WITNESS enabled for sparc64 and arm by moving physlock
into global scope:
mem.c:93: error: initializer element is not constant
mem.c:93: error: (near initialization for 'physlock.rwl_lock_obj.lo_type')
OK visa
Make inittodr() and resettodr() MI.2020-05-16T14:44:44Zketteniskettenis@openbsd.org2020-05-16T14:44:44Zurn:sha1:5fcf2a4b8103efd7bc779ac85e97dbbe7542aaf4
ok deraadt@, mpi@, visa@
ok cheloha@ as well (would have preferred in new file for this code)
Initialize the timeval passed to todr_gettime() with the base time from2020-05-11T13:25:31Zketteniskettenis@openbsd.org2020-05-11T13:25:31Zurn:sha1:903250556290f4ea437844c80f12567b5d98bfdf
the file system such that implementations can use it to guess the right
century.
ok mpi@
Let the armv7 bus_dma layer and simplebus(4) implementation deal with2020-04-29T15:25:07Zketteniskettenis@openbsd.org2020-04-29T15:25:07Zurn:sha1:37084e1e34e6eafe959b14d27c905d6c5ddf0888
DMA remapping in the same way as arm64. This relies on the dma-ranges
property in the device tree and allows us to get rid of the hack for
the Raspberry Pi in the dwctwo(4) driver.
Note that this does not include the hack in simplebus(4) that we have on
arm64 since firmware that has the dma-ranges is in widespread use now.
ok patrick@
Bring inittodr()/resettodr() in line with arm64 and move it to2020-04-27T13:02:50Zketteniskettenis@openbsd.org2020-04-27T13:02:50Zurn:sha1:8eae2166add500fa19fc65cb58962f4be6845b7d
arrm32_machdep.c.
ok mpi@
Remove an unnecessary type cast.2020-03-19T16:35:39Zvisavisa@openbsd.org2020-03-19T16:35:39Zurn:sha1:ca1178b10c65d1fe2b21929d47dfd6e32f9ba4d1
OK kettenis@