wireguard-openbsd/sys/arch/mips64/include/cpu.h, branch jd/queueboostsWireGuard implementation for the OpenBSD kernelhttps://git.zx2c4.com/wireguard-openbsd/atom/sys/arch/mips64/include/cpu.h?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.
in non-MP, cpu_number() the #define should be 0UL; ok visa2019-09-02T02:35:08Zderaadtderaadt@openbsd.org2019-09-02T02:35:08Zurn:sha1:282d9ab5bb8194ee733174e9c1921d57001c3eefTurn need_resched() and signotify() into proper functions on mips64.2019-05-05T13:28:14Zvisavisa@openbsd.org2019-05-05T13:28:14Zurn:sha1:00c79297cde52f3758ac191ea525674a23bbbeadInclude 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@
Add processor IDs for several OCTEON II and III SoCs.2018-12-04T16:24:13Zvisavisa@openbsd.org2018-12-04T16:24:13Zurn:sha1:5f3b292c92fd8f5c843f196251d0aa235a4ffce7Declare ci_ipl volatile to prevent the compiler from optimizing2018-02-24T11:42:30Zvisavisa@openbsd.org2018-02-24T11:42:30Zurn:sha1:cb5217fba3727742f326b0c20baed47113c0e1ef
or reordering accesses to the variable. Assume that the assembler
preserves the correct sequence of instructions, which allows the
removal of the explicit noreorder/reorder toggles from the C code.
With ci_ipl being volatile, drop mips_sync() calls that follow
the accesses of the variable. The sync is redundant as a compiler
barrier. In addition, the MIPS64 CPU designs should not need the
sync for pipeline or write buffer control. According to miod@,
the use of the instruction is a carryover from code targeting
early MIPS designs that lack tight integration with the cache
and write buffer.
Discussed with and testing help from miod@.
Tested on CN5020, CN6120, CN7130, CN7360, Loongson 2F and 3A1000,
R4400, R8000, R10000 and R16000.
Drop unused field `ci_ipiih'.2018-01-29T14:53:01Zvisavisa@openbsd.org2018-01-29T14:53:01Zurn:sha1:e39ac6ab45d3e52c272b210747bc70e324747702Use MI mplock on mips64.2017-10-21T06:11:22Zvisavisa@openbsd.org2017-10-21T06:11:22Zurn:sha1:9390f3854d26ce45dc4db6a378db16ebc35ea112
OK mpi@
Let the kernel utilize the FPU if one is available, even when the2017-09-02T15:56:29Zvisavisa@openbsd.org2017-09-02T15:56:29Zurn:sha1:6d1676f7a61bec8a8db7e0033dd62bd52a8da9a6
FPUEMUL option is enabled. This benefits OCTEON III systems which can
run floating-point operations natively.
Feedback from and OK miod@; he also helped with testing.
Tested on octeon without FPU (CN5020, CN6120) and with FPU (CN7130),
as well as on sgi/IP27 (MP R16000), sgi/IP32 (R5000), and
loongson (3A1000).
Define MAXCPUS per mips64 port.2017-07-30T16:05:24Zvisavisa@openbsd.org2017-07-30T16:05:24Zurn:sha1:70641ad19215cac260b8a751878d8e511c606661