#
303975 |
|
11-Aug-2016 |
gjb |
Copy stable/11@r303970 to releng/11.0 as part of the 11.0-RELEASE cycle.
Prune svn:mergeinfo from the new branch, and rename it to RC1.
Update __FreeBSD_version.
Use the quarterly branch for the default FreeBSD.conf pkg(8) repo and the dvd1.iso packages population.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
302408 |
|
08-Jul-2016 |
gjb |
Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle. Prune svn:mergeinfo from the new branch, as nothing has been merged here.
Additional commits post-branch will follow.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
|
#
284919 |
|
29-Jun-2015 |
kib |
Add x86 PT_GETFSBASE, PT_GETGSBASE machine-depended ptrace requests to obtain the thread %fs and %gs bases. Add x86 PT_SETFSBASE and PT_SETGSBASE requests to set the bases from debuggers. The set requests, similarly to the sysarch({I386,AMD64}_SET_FSBASE), override the corresponding segment registers.
The main purpose of the operations is to retrieve and modify the tcb address for debuggee.
Sponsored by: The FreeBSD Foundation MFC after: 2 weeks
|
#
278976 |
|
18-Feb-2015 |
jhb |
Ensure that the supplied data length is large enough to hold the base FPU state to avoid passing a negative length to fpusetregs() / npxsetregs().
Differential Revision: https://reviews.freebsd.org/D1861 Reviewed by: kib, emaste
|
#
274817 |
|
21-Nov-2014 |
jhb |
Improve support for XSAVE with debuggers. - Dump an NT_X86_XSTATE note if XSAVE is in use. This note is designed to match what Linux does in that 1) it dumps the entire XSAVE area including the fxsave state, and 2) it stashes a copy of the current xsave mask in the unused padding between the fxsave state and the xstate header at the same location used by Linux. - Teach readelf() to recognize NT_X86_XSTATE notes. - Change PT_GET/SETXSTATE to take the entire XSAVE state instead of only the extra portion. This avoids having to always make two ptrace() calls to get or set the full XSAVE state. - Add a PT_GET_XSTATE_INFO which returns the length of the current XSTATE save area (so the size of the buffer needed for PT_GETXSTATE) and the current XSAVE mask (%xcr0).
Differential Revision: https://reviews.freebsd.org/D1193 Reviewed by: kib MFC after: 2 weeks
|
#
273995 |
|
02-Nov-2014 |
jhb |
MFamd64: Add support for extended FPU states on i386. This includes support for AVX on i386. - Similar to amd64, move the FPU save area out of the PCB and instead store saved FPU state in a variable-sized buffer after the PCB on the stack. - To support the variable PCB location, alter the locore code to only use the bottom-most page of proc0stack for init386(). init386() returns the correct stack pointer to locore which adjusts the stack for thread0 before calling mi_startup(). - Don't bother setting cr3 in thread0's pcb in locore before calling init386(). It wasn't used (init386() overwrote it at the end) and it doesn't work with the variable-sized FPU save area. - Remove the new-bus attachment from npx. This was only ever useful for external co-processors using IRQ13, but those have not been supported for several years. npxinit() is now called much earlier during boot (init386()) similar to amd64. - Implement PT_{GET,SET}XSTATE and I386_GET_XFPUSTATE. - npxsave() is now only called from context switch contexts so it can use XSAVEOPT.
Differential Revision: https://reviews.freebsd.org/D1058 Reviewed by: kib Tested on: FreeBSD/i386 VM under bhyve on Intel i5-2520
|
#
238675 |
|
21-Jul-2012 |
kib |
MFamd64 r238669: Force clean FPU state in PCB user FPU save area for PT_I386_{GET,SET}XMMREGS.
Reported by: bde MFC after: 1 week
|
#
208833 |
|
05-Jun-2010 |
kib |
Introduce the x86 kernel interfaces to allow kernel code to use FPU/SSE hardware. Caller should provide a save area that is chained into the stack of the areas; pcb save_area for usermode FPU state is on top. The pcb now contains a pointer to the current FPU saved area, used during FPUDNA handling and context switches. There is also a facility to allow the kernel thread to use pcb save_area.
Change the dreaded warnings "npxdna in kernel mode!" into the panics when FPU usage is not registered.
KPI discussed with: fabient Tested by: pho, fabient Hardware provided by: Sentex Communications MFC after: 1 month
|
#
159087 |
|
30-May-2006 |
davidxu |
Use the method described in IA-32 Intel Architecture Software Developer's Manual chapter 11.6.6 to get valid mxcsr bits, use the mxcsr mask to clear invalid bits passed by user code.
Reviewed by: bde
|
#
159000 |
|
28-May-2006 |
davidxu |
Clear high 16 bits of mxcsr register, according to Intel document, if the high 16 bits is non-zero, fxrstor instruction will generate GP fault, resulting kernel crash, this bug can be triggered by setcontext and ptrace(PT_SETXMMREGS).
|
#
148694 |
|
04-Aug-2005 |
tobez |
Make kernel build suceed when with "options CPU_DISABLE_SSE".
PR: 84010 Submitted by: Sergey Gluschenko <deen@freebsd.org.ua> MFC after: 1 week
|
#
147741 |
|
02-Jul-2005 |
delphij |
Remove the CPU_ENABLE_SSE option from the i386 and pc98 architectures, as they are already default for I686_CPU for almost 3 years, and CPU_DISABLE_SSE always disables it. On the other hand, CPU_ENABLE_SSE does not work for I486_CPU and I586_CPU.
This commit has: - Removed the option from conf/options.* - Removed the option and comments from MD NOTES files - Simplified the CPU_ENABLE_SSE ifdef's so they don't deal with CPU_ENABLE_SSE from kernel configuration. (*)
For most users, this commit should be largely no-op. If you used to place CPU_ENABLE_SSE into your kernel configuration for some reason, it is time to remove it.
(*) The ifdef's of CPU_ENABLE_SSE are not removed at this point, since we need to change it to !defined(CPU_DISABLE_SSE) && defined(I686_CPU), not just !defined(CPU_DISABLE_SSE), if we really want to do so.
Discussed on: -arch Approved by: re (scottl)
|
#
146959 |
|
04-Jun-2005 |
dfr |
Add the proper logic so that we don't try to do SSE stuff unless its enabled.
|
#
146818 |
|
31-May-2005 |
dfr |
Add support for XMM registers in GDB for x86 processors that support SSE (or its successors).
Reviewed by: marcel, davidxu MFC After: 2 weeks
|