wireguard-openbsd/sys/arch/amd64/include/pcb.h, branch jd/queueboosts WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/sys/arch/amd64/include/pcb.h?h=jd%2Fqueueboosts 2018-06-05T06:39:10Z 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@ Fix a typo relating to savefpu alignment 2017-04-26T07:05:24Z mlarkin mlarkin@openbsd.org 2017-04-26T07:05:24Z urn:sha1:c36cf6a8d661045c81bcd7e723e794ad5a5cac8b ok kettenis Move the setting of pcb_fsbase out of reset_segs() into its callers 2016-04-03T17:48:33Z guenther guenther@openbsd.org 2016-04-03T17:48:33Z urn:sha1:daca63ce39bb5e708c2009ce57aacb6291e2e9c5 ok mpi@ Do lazy update/reset of the FS.base and %[def]s segment registers: reseting 2015-05-18T19:59:27Z guenther guenther@openbsd.org 2015-05-18T19:59:27Z urn:sha1:b13138f26d8f4e65100b2377aab2ba4570a8d014 segment registers in cpu_switchto if the old thread had made it to userspace and restoring FS.base only on first return to userspace since context switch. ok mlarkin@ emul_native is only used for kernel threads which can't dump core, so 2015-05-05T02:13:46Z guenther guenther@openbsd.org 2015-05-05T02:13:46Z urn:sha1:2df12b22ee779d3f10995325e7cbd0d4be5705a0 delete coredump_trad(), uvm_coredump(), cpu_coredump(), struct md_coredump, and various #includes that are superfluous. This leaves compat_linux processes without a coredump callback. If that ability is desired, someone should update it to use coredump_elf32() and verify the results... ok kettenis@ remove irrelevant comments 2011-07-10T18:11:49Z deraadt deraadt@openbsd.org 2011-07-10T18:11:49Z urn:sha1:878f5d1ffb310159908e71fc1a8d7ae5e8c2f24f Unrevert the FS.base diff: the issues were actually elsewhere 2011-04-13T02:49:12Z guenther guenther@openbsd.org 2011-04-13T02:49:12Z urn:sha1:f1665d79221ea67c1b7fd1b33e8f9165151faaaa Additional testing by jasper@ and pea@ Revert bulk of the FS.base diff, as it causes issues on some machines 2011-04-10T03:56:38Z guenther guenther@openbsd.org 2011-04-10T03:56:38Z urn:sha1:727ed795888fbb6064c3feb84bf592233479836a and the problem isn't obvious yet. Add support for per-rthread base-offset for the %fs selector on amd64. 2011-04-05T21:14:00Z guenther guenther@openbsd.org 2011-04-05T21:14:00Z urn:sha1:2b690be946f8ca8d171b1f34582f3678883d6db3 Add pcb_fsbase to the PCB for tracking what the value for the thread is, and ci_cur_fsbase to struct cpu_info for tracking the CPU's current value for FS.base, then on return to user-space, skip the setting if the CPU has the right value already. Non-threaded processes without TLS leave FS.base zero, which can be conveniently optimized: setting %fs zeros FS.base for fewer cycles than wrmsr. ok kettenis@ 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@.