wireguard-openbsd/sys/arch/amd64/include/fpu.h, branch jd/queueboosts WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/sys/arch/amd64/include/fpu.h?h=jd%2Fqueueboosts 2019-11-29T22:34:09Z Fix size of reserved bytes section in xsave header. 2019-11-29T22:34:09Z mortimer mortimer@openbsd.org 2019-11-29T22:34:09Z urn:sha1:4a35389011043056010c824e656c5a0f8ea069d9 ok guenther@ kettenis@ In vmm, handle xsetbv like xrstor: instead of trying to prevalidate 2018-10-07T22:43:06Z guenther guenther@openbsd.org 2018-10-07T22:43:06Z urn:sha1:c4fce44361a18e822ae1be4caf7bf2a842acbd9f the values, just try it and handle the #GP if it faults. Problem reported by Maxime Villard (max(at)m00nbsd.net) ok mlarkin@ Move signal generation from fputrap() to where it's called in trap() 2018-06-24T00:49:25Z guenther guenther@openbsd.org 2018-06-24T00:49:25Z urn:sha1:0dc8bfa22fe958beefcb4ef84a1b44bc70b79dee Switch from lazy FPU switching to semi-eager FPU switching: track whether 2018-06-05T06:39:10Z guenther guenther@openbsd.org 2018-06-05T06:39:10Z urn:sha1:c9de630f2b8eca49826c5a19f6e33a38c26295b2 curproc's xstate ("extended state") is loaded in the CPU or not. - context switch, sendsig(), vmm, and doing CPU crypto in the kernel all check the flag and, if set, save the old thread's state to the PCB, clear the flag, and then load the _blank_ state - when returning to userspace, if the flag is clear then set it and restore the thread's state This simpler tracking also fixes the restoring of FPU state after nested signal handlers. With this, %cr0's TS flag is never set, the FPU #DNA trap can no longer happen, and IPIs are no longer necessary for flushing or syncing FPU state; on the other hand, restoring xstate while returning to userspace means we have to handle xrstor faulting if we could be loading an altered state. If that happens, reset the state, fake a #GP fault (SIGBUS), and recheck for ASTs. While here, regularize fxsave/fxrstor vs xsave/xrstor handling, by using codepatching to switch to xsave/xrstor when present in the CPU. In addition, code patch in use of xsaveopt in most places when the CPU supports that. Use the 64bit-wide variants of the instructions in all cases so that x87 instruction fault IPs are reported correctly. This change has three motivations: 1) with modern clang, SSE registers are used even in rcrt0.o, making lazy FPU switching a smaller benefit vs trap costs 2) the Intel SDM warns that lazy FPU switching may increase power costs 3) post-Spectre rumors suggest that the %cr0 TS flag might not block speculation, permitting leaking of information about FPU state (AES keys?) across protection boundaries. tested by many in snaps; prodding from deraadt@ Update comment to reflect xsave 2018-05-26T17:28:17Z guenther guenther@openbsd.org 2018-05-26T17:28:17Z urn:sha1:b14d10f35544ed7648da71bad4d1e92eb19bd760 vmm(4): proper save/restore of FPU context during entry/exit. 2017-04-27T06:16:39Z mlarkin mlarkin@openbsd.org 2017-04-27T06:16:39Z urn:sha1:c86bb406de1a7d9c03da29308568da5ba90607c4 tested by reyk, dcoppa, and a few others. ok kettenis@ on the fpu bits ok deraadt@ on the vmm bits Save/restore AVX registers and other XSAVE-managed state information when 2015-03-25T21:05:18Z kettenis kettenis@openbsd.org 2015-03-25T21:05:18Z urn:sha1:a4ab44f3dff3b7a1675f153820989d0582d78e32 entering/leaving a signal handler like we already do the the FPU and SSE state. This should make it possible to use AVX instructions in signal handlers. ok mlarkin@ Add support for saving/restoring FPU state using the XSAVE/XRSTOR. Limit 2015-03-21T20:42:38Z kettenis kettenis@openbsd.org 2015-03-21T20:42:38Z urn:sha1:b03cf8e0afe5b068592053e59dc07a98dd04788f support to the X87, SSE and AVX state. This gives us (almost) full AVX support. The AVX state isn't saved by signal handlers yet, and ptrace(2) support is still missing. ok guenther@ Normalize sentinel. Use _MACHINE_*_H_ and _<ARCH>_*_H_ properly and consitently. 2011-03-23T16:54:33Z pirofti pirofti@openbsd.org 2011-03-23T16:54:33Z urn:sha1:2fa72412907ae78c4787a4a8f888c5f0486e225c Discussed and okay drahn@. Okay deraadt@. When reading MXCSR from userland sigcontext or a ptrace request, 2011-03-20T21:44:08Z guenther guenther@openbsd.org 2011-03-20T21:44:08Z urn:sha1:9ffc1ca4b10d000f656616c9a23d391bba6c08a3 mask out invalid bits to prevent a protect fault. Original diff by joshe@; further feedback and ok kettenis@