On Windows, we don't have the API that Linux provides, which can be used
to query MSRs of particular CPU cores. However, the same behaviour can be
emulated. Say that the driver handle object also stores 'dedicated thread
index'. When you call 'cpu_msr_driver_open()', this index is set to -1,
so further API functions do not force which core should be executing
RDMSR code. I.e. "I don't care on which core I run".
However, if this is non-negative number, the subsequent
functions like cpu_rdmsr() are forced to pass through this core by
using temporary affinity mask.
This function is similar to cpu_msr_driver_open(), but with core number as parameter
For Linux, core number was always 0. To be able to get all core temp/voltage, we need to set the core number.
They have L3 cache, and the detection code incorrectly assumed this is a Xeon
Irwindale variant due to an old and no longer valid classification check.
Correctly handle the XEON_IRWIN subcode and add an entry in the matchtable
to fix Sandy Bridge-E Xeon.
- move the INLINE_ASM_SUPPORTED guards outside the body of exec_cpuid, as
suggested by Genoil;
- copy the asm code of busy_sse_loop to masm-x64.asm. Some fixup was
required, because the microsoft calling convention doesn't expect
xmm6 & xmm7 to be clobbered in functions.
Confirmed that --clock-ic from cpuid_tool works with the resulting library.
Priously all fields in the matchtable were treated equal in importance.
With this change, the cache size a taken with half the weight in the decision.
Also add detection entries for some more recent Haswells, and the respective
tests. These are an i5 Haswell from a Mac Book Pro, and a i7 Haswel from
Thinkpad T540.
- Detect AVX and AVX2 on both Intel and AMD CPUs
- Detect BMI1 and BMI2 instruction sets (BMI2 is only on Haswell, BMI1 is
also present on Bulldozers).
- Fix tests to reflect changes.
Previously the detection only tested this AMD CPUs and the table check was
only present in recog_amd.c
Thanks to Andrew Roberts for reporting this issue!
Reorganize the detection for Intel Atom CPUs
- no longer make the distinction between single- and dualcore CPUs.
- correctly handle all Pineview and Cedarview CPUs.
Namely, printing a uint64_t with printf(...%llu...) is considered bad
practice; you need to use the format specifier PRIu64, defined in
inttypes.h. Apparently, it's not safe to assume that
uint64_t == unsigned long long.
However, I don't like this kind of formatting uglyness.
The td variable on my machine is ~30k - and conceivably can't go
above 1M. Moreover, this printf is only for detailed debug purposes.
So it's safe to cast the var to int and print it with %d.
Remove the line with the build date of the library from the
raw serialized file format. It doesn't help anything and it
bothers the openSUSE packaging guys. Having the current
date into a binary triggers a warning:
"Current date containing causes unnecessary package
republishing."
Confirmed that "strings libcpuid.a | grep 2014" no longer
contains the current date.
Also, the sse-width guesswork seems to handle this (wrong) Griffin ext_family
explicitly, so fix it there as well.
Seems that members of ext_family 20 (AMD Fusion based APUs) also are 64-bit,
but they have the authoritative sse width detection bit, so we don't need
to handle them explicitly here.
It seems that our SSE-based speed test is 1 IPC (instructions per clock)
on all current CPUs, and 1.4 IPC on the Bulldozer, which leads to its
result being 40% too high. Correct that in the function.
- Move detection of constant_tsc to common; it is spec'd in Intel docs
- Fix broken interpretation of EAX in leaf 80000000h: it shows max
800000xx-value, not max xx-value. This causes, for example, to seek
for extended features on Pentium II, where the extended leafs aren't
supported by the CPU at all.
This is only in common feature detection. AMD detection is fine.
- Add detection of a few new features in AMD leaf 80000007h: cbp (core
performance boost), aperfmperf (APERF/MPERF MSRs supported),
pfi (processor feedback interface) and pa (processor accumulator).
"make test" is broken right now, to be fixed in a subsequent commit.
Previously, 0.2.1 was mentioned in libcpuid.h, but this was not,
actually, in effect; it wasn't mentioned in autoconf and Visual Studio
project files. Also, cpuid_lib_version() still returned "0.2.0".
The .am files contained obsolete data (to include libcpuid.sln/libcpuid.vcproj
in a dist). These files are now in libcpuid_vc71.* and libcpuid_vc9.* flavours,
thus this change. "make dist" now works.
This adds support for x2apic detection. This is not a direct merge, since
- the feature is spelled as 'x2apic' instead of 'x2APIC', for consistency with other flags;
- tests are added
- the id of the feature is moved to the end of the cpu_feature_t enum, for binary
compatibility.
