You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

cpu-intel.c 9.9 KiB

Replace cpuid assembly with C code. Rather, take a leaf out of Chromium's book and use MSVC's __cpuid and _xgetbv built-in, with an inline assembly emulated version for other compilers. This preserves the behavior of the original assembly with the following differences: - CPUs without cpuid aren't support. Chromium's base/cpu.cc doesn't check, and SSE2 support is part of our baseline; the perlasm code is always built with OPENSSL_IA32_SSE2. - The clear_xmm block in cpu-x86-asm.pl is removed. This was used to clear some XMM-using features if OSXSAVE was set but XCR0 reports the OS doesn't use XSAVE to store SSE state. This wasn't present in the x86_64 and seems wrong. Section 13.5.2 of the Intel manual, volume 1, explicitly says SSE may still be used in this case; the OS may save that state in FXSAVE instead. A side discussion on upstream's RT#2633 agrees. - The old code ran some AMD CPUs through the "intel" codepath and some went straight to "generic" after duplicating some, but not all, logic. The AMD copy didn't clear some reserved bits and didn't query CPUID 7 for AVX2 support. This is moot since AMD CPUs today don't support AVX2, but it seems they're expected to in the future? - Setting bit 10 is dropped. This doesn't appear to be queried anywhere, was 32-bit only, and seems a remnant of upstream's 14e21f863a3e3278bb8660ea9844e92e52e1f2f7. Change-Id: I0548877c97e997f7beb25e15f3fea71c68a951d2 Reviewed-on: https://boringssl-review.googlesource.com/5434 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Replace cpuid assembly with C code. Rather, take a leaf out of Chromium's book and use MSVC's __cpuid and _xgetbv built-in, with an inline assembly emulated version for other compilers. This preserves the behavior of the original assembly with the following differences: - CPUs without cpuid aren't support. Chromium's base/cpu.cc doesn't check, and SSE2 support is part of our baseline; the perlasm code is always built with OPENSSL_IA32_SSE2. - The clear_xmm block in cpu-x86-asm.pl is removed. This was used to clear some XMM-using features if OSXSAVE was set but XCR0 reports the OS doesn't use XSAVE to store SSE state. This wasn't present in the x86_64 and seems wrong. Section 13.5.2 of the Intel manual, volume 1, explicitly says SSE may still be used in this case; the OS may save that state in FXSAVE instead. A side discussion on upstream's RT#2633 agrees. - The old code ran some AMD CPUs through the "intel" codepath and some went straight to "generic" after duplicating some, but not all, logic. The AMD copy didn't clear some reserved bits and didn't query CPUID 7 for AVX2 support. This is moot since AMD CPUs today don't support AVX2, but it seems they're expected to in the future? - Setting bit 10 is dropped. This doesn't appear to be queried anywhere, was 32-bit only, and seems a remnant of upstream's 14e21f863a3e3278bb8660ea9844e92e52e1f2f7. Change-Id: I0548877c97e997f7beb25e15f3fea71c68a951d2 Reviewed-on: https://boringssl-review.googlesource.com/5434 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Replace cpuid assembly with C code. Rather, take a leaf out of Chromium's book and use MSVC's __cpuid and _xgetbv built-in, with an inline assembly emulated version for other compilers. This preserves the behavior of the original assembly with the following differences: - CPUs without cpuid aren't support. Chromium's base/cpu.cc doesn't check, and SSE2 support is part of our baseline; the perlasm code is always built with OPENSSL_IA32_SSE2. - The clear_xmm block in cpu-x86-asm.pl is removed. This was used to clear some XMM-using features if OSXSAVE was set but XCR0 reports the OS doesn't use XSAVE to store SSE state. This wasn't present in the x86_64 and seems wrong. Section 13.5.2 of the Intel manual, volume 1, explicitly says SSE may still be used in this case; the OS may save that state in FXSAVE instead. A side discussion on upstream's RT#2633 agrees. - The old code ran some AMD CPUs through the "intel" codepath and some went straight to "generic" after duplicating some, but not all, logic. The AMD copy didn't clear some reserved bits and didn't query CPUID 7 for AVX2 support. This is moot since AMD CPUs today don't support AVX2, but it seems they're expected to in the future? - Setting bit 10 is dropped. This doesn't appear to be queried anywhere, was 32-bit only, and seems a remnant of upstream's 14e21f863a3e3278bb8660ea9844e92e52e1f2f7. Change-Id: I0548877c97e997f7beb25e15f3fea71c68a951d2 Reviewed-on: https://boringssl-review.googlesource.com/5434 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Replace cpuid assembly with C code. Rather, take a leaf out of Chromium's book and use MSVC's __cpuid and _xgetbv built-in, with an inline assembly emulated version for other compilers. This preserves the behavior of the original assembly with the following differences: - CPUs without cpuid aren't support. Chromium's base/cpu.cc doesn't check, and SSE2 support is part of our baseline; the perlasm code is always built with OPENSSL_IA32_SSE2. - The clear_xmm block in cpu-x86-asm.pl is removed. This was used to clear some XMM-using features if OSXSAVE was set but XCR0 reports the OS doesn't use XSAVE to store SSE state. This wasn't present in the x86_64 and seems wrong. Section 13.5.2 of the Intel manual, volume 1, explicitly says SSE may still be used in this case; the OS may save that state in FXSAVE instead. A side discussion on upstream's RT#2633 agrees. - The old code ran some AMD CPUs through the "intel" codepath and some went straight to "generic" after duplicating some, but not all, logic. The AMD copy didn't clear some reserved bits and didn't query CPUID 7 for AVX2 support. This is moot since AMD CPUs today don't support AVX2, but it seems they're expected to in the future? - Setting bit 10 is dropped. This doesn't appear to be queried anywhere, was 32-bit only, and seems a remnant of upstream's 14e21f863a3e3278bb8660ea9844e92e52e1f2f7. Change-Id: I0548877c97e997f7beb25e15f3fea71c68a951d2 Reviewed-on: https://boringssl-review.googlesource.com/5434 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Replace cpuid assembly with C code. Rather, take a leaf out of Chromium's book and use MSVC's __cpuid and _xgetbv built-in, with an inline assembly emulated version for other compilers. This preserves the behavior of the original assembly with the following differences: - CPUs without cpuid aren't support. Chromium's base/cpu.cc doesn't check, and SSE2 support is part of our baseline; the perlasm code is always built with OPENSSL_IA32_SSE2. - The clear_xmm block in cpu-x86-asm.pl is removed. This was used to clear some XMM-using features if OSXSAVE was set but XCR0 reports the OS doesn't use XSAVE to store SSE state. This wasn't present in the x86_64 and seems wrong. Section 13.5.2 of the Intel manual, volume 1, explicitly says SSE may still be used in this case; the OS may save that state in FXSAVE instead. A side discussion on upstream's RT#2633 agrees. - The old code ran some AMD CPUs through the "intel" codepath and some went straight to "generic" after duplicating some, but not all, logic. The AMD copy didn't clear some reserved bits and didn't query CPUID 7 for AVX2 support. This is moot since AMD CPUs today don't support AVX2, but it seems they're expected to in the future? - Setting bit 10 is dropped. This doesn't appear to be queried anywhere, was 32-bit only, and seems a remnant of upstream's 14e21f863a3e3278bb8660ea9844e92e52e1f2f7. Change-Id: I0548877c97e997f7beb25e15f3fea71c68a951d2 Reviewed-on: https://boringssl-review.googlesource.com/5434 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Replace cpuid assembly with C code. Rather, take a leaf out of Chromium's book and use MSVC's __cpuid and _xgetbv built-in, with an inline assembly emulated version for other compilers. This preserves the behavior of the original assembly with the following differences: - CPUs without cpuid aren't support. Chromium's base/cpu.cc doesn't check, and SSE2 support is part of our baseline; the perlasm code is always built with OPENSSL_IA32_SSE2. - The clear_xmm block in cpu-x86-asm.pl is removed. This was used to clear some XMM-using features if OSXSAVE was set but XCR0 reports the OS doesn't use XSAVE to store SSE state. This wasn't present in the x86_64 and seems wrong. Section 13.5.2 of the Intel manual, volume 1, explicitly says SSE may still be used in this case; the OS may save that state in FXSAVE instead. A side discussion on upstream's RT#2633 agrees. - The old code ran some AMD CPUs through the "intel" codepath and some went straight to "generic" after duplicating some, but not all, logic. The AMD copy didn't clear some reserved bits and didn't query CPUID 7 for AVX2 support. This is moot since AMD CPUs today don't support AVX2, but it seems they're expected to in the future? - Setting bit 10 is dropped. This doesn't appear to be queried anywhere, was 32-bit only, and seems a remnant of upstream's 14e21f863a3e3278bb8660ea9844e92e52e1f2f7. Change-Id: I0548877c97e997f7beb25e15f3fea71c68a951d2 Reviewed-on: https://boringssl-review.googlesource.com/5434 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Replace cpuid assembly with C code. Rather, take a leaf out of Chromium's book and use MSVC's __cpuid and _xgetbv built-in, with an inline assembly emulated version for other compilers. This preserves the behavior of the original assembly with the following differences: - CPUs without cpuid aren't support. Chromium's base/cpu.cc doesn't check, and SSE2 support is part of our baseline; the perlasm code is always built with OPENSSL_IA32_SSE2. - The clear_xmm block in cpu-x86-asm.pl is removed. This was used to clear some XMM-using features if OSXSAVE was set but XCR0 reports the OS doesn't use XSAVE to store SSE state. This wasn't present in the x86_64 and seems wrong. Section 13.5.2 of the Intel manual, volume 1, explicitly says SSE may still be used in this case; the OS may save that state in FXSAVE instead. A side discussion on upstream's RT#2633 agrees. - The old code ran some AMD CPUs through the "intel" codepath and some went straight to "generic" after duplicating some, but not all, logic. The AMD copy didn't clear some reserved bits and didn't query CPUID 7 for AVX2 support. This is moot since AMD CPUs today don't support AVX2, but it seems they're expected to in the future? - Setting bit 10 is dropped. This doesn't appear to be queried anywhere, was 32-bit only, and seems a remnant of upstream's 14e21f863a3e3278bb8660ea9844e92e52e1f2f7. Change-Id: I0548877c97e997f7beb25e15f3fea71c68a951d2 Reviewed-on: https://boringssl-review.googlesource.com/5434 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Replace cpuid assembly with C code. Rather, take a leaf out of Chromium's book and use MSVC's __cpuid and _xgetbv built-in, with an inline assembly emulated version for other compilers. This preserves the behavior of the original assembly with the following differences: - CPUs without cpuid aren't support. Chromium's base/cpu.cc doesn't check, and SSE2 support is part of our baseline; the perlasm code is always built with OPENSSL_IA32_SSE2. - The clear_xmm block in cpu-x86-asm.pl is removed. This was used to clear some XMM-using features if OSXSAVE was set but XCR0 reports the OS doesn't use XSAVE to store SSE state. This wasn't present in the x86_64 and seems wrong. Section 13.5.2 of the Intel manual, volume 1, explicitly says SSE may still be used in this case; the OS may save that state in FXSAVE instead. A side discussion on upstream's RT#2633 agrees. - The old code ran some AMD CPUs through the "intel" codepath and some went straight to "generic" after duplicating some, but not all, logic. The AMD copy didn't clear some reserved bits and didn't query CPUID 7 for AVX2 support. This is moot since AMD CPUs today don't support AVX2, but it seems they're expected to in the future? - Setting bit 10 is dropped. This doesn't appear to be queried anywhere, was 32-bit only, and seems a remnant of upstream's 14e21f863a3e3278bb8660ea9844e92e52e1f2f7. Change-Id: I0548877c97e997f7beb25e15f3fea71c68a951d2 Reviewed-on: https://boringssl-review.googlesource.com/5434 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Replace cpuid assembly with C code. Rather, take a leaf out of Chromium's book and use MSVC's __cpuid and _xgetbv built-in, with an inline assembly emulated version for other compilers. This preserves the behavior of the original assembly with the following differences: - CPUs without cpuid aren't support. Chromium's base/cpu.cc doesn't check, and SSE2 support is part of our baseline; the perlasm code is always built with OPENSSL_IA32_SSE2. - The clear_xmm block in cpu-x86-asm.pl is removed. This was used to clear some XMM-using features if OSXSAVE was set but XCR0 reports the OS doesn't use XSAVE to store SSE state. This wasn't present in the x86_64 and seems wrong. Section 13.5.2 of the Intel manual, volume 1, explicitly says SSE may still be used in this case; the OS may save that state in FXSAVE instead. A side discussion on upstream's RT#2633 agrees. - The old code ran some AMD CPUs through the "intel" codepath and some went straight to "generic" after duplicating some, but not all, logic. The AMD copy didn't clear some reserved bits and didn't query CPUID 7 for AVX2 support. This is moot since AMD CPUs today don't support AVX2, but it seems they're expected to in the future? - Setting bit 10 is dropped. This doesn't appear to be queried anywhere, was 32-bit only, and seems a remnant of upstream's 14e21f863a3e3278bb8660ea9844e92e52e1f2f7. Change-Id: I0548877c97e997f7beb25e15f3fea71c68a951d2 Reviewed-on: https://boringssl-review.googlesource.com/5434 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Replace cpuid assembly with C code. Rather, take a leaf out of Chromium's book and use MSVC's __cpuid and _xgetbv built-in, with an inline assembly emulated version for other compilers. This preserves the behavior of the original assembly with the following differences: - CPUs without cpuid aren't support. Chromium's base/cpu.cc doesn't check, and SSE2 support is part of our baseline; the perlasm code is always built with OPENSSL_IA32_SSE2. - The clear_xmm block in cpu-x86-asm.pl is removed. This was used to clear some XMM-using features if OSXSAVE was set but XCR0 reports the OS doesn't use XSAVE to store SSE state. This wasn't present in the x86_64 and seems wrong. Section 13.5.2 of the Intel manual, volume 1, explicitly says SSE may still be used in this case; the OS may save that state in FXSAVE instead. A side discussion on upstream's RT#2633 agrees. - The old code ran some AMD CPUs through the "intel" codepath and some went straight to "generic" after duplicating some, but not all, logic. The AMD copy didn't clear some reserved bits and didn't query CPUID 7 for AVX2 support. This is moot since AMD CPUs today don't support AVX2, but it seems they're expected to in the future? - Setting bit 10 is dropped. This doesn't appear to be queried anywhere, was 32-bit only, and seems a remnant of upstream's 14e21f863a3e3278bb8660ea9844e92e52e1f2f7. Change-Id: I0548877c97e997f7beb25e15f3fea71c68a951d2 Reviewed-on: https://boringssl-review.googlesource.com/5434 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Replace cpuid assembly with C code. Rather, take a leaf out of Chromium's book and use MSVC's __cpuid and _xgetbv built-in, with an inline assembly emulated version for other compilers. This preserves the behavior of the original assembly with the following differences: - CPUs without cpuid aren't support. Chromium's base/cpu.cc doesn't check, and SSE2 support is part of our baseline; the perlasm code is always built with OPENSSL_IA32_SSE2. - The clear_xmm block in cpu-x86-asm.pl is removed. This was used to clear some XMM-using features if OSXSAVE was set but XCR0 reports the OS doesn't use XSAVE to store SSE state. This wasn't present in the x86_64 and seems wrong. Section 13.5.2 of the Intel manual, volume 1, explicitly says SSE may still be used in this case; the OS may save that state in FXSAVE instead. A side discussion on upstream's RT#2633 agrees. - The old code ran some AMD CPUs through the "intel" codepath and some went straight to "generic" after duplicating some, but not all, logic. The AMD copy didn't clear some reserved bits and didn't query CPUID 7 for AVX2 support. This is moot since AMD CPUs today don't support AVX2, but it seems they're expected to in the future? - Setting bit 10 is dropped. This doesn't appear to be queried anywhere, was 32-bit only, and seems a remnant of upstream's 14e21f863a3e3278bb8660ea9844e92e52e1f2f7. Change-Id: I0548877c97e997f7beb25e15f3fea71c68a951d2 Reviewed-on: https://boringssl-review.googlesource.com/5434 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Replace cpuid assembly with C code. Rather, take a leaf out of Chromium's book and use MSVC's __cpuid and _xgetbv built-in, with an inline assembly emulated version for other compilers. This preserves the behavior of the original assembly with the following differences: - CPUs without cpuid aren't support. Chromium's base/cpu.cc doesn't check, and SSE2 support is part of our baseline; the perlasm code is always built with OPENSSL_IA32_SSE2. - The clear_xmm block in cpu-x86-asm.pl is removed. This was used to clear some XMM-using features if OSXSAVE was set but XCR0 reports the OS doesn't use XSAVE to store SSE state. This wasn't present in the x86_64 and seems wrong. Section 13.5.2 of the Intel manual, volume 1, explicitly says SSE may still be used in this case; the OS may save that state in FXSAVE instead. A side discussion on upstream's RT#2633 agrees. - The old code ran some AMD CPUs through the "intel" codepath and some went straight to "generic" after duplicating some, but not all, logic. The AMD copy didn't clear some reserved bits and didn't query CPUID 7 for AVX2 support. This is moot since AMD CPUs today don't support AVX2, but it seems they're expected to in the future? - Setting bit 10 is dropped. This doesn't appear to be queried anywhere, was 32-bit only, and seems a remnant of upstream's 14e21f863a3e3278bb8660ea9844e92e52e1f2f7. Change-Id: I0548877c97e997f7beb25e15f3fea71c68a951d2 Reviewed-on: https://boringssl-review.googlesource.com/5434 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Replace cpuid assembly with C code. Rather, take a leaf out of Chromium's book and use MSVC's __cpuid and _xgetbv built-in, with an inline assembly emulated version for other compilers. This preserves the behavior of the original assembly with the following differences: - CPUs without cpuid aren't support. Chromium's base/cpu.cc doesn't check, and SSE2 support is part of our baseline; the perlasm code is always built with OPENSSL_IA32_SSE2. - The clear_xmm block in cpu-x86-asm.pl is removed. This was used to clear some XMM-using features if OSXSAVE was set but XCR0 reports the OS doesn't use XSAVE to store SSE state. This wasn't present in the x86_64 and seems wrong. Section 13.5.2 of the Intel manual, volume 1, explicitly says SSE may still be used in this case; the OS may save that state in FXSAVE instead. A side discussion on upstream's RT#2633 agrees. - The old code ran some AMD CPUs through the "intel" codepath and some went straight to "generic" after duplicating some, but not all, logic. The AMD copy didn't clear some reserved bits and didn't query CPUID 7 for AVX2 support. This is moot since AMD CPUs today don't support AVX2, but it seems they're expected to in the future? - Setting bit 10 is dropped. This doesn't appear to be queried anywhere, was 32-bit only, and seems a remnant of upstream's 14e21f863a3e3278bb8660ea9844e92e52e1f2f7. Change-Id: I0548877c97e997f7beb25e15f3fea71c68a951d2 Reviewed-on: https://boringssl-review.googlesource.com/5434 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Replace cpuid assembly with C code. Rather, take a leaf out of Chromium's book and use MSVC's __cpuid and _xgetbv built-in, with an inline assembly emulated version for other compilers. This preserves the behavior of the original assembly with the following differences: - CPUs without cpuid aren't support. Chromium's base/cpu.cc doesn't check, and SSE2 support is part of our baseline; the perlasm code is always built with OPENSSL_IA32_SSE2. - The clear_xmm block in cpu-x86-asm.pl is removed. This was used to clear some XMM-using features if OSXSAVE was set but XCR0 reports the OS doesn't use XSAVE to store SSE state. This wasn't present in the x86_64 and seems wrong. Section 13.5.2 of the Intel manual, volume 1, explicitly says SSE may still be used in this case; the OS may save that state in FXSAVE instead. A side discussion on upstream's RT#2633 agrees. - The old code ran some AMD CPUs through the "intel" codepath and some went straight to "generic" after duplicating some, but not all, logic. The AMD copy didn't clear some reserved bits and didn't query CPUID 7 for AVX2 support. This is moot since AMD CPUs today don't support AVX2, but it seems they're expected to in the future? - Setting bit 10 is dropped. This doesn't appear to be queried anywhere, was 32-bit only, and seems a remnant of upstream's 14e21f863a3e3278bb8660ea9844e92e52e1f2f7. Change-Id: I0548877c97e997f7beb25e15f3fea71c68a951d2 Reviewed-on: https://boringssl-review.googlesource.com/5434 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Replace cpuid assembly with C code. Rather, take a leaf out of Chromium's book and use MSVC's __cpuid and _xgetbv built-in, with an inline assembly emulated version for other compilers. This preserves the behavior of the original assembly with the following differences: - CPUs without cpuid aren't support. Chromium's base/cpu.cc doesn't check, and SSE2 support is part of our baseline; the perlasm code is always built with OPENSSL_IA32_SSE2. - The clear_xmm block in cpu-x86-asm.pl is removed. This was used to clear some XMM-using features if OSXSAVE was set but XCR0 reports the OS doesn't use XSAVE to store SSE state. This wasn't present in the x86_64 and seems wrong. Section 13.5.2 of the Intel manual, volume 1, explicitly says SSE may still be used in this case; the OS may save that state in FXSAVE instead. A side discussion on upstream's RT#2633 agrees. - The old code ran some AMD CPUs through the "intel" codepath and some went straight to "generic" after duplicating some, but not all, logic. The AMD copy didn't clear some reserved bits and didn't query CPUID 7 for AVX2 support. This is moot since AMD CPUs today don't support AVX2, but it seems they're expected to in the future? - Setting bit 10 is dropped. This doesn't appear to be queried anywhere, was 32-bit only, and seems a remnant of upstream's 14e21f863a3e3278bb8660ea9844e92e52e1f2f7. Change-Id: I0548877c97e997f7beb25e15f3fea71c68a951d2 Reviewed-on: https://boringssl-review.googlesource.com/5434 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Replace cpuid assembly with C code. Rather, take a leaf out of Chromium's book and use MSVC's __cpuid and _xgetbv built-in, with an inline assembly emulated version for other compilers. This preserves the behavior of the original assembly with the following differences: - CPUs without cpuid aren't support. Chromium's base/cpu.cc doesn't check, and SSE2 support is part of our baseline; the perlasm code is always built with OPENSSL_IA32_SSE2. - The clear_xmm block in cpu-x86-asm.pl is removed. This was used to clear some XMM-using features if OSXSAVE was set but XCR0 reports the OS doesn't use XSAVE to store SSE state. This wasn't present in the x86_64 and seems wrong. Section 13.5.2 of the Intel manual, volume 1, explicitly says SSE may still be used in this case; the OS may save that state in FXSAVE instead. A side discussion on upstream's RT#2633 agrees. - The old code ran some AMD CPUs through the "intel" codepath and some went straight to "generic" after duplicating some, but not all, logic. The AMD copy didn't clear some reserved bits and didn't query CPUID 7 for AVX2 support. This is moot since AMD CPUs today don't support AVX2, but it seems they're expected to in the future? - Setting bit 10 is dropped. This doesn't appear to be queried anywhere, was 32-bit only, and seems a remnant of upstream's 14e21f863a3e3278bb8660ea9844e92e52e1f2f7. Change-Id: I0548877c97e997f7beb25e15f3fea71c68a951d2 Reviewed-on: https://boringssl-review.googlesource.com/5434 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Replace cpuid assembly with C code. Rather, take a leaf out of Chromium's book and use MSVC's __cpuid and _xgetbv built-in, with an inline assembly emulated version for other compilers. This preserves the behavior of the original assembly with the following differences: - CPUs without cpuid aren't support. Chromium's base/cpu.cc doesn't check, and SSE2 support is part of our baseline; the perlasm code is always built with OPENSSL_IA32_SSE2. - The clear_xmm block in cpu-x86-asm.pl is removed. This was used to clear some XMM-using features if OSXSAVE was set but XCR0 reports the OS doesn't use XSAVE to store SSE state. This wasn't present in the x86_64 and seems wrong. Section 13.5.2 of the Intel manual, volume 1, explicitly says SSE may still be used in this case; the OS may save that state in FXSAVE instead. A side discussion on upstream's RT#2633 agrees. - The old code ran some AMD CPUs through the "intel" codepath and some went straight to "generic" after duplicating some, but not all, logic. The AMD copy didn't clear some reserved bits and didn't query CPUID 7 for AVX2 support. This is moot since AMD CPUs today don't support AVX2, but it seems they're expected to in the future? - Setting bit 10 is dropped. This doesn't appear to be queried anywhere, was 32-bit only, and seems a remnant of upstream's 14e21f863a3e3278bb8660ea9844e92e52e1f2f7. Change-Id: I0548877c97e997f7beb25e15f3fea71c68a951d2 Reviewed-on: https://boringssl-review.googlesource.com/5434 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Replace cpuid assembly with C code. Rather, take a leaf out of Chromium's book and use MSVC's __cpuid and _xgetbv built-in, with an inline assembly emulated version for other compilers. This preserves the behavior of the original assembly with the following differences: - CPUs without cpuid aren't support. Chromium's base/cpu.cc doesn't check, and SSE2 support is part of our baseline; the perlasm code is always built with OPENSSL_IA32_SSE2. - The clear_xmm block in cpu-x86-asm.pl is removed. This was used to clear some XMM-using features if OSXSAVE was set but XCR0 reports the OS doesn't use XSAVE to store SSE state. This wasn't present in the x86_64 and seems wrong. Section 13.5.2 of the Intel manual, volume 1, explicitly says SSE may still be used in this case; the OS may save that state in FXSAVE instead. A side discussion on upstream's RT#2633 agrees. - The old code ran some AMD CPUs through the "intel" codepath and some went straight to "generic" after duplicating some, but not all, logic. The AMD copy didn't clear some reserved bits and didn't query CPUID 7 for AVX2 support. This is moot since AMD CPUs today don't support AVX2, but it seems they're expected to in the future? - Setting bit 10 is dropped. This doesn't appear to be queried anywhere, was 32-bit only, and seems a remnant of upstream's 14e21f863a3e3278bb8660ea9844e92e52e1f2f7. Change-Id: I0548877c97e997f7beb25e15f3fea71c68a951d2 Reviewed-on: https://boringssl-review.googlesource.com/5434 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Replace cpuid assembly with C code. Rather, take a leaf out of Chromium's book and use MSVC's __cpuid and _xgetbv built-in, with an inline assembly emulated version for other compilers. This preserves the behavior of the original assembly with the following differences: - CPUs without cpuid aren't support. Chromium's base/cpu.cc doesn't check, and SSE2 support is part of our baseline; the perlasm code is always built with OPENSSL_IA32_SSE2. - The clear_xmm block in cpu-x86-asm.pl is removed. This was used to clear some XMM-using features if OSXSAVE was set but XCR0 reports the OS doesn't use XSAVE to store SSE state. This wasn't present in the x86_64 and seems wrong. Section 13.5.2 of the Intel manual, volume 1, explicitly says SSE may still be used in this case; the OS may save that state in FXSAVE instead. A side discussion on upstream's RT#2633 agrees. - The old code ran some AMD CPUs through the "intel" codepath and some went straight to "generic" after duplicating some, but not all, logic. The AMD copy didn't clear some reserved bits and didn't query CPUID 7 for AVX2 support. This is moot since AMD CPUs today don't support AVX2, but it seems they're expected to in the future? - Setting bit 10 is dropped. This doesn't appear to be queried anywhere, was 32-bit only, and seems a remnant of upstream's 14e21f863a3e3278bb8660ea9844e92e52e1f2f7. Change-Id: I0548877c97e997f7beb25e15f3fea71c68a951d2 Reviewed-on: https://boringssl-review.googlesource.com/5434 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Replace cpuid assembly with C code. Rather, take a leaf out of Chromium's book and use MSVC's __cpuid and _xgetbv built-in, with an inline assembly emulated version for other compilers. This preserves the behavior of the original assembly with the following differences: - CPUs without cpuid aren't support. Chromium's base/cpu.cc doesn't check, and SSE2 support is part of our baseline; the perlasm code is always built with OPENSSL_IA32_SSE2. - The clear_xmm block in cpu-x86-asm.pl is removed. This was used to clear some XMM-using features if OSXSAVE was set but XCR0 reports the OS doesn't use XSAVE to store SSE state. This wasn't present in the x86_64 and seems wrong. Section 13.5.2 of the Intel manual, volume 1, explicitly says SSE may still be used in this case; the OS may save that state in FXSAVE instead. A side discussion on upstream's RT#2633 agrees. - The old code ran some AMD CPUs through the "intel" codepath and some went straight to "generic" after duplicating some, but not all, logic. The AMD copy didn't clear some reserved bits and didn't query CPUID 7 for AVX2 support. This is moot since AMD CPUs today don't support AVX2, but it seems they're expected to in the future? - Setting bit 10 is dropped. This doesn't appear to be queried anywhere, was 32-bit only, and seems a remnant of upstream's 14e21f863a3e3278bb8660ea9844e92e52e1f2f7. Change-Id: I0548877c97e997f7beb25e15f3fea71c68a951d2 Reviewed-on: https://boringssl-review.googlesource.com/5434 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Replace cpuid assembly with C code. Rather, take a leaf out of Chromium's book and use MSVC's __cpuid and _xgetbv built-in, with an inline assembly emulated version for other compilers. This preserves the behavior of the original assembly with the following differences: - CPUs without cpuid aren't support. Chromium's base/cpu.cc doesn't check, and SSE2 support is part of our baseline; the perlasm code is always built with OPENSSL_IA32_SSE2. - The clear_xmm block in cpu-x86-asm.pl is removed. This was used to clear some XMM-using features if OSXSAVE was set but XCR0 reports the OS doesn't use XSAVE to store SSE state. This wasn't present in the x86_64 and seems wrong. Section 13.5.2 of the Intel manual, volume 1, explicitly says SSE may still be used in this case; the OS may save that state in FXSAVE instead. A side discussion on upstream's RT#2633 agrees. - The old code ran some AMD CPUs through the "intel" codepath and some went straight to "generic" after duplicating some, but not all, logic. The AMD copy didn't clear some reserved bits and didn't query CPUID 7 for AVX2 support. This is moot since AMD CPUs today don't support AVX2, but it seems they're expected to in the future? - Setting bit 10 is dropped. This doesn't appear to be queried anywhere, was 32-bit only, and seems a remnant of upstream's 14e21f863a3e3278bb8660ea9844e92e52e1f2f7. Change-Id: I0548877c97e997f7beb25e15f3fea71c68a951d2 Reviewed-on: https://boringssl-review.googlesource.com/5434 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Replace cpuid assembly with C code. Rather, take a leaf out of Chromium's book and use MSVC's __cpuid and _xgetbv built-in, with an inline assembly emulated version for other compilers. This preserves the behavior of the original assembly with the following differences: - CPUs without cpuid aren't support. Chromium's base/cpu.cc doesn't check, and SSE2 support is part of our baseline; the perlasm code is always built with OPENSSL_IA32_SSE2. - The clear_xmm block in cpu-x86-asm.pl is removed. This was used to clear some XMM-using features if OSXSAVE was set but XCR0 reports the OS doesn't use XSAVE to store SSE state. This wasn't present in the x86_64 and seems wrong. Section 13.5.2 of the Intel manual, volume 1, explicitly says SSE may still be used in this case; the OS may save that state in FXSAVE instead. A side discussion on upstream's RT#2633 agrees. - The old code ran some AMD CPUs through the "intel" codepath and some went straight to "generic" after duplicating some, but not all, logic. The AMD copy didn't clear some reserved bits and didn't query CPUID 7 for AVX2 support. This is moot since AMD CPUs today don't support AVX2, but it seems they're expected to in the future? - Setting bit 10 is dropped. This doesn't appear to be queried anywhere, was 32-bit only, and seems a remnant of upstream's 14e21f863a3e3278bb8660ea9844e92e52e1f2f7. Change-Id: I0548877c97e997f7beb25e15f3fea71c68a951d2 Reviewed-on: https://boringssl-review.googlesource.com/5434 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Replace cpuid assembly with C code. Rather, take a leaf out of Chromium's book and use MSVC's __cpuid and _xgetbv built-in, with an inline assembly emulated version for other compilers. This preserves the behavior of the original assembly with the following differences: - CPUs without cpuid aren't support. Chromium's base/cpu.cc doesn't check, and SSE2 support is part of our baseline; the perlasm code is always built with OPENSSL_IA32_SSE2. - The clear_xmm block in cpu-x86-asm.pl is removed. This was used to clear some XMM-using features if OSXSAVE was set but XCR0 reports the OS doesn't use XSAVE to store SSE state. This wasn't present in the x86_64 and seems wrong. Section 13.5.2 of the Intel manual, volume 1, explicitly says SSE may still be used in this case; the OS may save that state in FXSAVE instead. A side discussion on upstream's RT#2633 agrees. - The old code ran some AMD CPUs through the "intel" codepath and some went straight to "generic" after duplicating some, but not all, logic. The AMD copy didn't clear some reserved bits and didn't query CPUID 7 for AVX2 support. This is moot since AMD CPUs today don't support AVX2, but it seems they're expected to in the future? - Setting bit 10 is dropped. This doesn't appear to be queried anywhere, was 32-bit only, and seems a remnant of upstream's 14e21f863a3e3278bb8660ea9844e92e52e1f2f7. Change-Id: I0548877c97e997f7beb25e15f3fea71c68a951d2 Reviewed-on: https://boringssl-review.googlesource.com/5434 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Replace cpuid assembly with C code. Rather, take a leaf out of Chromium's book and use MSVC's __cpuid and _xgetbv built-in, with an inline assembly emulated version for other compilers. This preserves the behavior of the original assembly with the following differences: - CPUs without cpuid aren't support. Chromium's base/cpu.cc doesn't check, and SSE2 support is part of our baseline; the perlasm code is always built with OPENSSL_IA32_SSE2. - The clear_xmm block in cpu-x86-asm.pl is removed. This was used to clear some XMM-using features if OSXSAVE was set but XCR0 reports the OS doesn't use XSAVE to store SSE state. This wasn't present in the x86_64 and seems wrong. Section 13.5.2 of the Intel manual, volume 1, explicitly says SSE may still be used in this case; the OS may save that state in FXSAVE instead. A side discussion on upstream's RT#2633 agrees. - The old code ran some AMD CPUs through the "intel" codepath and some went straight to "generic" after duplicating some, but not all, logic. The AMD copy didn't clear some reserved bits and didn't query CPUID 7 for AVX2 support. This is moot since AMD CPUs today don't support AVX2, but it seems they're expected to in the future? - Setting bit 10 is dropped. This doesn't appear to be queried anywhere, was 32-bit only, and seems a remnant of upstream's 14e21f863a3e3278bb8660ea9844e92e52e1f2f7. Change-Id: I0548877c97e997f7beb25e15f3fea71c68a951d2 Reviewed-on: https://boringssl-review.googlesource.com/5434 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Replace cpuid assembly with C code. Rather, take a leaf out of Chromium's book and use MSVC's __cpuid and _xgetbv built-in, with an inline assembly emulated version for other compilers. This preserves the behavior of the original assembly with the following differences: - CPUs without cpuid aren't support. Chromium's base/cpu.cc doesn't check, and SSE2 support is part of our baseline; the perlasm code is always built with OPENSSL_IA32_SSE2. - The clear_xmm block in cpu-x86-asm.pl is removed. This was used to clear some XMM-using features if OSXSAVE was set but XCR0 reports the OS doesn't use XSAVE to store SSE state. This wasn't present in the x86_64 and seems wrong. Section 13.5.2 of the Intel manual, volume 1, explicitly says SSE may still be used in this case; the OS may save that state in FXSAVE instead. A side discussion on upstream's RT#2633 agrees. - The old code ran some AMD CPUs through the "intel" codepath and some went straight to "generic" after duplicating some, but not all, logic. The AMD copy didn't clear some reserved bits and didn't query CPUID 7 for AVX2 support. This is moot since AMD CPUs today don't support AVX2, but it seems they're expected to in the future? - Setting bit 10 is dropped. This doesn't appear to be queried anywhere, was 32-bit only, and seems a remnant of upstream's 14e21f863a3e3278bb8660ea9844e92e52e1f2f7. Change-Id: I0548877c97e997f7beb25e15f3fea71c68a951d2 Reviewed-on: https://boringssl-review.googlesource.com/5434 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Replace cpuid assembly with C code. Rather, take a leaf out of Chromium's book and use MSVC's __cpuid and _xgetbv built-in, with an inline assembly emulated version for other compilers. This preserves the behavior of the original assembly with the following differences: - CPUs without cpuid aren't support. Chromium's base/cpu.cc doesn't check, and SSE2 support is part of our baseline; the perlasm code is always built with OPENSSL_IA32_SSE2. - The clear_xmm block in cpu-x86-asm.pl is removed. This was used to clear some XMM-using features if OSXSAVE was set but XCR0 reports the OS doesn't use XSAVE to store SSE state. This wasn't present in the x86_64 and seems wrong. Section 13.5.2 of the Intel manual, volume 1, explicitly says SSE may still be used in this case; the OS may save that state in FXSAVE instead. A side discussion on upstream's RT#2633 agrees. - The old code ran some AMD CPUs through the "intel" codepath and some went straight to "generic" after duplicating some, but not all, logic. The AMD copy didn't clear some reserved bits and didn't query CPUID 7 for AVX2 support. This is moot since AMD CPUs today don't support AVX2, but it seems they're expected to in the future? - Setting bit 10 is dropped. This doesn't appear to be queried anywhere, was 32-bit only, and seems a remnant of upstream's 14e21f863a3e3278bb8660ea9844e92e52e1f2f7. Change-Id: I0548877c97e997f7beb25e15f3fea71c68a951d2 Reviewed-on: https://boringssl-review.googlesource.com/5434 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Replace cpuid assembly with C code. Rather, take a leaf out of Chromium's book and use MSVC's __cpuid and _xgetbv built-in, with an inline assembly emulated version for other compilers. This preserves the behavior of the original assembly with the following differences: - CPUs without cpuid aren't support. Chromium's base/cpu.cc doesn't check, and SSE2 support is part of our baseline; the perlasm code is always built with OPENSSL_IA32_SSE2. - The clear_xmm block in cpu-x86-asm.pl is removed. This was used to clear some XMM-using features if OSXSAVE was set but XCR0 reports the OS doesn't use XSAVE to store SSE state. This wasn't present in the x86_64 and seems wrong. Section 13.5.2 of the Intel manual, volume 1, explicitly says SSE may still be used in this case; the OS may save that state in FXSAVE instead. A side discussion on upstream's RT#2633 agrees. - The old code ran some AMD CPUs through the "intel" codepath and some went straight to "generic" after duplicating some, but not all, logic. The AMD copy didn't clear some reserved bits and didn't query CPUID 7 for AVX2 support. This is moot since AMD CPUs today don't support AVX2, but it seems they're expected to in the future? - Setting bit 10 is dropped. This doesn't appear to be queried anywhere, was 32-bit only, and seems a remnant of upstream's 14e21f863a3e3278bb8660ea9844e92e52e1f2f7. Change-Id: I0548877c97e997f7beb25e15f3fea71c68a951d2 Reviewed-on: https://boringssl-review.googlesource.com/5434 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Replace cpuid assembly with C code. Rather, take a leaf out of Chromium's book and use MSVC's __cpuid and _xgetbv built-in, with an inline assembly emulated version for other compilers. This preserves the behavior of the original assembly with the following differences: - CPUs without cpuid aren't support. Chromium's base/cpu.cc doesn't check, and SSE2 support is part of our baseline; the perlasm code is always built with OPENSSL_IA32_SSE2. - The clear_xmm block in cpu-x86-asm.pl is removed. This was used to clear some XMM-using features if OSXSAVE was set but XCR0 reports the OS doesn't use XSAVE to store SSE state. This wasn't present in the x86_64 and seems wrong. Section 13.5.2 of the Intel manual, volume 1, explicitly says SSE may still be used in this case; the OS may save that state in FXSAVE instead. A side discussion on upstream's RT#2633 agrees. - The old code ran some AMD CPUs through the "intel" codepath and some went straight to "generic" after duplicating some, but not all, logic. The AMD copy didn't clear some reserved bits and didn't query CPUID 7 for AVX2 support. This is moot since AMD CPUs today don't support AVX2, but it seems they're expected to in the future? - Setting bit 10 is dropped. This doesn't appear to be queried anywhere, was 32-bit only, and seems a remnant of upstream's 14e21f863a3e3278bb8660ea9844e92e52e1f2f7. Change-Id: I0548877c97e997f7beb25e15f3fea71c68a951d2 Reviewed-on: https://boringssl-review.googlesource.com/5434 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Replace cpuid assembly with C code. Rather, take a leaf out of Chromium's book and use MSVC's __cpuid and _xgetbv built-in, with an inline assembly emulated version for other compilers. This preserves the behavior of the original assembly with the following differences: - CPUs without cpuid aren't support. Chromium's base/cpu.cc doesn't check, and SSE2 support is part of our baseline; the perlasm code is always built with OPENSSL_IA32_SSE2. - The clear_xmm block in cpu-x86-asm.pl is removed. This was used to clear some XMM-using features if OSXSAVE was set but XCR0 reports the OS doesn't use XSAVE to store SSE state. This wasn't present in the x86_64 and seems wrong. Section 13.5.2 of the Intel manual, volume 1, explicitly says SSE may still be used in this case; the OS may save that state in FXSAVE instead. A side discussion on upstream's RT#2633 agrees. - The old code ran some AMD CPUs through the "intel" codepath and some went straight to "generic" after duplicating some, but not all, logic. The AMD copy didn't clear some reserved bits and didn't query CPUID 7 for AVX2 support. This is moot since AMD CPUs today don't support AVX2, but it seems they're expected to in the future? - Setting bit 10 is dropped. This doesn't appear to be queried anywhere, was 32-bit only, and seems a remnant of upstream's 14e21f863a3e3278bb8660ea9844e92e52e1f2f7. Change-Id: I0548877c97e997f7beb25e15f3fea71c68a951d2 Reviewed-on: https://boringssl-review.googlesource.com/5434 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289
  1. /* Copyright (C) 1995-1998 Eric Young (eay@cryptsoft.com)
  2. * All rights reserved.
  3. *
  4. * This package is an SSL implementation written
  5. * by Eric Young (eay@cryptsoft.com).
  6. * The implementation was written so as to conform with Netscapes SSL.
  7. *
  8. * This library is free for commercial and non-commercial use as long as
  9. * the following conditions are aheared to. The following conditions
  10. * apply to all code found in this distribution, be it the RC4, RSA,
  11. * lhash, DES, etc., code; not just the SSL code. The SSL documentation
  12. * included with this distribution is covered by the same copyright terms
  13. * except that the holder is Tim Hudson (tjh@cryptsoft.com).
  14. *
  15. * Copyright remains Eric Young's, and as such any Copyright notices in
  16. * the code are not to be removed.
  17. * If this package is used in a product, Eric Young should be given attribution
  18. * as the author of the parts of the library used.
  19. * This can be in the form of a textual message at program startup or
  20. * in documentation (online or textual) provided with the package.
  21. *
  22. * Redistribution and use in source and binary forms, with or without
  23. * modification, are permitted provided that the following conditions
  24. * are met:
  25. * 1. Redistributions of source code must retain the copyright
  26. * notice, this list of conditions and the following disclaimer.
  27. * 2. Redistributions in binary form must reproduce the above copyright
  28. * notice, this list of conditions and the following disclaimer in the
  29. * documentation and/or other materials provided with the distribution.
  30. * 3. All advertising materials mentioning features or use of this software
  31. * must display the following acknowledgement:
  32. * "This product includes cryptographic software written by
  33. * Eric Young (eay@cryptsoft.com)"
  34. * The word 'cryptographic' can be left out if the rouines from the library
  35. * being used are not cryptographic related :-).
  36. * 4. If you include any Windows specific code (or a derivative thereof) from
  37. * the apps directory (application code) you must include an acknowledgement:
  38. * "This product includes software written by Tim Hudson (tjh@cryptsoft.com)"
  39. *
  40. * THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND
  41. * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  42. * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  43. * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
  44. * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
  45. * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
  46. * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  47. * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
  48. * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
  49. * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  50. * SUCH DAMAGE.
  51. *
  52. * The licence and distribution terms for any publically available version or
  53. * derivative of this code cannot be changed. i.e. this code cannot simply be
  54. * copied and put under another distribution licence
  55. * [including the GNU Public Licence.] */
  56. #if !defined(__STDC_FORMAT_MACROS)
  57. #define __STDC_FORMAT_MACROS
  58. #endif
  59. #include <openssl/cpu.h>
  60. #if !defined(OPENSSL_NO_ASM) && (defined(OPENSSL_X86) || defined(OPENSSL_X86_64))
  61. #include <inttypes.h>
  62. #include <stdio.h>
  63. #include <stdlib.h>
  64. #include <string.h>
  65. #if defined(_MSC_VER)
  66. OPENSSL_MSVC_PRAGMA(warning(push, 3))
  67. #include <immintrin.h>
  68. #include <intrin.h>
  69. OPENSSL_MSVC_PRAGMA(warning(pop))
  70. #endif
  71. #include "internal.h"
  72. // OPENSSL_cpuid runs the cpuid instruction. |leaf| is passed in as EAX and ECX
  73. // is set to zero. It writes EAX, EBX, ECX, and EDX to |*out_eax| through
  74. // |*out_edx|.
  75. static void OPENSSL_cpuid(uint32_t *out_eax, uint32_t *out_ebx,
  76. uint32_t *out_ecx, uint32_t *out_edx, uint32_t leaf) {
  77. #if defined(_MSC_VER)
  78. int tmp[4];
  79. __cpuid(tmp, (int)leaf);
  80. *out_eax = (uint32_t)tmp[0];
  81. *out_ebx = (uint32_t)tmp[1];
  82. *out_ecx = (uint32_t)tmp[2];
  83. *out_edx = (uint32_t)tmp[3];
  84. #elif defined(__pic__) && defined(OPENSSL_32_BIT)
  85. // Inline assembly may not clobber the PIC register. For 32-bit, this is EBX.
  86. // See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47602.
  87. __asm__ volatile (
  88. "xor %%ecx, %%ecx\n"
  89. "mov %%ebx, %%edi\n"
  90. "cpuid\n"
  91. "xchg %%edi, %%ebx\n"
  92. : "=a"(*out_eax), "=D"(*out_ebx), "=c"(*out_ecx), "=d"(*out_edx)
  93. : "a"(leaf)
  94. );
  95. #else
  96. __asm__ volatile (
  97. "xor %%ecx, %%ecx\n"
  98. "cpuid\n"
  99. : "=a"(*out_eax), "=b"(*out_ebx), "=c"(*out_ecx), "=d"(*out_edx)
  100. : "a"(leaf)
  101. );
  102. #endif
  103. }
  104. // OPENSSL_xgetbv returns the value of an Intel Extended Control Register (XCR).
  105. // Currently only XCR0 is defined by Intel so |xcr| should always be zero.
  106. static uint64_t OPENSSL_xgetbv(uint32_t xcr) {
  107. #if defined(_MSC_VER)
  108. return (uint64_t)_xgetbv(xcr);
  109. #else
  110. uint32_t eax, edx;
  111. __asm__ volatile ("xgetbv" : "=a"(eax), "=d"(edx) : "c"(xcr));
  112. return (((uint64_t)edx) << 32) | eax;
  113. #endif
  114. }
  115. // handle_cpu_env applies the value from |in| to the CPUID values in |out[0]|
  116. // and |out[1]|. See the comment in |OPENSSL_cpuid_setup| about this.
  117. static void handle_cpu_env(uint32_t *out, const char *in) {
  118. const int invert = in[0] == '~';
  119. uint64_t v;
  120. if (!sscanf(in + invert, "%" PRIu64, &v)) {
  121. return;
  122. }
  123. if (invert) {
  124. out[0] &= ~v;
  125. out[1] &= ~(v >> 32);
  126. } else {
  127. out[0] = v;
  128. out[1] = v >> 32;
  129. }
  130. }
  131. void OPENSSL_cpuid_setup(void) {
  132. // Determine the vendor and maximum input value.
  133. uint32_t eax, ebx, ecx, edx;
  134. OPENSSL_cpuid(&eax, &ebx, &ecx, &edx, 0);
  135. uint32_t num_ids = eax;
  136. int is_intel = ebx == 0x756e6547 /* Genu */ &&
  137. edx == 0x49656e69 /* ineI */ &&
  138. ecx == 0x6c65746e /* ntel */;
  139. int is_amd = ebx == 0x68747541 /* Auth */ &&
  140. edx == 0x69746e65 /* enti */ &&
  141. ecx == 0x444d4163 /* cAMD */;
  142. int has_amd_xop = 0;
  143. if (is_amd) {
  144. // AMD-specific logic.
  145. // See http://developer.amd.com/wordpress/media/2012/10/254811.pdf
  146. OPENSSL_cpuid(&eax, &ebx, &ecx, &edx, 0x80000000);
  147. uint32_t num_extended_ids = eax;
  148. if (num_extended_ids >= 0x80000001) {
  149. OPENSSL_cpuid(&eax, &ebx, &ecx, &edx, 0x80000001);
  150. if (ecx & (1u << 11)) {
  151. has_amd_xop = 1;
  152. }
  153. }
  154. }
  155. uint32_t extended_features[2] = {0};
  156. if (num_ids >= 7) {
  157. OPENSSL_cpuid(&eax, &ebx, &ecx, &edx, 7);
  158. extended_features[0] = ebx;
  159. extended_features[1] = ecx;
  160. }
  161. // Determine the number of cores sharing an L1 data cache to adjust the
  162. // hyper-threading bit.
  163. uint32_t cores_per_cache = 0;
  164. if (is_amd) {
  165. // AMD CPUs never share an L1 data cache between threads but do set the HTT
  166. // bit on multi-core CPUs.
  167. cores_per_cache = 1;
  168. } else if (num_ids >= 4) {
  169. // TODO(davidben): The Intel manual says this CPUID leaf enumerates all
  170. // caches using ECX and doesn't say which is first. Does this matter?
  171. OPENSSL_cpuid(&eax, &ebx, &ecx, &edx, 4);
  172. cores_per_cache = 1 + ((eax >> 14) & 0xfff);
  173. }
  174. OPENSSL_cpuid(&eax, &ebx, &ecx, &edx, 1);
  175. // Adjust the hyper-threading bit.
  176. if (edx & (1u << 28)) {
  177. uint32_t num_logical_cores = (ebx >> 16) & 0xff;
  178. if (cores_per_cache == 1 || num_logical_cores <= 1) {
  179. edx &= ~(1u << 28);
  180. }
  181. }
  182. // Reserved bit #20 was historically repurposed to control the in-memory
  183. // representation of RC4 state. Always set it to zero.
  184. edx &= ~(1u << 20);
  185. // Reserved bit #30 is repurposed to signal an Intel CPU.
  186. if (is_intel) {
  187. edx |= (1u << 30);
  188. // Clear the XSAVE bit on Knights Landing to mimic Silvermont. This enables
  189. // some Silvermont-specific codepaths which perform better. See OpenSSL
  190. // commit 64d92d74985ebb3d0be58a9718f9e080a14a8e7f.
  191. if ((eax & 0x0fff0ff0) == 0x00050670 /* Knights Landing */ ||
  192. (eax & 0x0fff0ff0) == 0x00080650 /* Knights Mill (per SDE) */) {
  193. ecx &= ~(1u << 26);
  194. }
  195. } else {
  196. edx &= ~(1u << 30);
  197. }
  198. // The SDBG bit is repurposed to denote AMD XOP support.
  199. if (has_amd_xop) {
  200. ecx |= (1u << 11);
  201. } else {
  202. ecx &= ~(1u << 11);
  203. }
  204. uint64_t xcr0 = 0;
  205. if (ecx & (1u << 27)) {
  206. // XCR0 may only be queried if the OSXSAVE bit is set.
  207. xcr0 = OPENSSL_xgetbv(0);
  208. }
  209. // See Intel manual, volume 1, section 14.3.
  210. if ((xcr0 & 6) != 6) {
  211. // YMM registers cannot be used.
  212. ecx &= ~(1u << 28); // AVX
  213. ecx &= ~(1u << 12); // FMA
  214. ecx &= ~(1u << 11); // AMD XOP
  215. // Clear AVX2 and AVX512* bits.
  216. //
  217. // TODO(davidben): Should bits 17 and 26-28 also be cleared? Upstream
  218. // doesn't clear those.
  219. extended_features[0] &=
  220. ~((1u << 5) | (1u << 16) | (1u << 21) | (1u << 30) | (1u << 31));
  221. }
  222. // See Intel manual, volume 1, section 15.2.
  223. if ((xcr0 & 0xe6) != 0xe6) {
  224. // Clear AVX512F. Note we don't touch other AVX512 extensions because they
  225. // can be used with YMM.
  226. extended_features[0] &= ~(1u << 16);
  227. }
  228. // Disable ADX instructions on Knights Landing. See OpenSSL commit
  229. // 64d92d74985ebb3d0be58a9718f9e080a14a8e7f.
  230. if ((ecx & (1u << 26)) == 0) {
  231. extended_features[0] &= ~(1u << 19);
  232. }
  233. OPENSSL_ia32cap_P[0] = edx;
  234. OPENSSL_ia32cap_P[1] = ecx;
  235. OPENSSL_ia32cap_P[2] = extended_features[0];
  236. OPENSSL_ia32cap_P[3] = extended_features[1];
  237. const char *env1, *env2;
  238. env1 = getenv("OPENSSL_ia32cap");
  239. if (env1 == NULL) {
  240. return;
  241. }
  242. // OPENSSL_ia32cap can contain zero, one or two values, separated with a ':'.
  243. // Each value is a 64-bit, unsigned value which may start with "0x" to
  244. // indicate a hex value. Prior to the 64-bit value, a '~' may be given.
  245. //
  246. // If '~' isn't present, then the value is taken as the result of the CPUID.
  247. // Otherwise the value is inverted and ANDed with the probed CPUID result.
  248. //
  249. // The first value determines OPENSSL_ia32cap_P[0] and [1]. The second [2]
  250. // and [3].
  251. handle_cpu_env(&OPENSSL_ia32cap_P[0], env1);
  252. env2 = strchr(env1, ':');
  253. if (env2 != NULL) {
  254. handle_cpu_env(&OPENSSL_ia32cap_P[2], env2 + 1);
  255. }
  256. }
  257. #endif // !OPENSSL_NO_ASM && (OPENSSL_X86 || OPENSSL_X86_64)