WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/sys/arch/m88k/include/cpu.h?h=jd%2Fqueueboosts 2020-05-31T06:23:56Z 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. 2019-08-28T13:48:40Z aoyama aoyama@openbsd.org 2019-08-28T13:48:40Z urn:sha1:8db9df62777b1c1bb6e93e6a1287c8982debb860 ci_mp_atomic_{begin,end} are 6th and 7th elements of cpu_info structure. Actually that is dummy structure used in early boot stage, but for consistency, move ci_srp_hazards position in cpu_info. ok mpi@ 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@ 2017-03-19T10:57:29Z miod miod@openbsd.org 2017-03-19T10:57:29Z urn:sha1:8adebe846c146c3067944abef6a94106ce5f13ae struct, rather than fetching them from arrays every time they are needed. ok aoyama@ 2015-07-02T01:33:59Z dlg dlg@openbsd.org 2015-07-02T01:33:59Z urn:sha1:52776b7dd171c092a35f86a9ed8bd1c22cac9fb8 "shared reference pointers". srp allows concurrent access to a data structure by multiple cpus while avoiding interlocking cpu opcodes. it manages its own reference counts and the garbage collection of those data structure to avoid use after frees. internally srp is a twisted version of hazard pointers, which are a relative of RCU. jmatthew wrote the bulk of a hazard pointer implementation and changed bpf to use it to allow mpsafe access to bpfilters. however, at s2k15 we were trying to apply it to other data structures but the memory overhead of every hazard pointer would have blown out significantly in several uses cases. a bulk of our time at s2k15 was spent reworking hazard pointers into srp. this diff adds the srp api and adds the necessary metadata to struct cpuinfo on our MP architectures. srp on uniprocessor platforms has alternate code that is optimised because it knows there'll be no concurrent access to data by multiple cpus. srp is made available to the system via param.h, so it should be available everywhere in the kernel. the docs likely need improvement cos im too close to the implementation. ok mpi@ 2015-02-11T07:05:39Z dlg dlg@openbsd.org 2015-02-11T07:05:39Z urn:sha1:d3b1d173f07835f2d78b379d23a5946ce16b055a with and ok miod@ 2014-07-11T10:53:07Z uebayasi uebayasi@openbsd.org 2014-07-11T10:53:07Z urn:sha1:65f535b7fa77bbec89e3f3bc91362d65d807077e The new CPU_BUSY_CYCLE() may be put in a busy loop body so that CPU can reduce power consumption, as Linux's cpu_relax() and FreeBSD's cpu_spinwait(). To start minimally, use PAUSE on i386/amd64 and empty on others. The name is chosen following the existing cpu_idle_*() functions. Naming and API may be polished later. OK kettenis@ 2014-03-29T18:09:28Z guenther guenther@openbsd.org 2014-03-29T18:09:28Z urn:sha1:2df76cc2a0aee2cb2166e3799b7bb5c3f883f83d ok dlg@ mpi@ deraadt@ 2013-05-31T17:00:57Z tedu tedu@openbsd.org 2013-05-31T17:00:57Z urn:sha1:05c6e375d50ab39874a711bb89313b663548aa0d 2013-03-12T09:37:16Z mpi mpi@openbsd.org 2013-03-12T09:37:16Z urn:sha1:6377c2eaf8ad0c2174b64c6ffe780441bba1d2d3 kgmon(8) to deal with them, this time without public header changes. Previously various CPUs were iterating over the same global buffer at the same time to modify it and never ended. This diff includes some ideas submited by Thor Simon to NetBSD via miod@. ok deraadt@, mikeb@, haesbaert@