wireguard-openbsd/sys/arch/amd64/include/cpu.h, branch jd/queueboostsWireGuard implementation for the OpenBSD kernelhttps://git.zx2c4.com/wireguard-openbsd/atom/sys/arch/amd64/include/cpu.h?h=jd%2Fqueueboosts2020-06-03T06:54:04Zlet the random subsystem read the tsc for event "timestamps".2020-06-03T06:54:04Zdlgdlg@openbsd.org2020-06-03T06:54:04Zurn:sha1:b8f1c15c74bab3fdc46349a15171114bcc56e562introduce "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.
Use the same inittodr()/resettodr() implementation as on arm64/armv7/sparc642020-04-28T12:58:27Zketteniskettenis@openbsd.org2020-04-28T12:58:27Zurn:sha1:6905cb4ab37f6b72270043235ae0ebbc5033bf6a
and move it to the end of machdep.c. Rework the actual implementation
for te MC14818 compatible RTC into something that can be used as a todr_handle.
ok mpi@
Remove unused protoype.2020-04-15T16:38:24Zketteniskettenis@openbsd.org2020-04-15T16:38:24Zurn:sha1:49989bafd49f1d77c5079478172fd81eddb48b5dDisable TSX when MSR_ARCH_CAPABILITIES sets TSX_CTRL.2019-12-20T07:49:31Zjsgjsg@openbsd.org2019-12-20T07:49:31Zurn:sha1:b8e34f5347d9abe26f72a6396eb3ca95ece63c26
Even with the latest microcode this is not set on all CPUs with TSX, but
is set on CPUs which don't need MDS mitigations.
MDS mitigations also mitigate TSX Asynchronous Abort (TAA) but aren't
done if the CPU claims to not be affected by MDS (MDS_NO).
According to "Deep Dive: Intel Transactional Synchronization Extensions
(Intel TSX) Asynchronous Abort" CPUs requiring additional mitigations
for this are:
06-8e-0c Whiskey Lake (ULT refresh)
06-55-0{6,7} 2nd Gen Xeon Scalable Processors based on Cascade Lake
06-9e-0d Coffee Lake R
Currently TSX is disabled unconditionally when possible even if TAA_NO
is set.
ok bluhm@ guenther@ deraadt@
tested by bluhm@ on i5-8365U (06-8e-0c).
Add TSC synchronization for multiprocessor machines.2019-08-09T15:20:04Zpiroftipirofti@openbsd.org2019-08-09T15:20:04Zurn:sha1:8d9f4b32f43f4b9aeb465c2f55b56a13d021b7d8
CPU0 is the reference clock and all others are skewed. During CPU
initialization the clocks synchronize by keeping a registry of each CPU
clock skewness and adapting the TSC read routine accordingly.
This commit also re-enables TSC as the default time source.
Future work includes MSR-based synchronization via IA32_TSC_ADJUST
and perhaps adding a task that is executed periodically to keep the
clocks in sync in case they drift apart.
Inspired from NetBSD.
Tested by many and thoroughly reviewed by kettenis@, thank you!
OK kettenis@, deraadt@
Mitigate Intel's Microarchitectural Data Sampling vulnerability.2019-05-17T19:07:15Zguentherguenther@openbsd.org2019-05-17T19:07:15Zurn:sha1:a0dcb1783e6fe75c0d3cc06802415d3e715ac53b
If the CPU has the new VERW behavior than that is used, otherwise
use the proper sequence from Intel's "Deep Dive" doc is used in the
return-to-userspace and enter-VMM-guest paths. The enter-C3-idle
path is not mitigated because it's only a problem when SMT/HT is
enabled: mitigating everything when that's enabled would be a _huge_
set of changes that we see no point in doing.
Update vmm(4) to pass through the MSR bits so that guests can apply
the optimal mitigation.
VMM help and specific feedback from mlarkin@
vendor-portability help from jsg@ and kettenis@
ok kettenis@ mlarkin@ deraadt@ jsg@
Delete cpu_idle_{enter,leave}_fcn() as unused. Add RETGUARD checks to2019-05-12T22:23:38Zguentherguenther@openbsd.org2019-05-12T22:23:38Zurn:sha1:f7a56ef1360d3ad003d116f7914fb30bc1a02760
cpu_idle_cycle()
ok mpi@ kettenis@
Add a pwraction sysctl that controls what the power button does on acpi.2019-01-19T20:45:06Ztedutedu@openbsd.org2019-01-19T20:45:06Zurn:sha1:e9721e4882a991481e5af5fdf9238b40ca429ecb
By default, nothing changes -- shutdown is initiated. But allows turning
power button into a sleep button if desired.
(grudging) ok from a few parties
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@