wireguard-openbsd/sys/arch/arm64/include/cpu.h, branch jd/queueboosts WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/sys/arch/arm64/include/cpu.h?h=jd%2Fqueueboosts 2020-06-05T23:16:24Z Implement cpu_rnd_messybits() as a read of the virtual counter xored 2020-06-05T23:16:24Z naddy naddy@openbsd.org 2020-06-05T23:16:24Z urn:sha1:8274f7016bafdaa9664a02c123f04607750edbe0 with a bit-reversed copy of itself. There is progressively less entropy in the higher bits of a counter than in the lower bits, so bit-reverse one half in order to extract maximal entropy. style fixes and ok kettenis@ 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. Fix typo in comment. 2020-05-17T13:36:33Z kettenis kettenis@openbsd.org 2020-05-17T13:36:33Z urn:sha1:f8c21047e63df663d400f96c8a1bf49ec52bdfa2 Add machdep.compatible. 2020-05-17T11:05:15Z kettenis kettenis@openbsd.org 2020-05-17T11:05:15Z urn:sha1:943434f8be7bd40574537218daf09c4f07eafc22 ok jsg@ Register cpu(4) as a cooling device. This supports passive cooling by 2019-07-02T20:13:50Z kettenis kettenis@openbsd.org 2019-07-02T20:13:50Z urn:sha1:03e578406bb4bf63334c5bd1c0a2b49fd77a89d3 clamping the maximum DVFS state. ok mlarkin@, patrick@ Bump MAXCPUS to 32 so that we can use all cores on the Ampere eMAG. 2019-06-04T14:03:21Z patrick patrick@openbsd.org 2019-06-04T14:03:21Z urn:sha1:22c378bc8fd3e7d990882cf9f8ff2cb784900195 ok kettenis@ Include srp.h where struct cpu_info uses srp to avoid erroring out when 2018-12-05T10:28:21Z jsg jsg@openbsd.org 2018-12-05T10:28:21Z urn:sha1:1a1181a966226532433438cb3741ae7cdc0727d4 including cpu.h machine/intr.h etc without first including param.h when MULTIPROCESSOR is defined. ok visa@ Bump MAXCPUS from 8 to 24. 2018-08-11T14:00:33Z kettenis kettenis@openbsd.org 2018-08-11T14:00:33Z urn:sha1:81deddc382fccecbedaa7cfdf4e0a99ef055cf89 ok jsg@ Implement DVFS support. 2018-08-03T16:45:17Z kettenis kettenis@openbsd.org 2018-08-03T16:45:17Z urn:sha1:27d9c4288a3b1d24ade8a725f9504e61f45ae9ce ok patrick@ Add intr_enable() here as well. 2018-06-30T10:20:21Z kettenis kettenis@openbsd.org 2018-06-30T10:20:21Z urn:sha1:b5e763189b9982b741a8f9f15f770fc3c31055d1