This exposes L1, L2, etc. cache sizes, cache line size, etc.
Across S/R, everything except cache line size can differ from the host. This is
because cache line size is critical for correct use of CLFLUSH / CLFLUSHOPT,
but as far as I know, the other cache parameters can only affect performance,
not correctness.
AMD uses different leafs for cache information, which are not yet supported.
fail. There are no known cases of cache line size other than 64 in the fleet.
PiperOrigin-RevId: 265544786
Addresses obvious typos, in the documentation only.
COPYBARA_INTEGRATE_REVIEW=https://github.com/google/gvisor/pull/443 from Pixep:fix/documentation-spelling 4d0688164eafaf0b3010e5f4824b35d1e7176d65
PiperOrigin-RevId: 255477779
Based on the guidelines at
https://opensource.google.com/docs/releasing/authors/.
1. $ rg -l "Google LLC" | xargs sed -i 's/Google LLC.*/The gVisor Authors./'
2. Manual fixup of "Google Inc" references.
3. Add AUTHORS file. Authors may request to be added to this file.
4. Point netstack AUTHORS to gVisor AUTHORS. Drop CONTRIBUTORS.
Fixes#209
PiperOrigin-RevId: 245823212
Change-Id: I64530b24ad021a7d683137459cafc510f5ee1de9
From the SDM: "The least-significant byte in register EAX (register AL)
will always return 01H. Software should ignore this value and not
interpret it as an informational descriptor."
Unfortunately, online docs [1] [2] (likely based on an old version of the SDM)
say: "The least-significant byte in register EAX (register AL) indicates
the number of times the CPUID instruction must be executed with an input
value of 2 to get a complete description of the processor's caches and
TLBs."
dlang uses this second interpretation [3] and will loop 2^32 times if we
return zero. Fix this by specifying the fixed value of one. We still
don't support exposing the actual cache information, leaving all other
bytes empty. A zero byte means: "Null descriptor, this byte contains no
information."
[1] http://www.sandpile.org/x86/cpuid.htm#level_0000_0002h
[2] https://c9x.me/x86/html/file_module_x86_id_45.html
[3] https://github.com/dlang/druntime/blob/424640864c2aa001731467e96f637bd3e704e481/src/core/cpuid.d#L533-L534
PiperOrigin-RevId: 242046629
Change-Id: Ic0f0a5f974b20f71391cb85645bdcd4003e5fe88
910448bbed066ab1082b510eef1ae61bb792d854 ("perf/x86/amd/uncore: Rename
cpufeatures macro for cache counters") in 4.14 changed the name.
We change both the internal and cpuinfo name. As the upstream commit
states, "In Family 17h, L3 is the last level cache as opposed to L2 in
previous families. Avoid this name confusion ..."
PiperOrigin-RevId: 234698034
Change-Id: Ibf2efd4c0b83c1a8b5bb123da65ea1d7c6acd778
The final merged patch in Linux 4.10,
4ab1586488cb56ed8728e54c4157cc38646874d9 ("x86/cpufeature: Add RDT CPUID
feature bits") named this feature "rdt_a". Earlier patch sets had named
this "rdt".
PiperOrigin-RevId: 234680481
Change-Id: I0cc968201ec9a2825701405e207994a7331322b7
Linux started doing this in b8be15d588060a03569ac85dc4a0247460988f5b
("x86/fpu/xstate: Re-enable XSAVES"), which first appeared in 4.8.
PiperOrigin-RevId: 233800931
Change-Id: Icac2c2b03ccf1a91f3070431efb5152ca619fca3
Nothing reads them and they can simply get stale.
Generated with:
$ sed -i "s/licenses(\(.*\)).*/licenses(\1)/" **/BUILD
PiperOrigin-RevId: 231818945
Change-Id: Ibc3f9838546b7e94f13f217060d31f4ada9d4bf0
Actually parse flags from cpuinfo to avoid mistakenly matching
substrings in cpuinfo that happen to match a flags.
Some features were only exposed in recent versions of Linux. Don't
require them to appear in cpuinfo on old versions of Linux.
Move PREFETCHWT1 back to parse only features. It isn't actually exposed
in Linux yet. Move SDBG to shown features. It has been visible since
Linux 4.3.
PiperOrigin-RevId: 219381731
Change-Id: Ied7c0ee7c8a9879683e81933de56c9074b01108f
Michael Pratt
gVisor bot
Haibo Xu
Adin Scannell
Fabricio Voznika
Brad Burlage
Kevin Krakauer
Nicolas Lacasse