wireguard-openbsd/sys/arch/powerpc/include, branch jd/queueboostsWireGuard implementation for the OpenBSD kernelhttps://git.zx2c4.com/wireguard-openbsd/atom/sys/arch/powerpc/include?h=jd%2Fqueueboosts2020-06-05T14:25:05ZImplement cpu_rnd_messybits() as a read of the cycle counter register.2020-06-05T14:25:05Znaddynaddy@openbsd.org2020-06-05T14:25:05Zurn:sha1:4f1155a8e1b8d56b62802304c62b79d4e918eb9a
ok dlg@, powerpc/sparc64 ok kettenis@, sparc64/alpha tested by deraadt@
introduce "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.
Retire <machine/varargs.h>.2020-05-27T15:16:04Zvisavisa@openbsd.org2020-05-27T15:16:04Zurn:sha1:9df0f941a91e9f67cc4e63514cb174cb2a5783fd
Nothing uses the header anymore.
OK deraadt@ mpi@
Switch powerpc to MI mplock implementation.2020-04-15T08:09:00Zmpimpi@openbsd.org2020-04-15T08:09:00Zurn:sha1:bb9163a1e6a69b9ce00788c7e8db783619b1549f
Reduce differences with others architectures and make it possible to use
WITNESS on it.
Rename & keep the current recursive lock implementation as it is used by
the pmap.
Tested by Peter J. Philipp, otto@ and cwen@.
ok kettenis@
Fix inline assembly in ppc_mftb(); using %L0 instead of %0+1 makes this work2020-03-17T10:14:45Zketteniskettenis@openbsd.org2020-03-17T10:14:45Zurn:sha1:1b5c1bb041a8716a4f9de2b79b9d94b5d3e53c6a
for both gcc and clang. From NetBSD. Thanks to some serious detective work
by ghoehler@.
ok deraadt@, gkeohler@
Use "i" constrain instead of "n" constrain in inline assembly. Makes clang2019-07-11T21:18:05Zketteniskettenis@openbsd.org2019-07-11T21:18:05Zurn:sha1:d3299c81f3075097f8f803d7f533a455b7832fe8
happy.
ok visa@, mpi@
Drop % from register name used for register variable since it makes clang2019-07-02T20:42:45Zketteniskettenis@openbsd.org2019-07-02T20:42:45Zurn:sha1:3b11bbaaee5711a3b5059b6df2d2680e52dfb6f1
unhappy.
ok deraadt@, visa@
Use the debugger mutex for `ddb_mp_mutex'. This should prevent a race2019-03-23T05:47:22Zvisavisa@openbsd.org2019-03-23T05:47:22Zurn:sha1:6c78d705e4830fa073b47e28a89f766740a85331
that could leave `ddb_mp_mutex' locked if one CPU incremented
`db_active' while another CPU was in the critical section. When the race
hit, the debugger was unable to resume execution or switch between CPUs.
Race analyzed by patrick@
OK mpi@ patrick@
Add intr_{disable,restore}() for powerpc.2019-03-23T05:27:53Zvisavisa@openbsd.org2019-03-23T05:27:53Zurn:sha1:f803efbff0a45e217da2c5f5bdc57a47fc1931de
OK mpi@ patrick@
Include srp.h where struct cpu_info uses srp to avoid erroring out when2018-12-05T10:28:21Zjsgjsg@openbsd.org2018-12-05T10:28:21Zurn:sha1:1a1181a966226532433438cb3741ae7cdc0727d4
including cpu.h machine/intr.h etc without first including param.h when
MULTIPROCESSOR is defined.
ok visa@