summaryrefslogtreecommitdiff
path: root/bpf_ext.h
blob: f9892edf1ca1fd47446e4e58fc4dbca2d772c5e8 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
#ifndef BPF_EXT
#define BPF_EXT

#ifndef SKF_AD_OFF
# define SKF_AD_OFF			(-0x1000)
#endif
#ifndef SKF_AD_PROTOCOL
# define SKF_AD_PROTOCOL		0
#endif
#ifndef SKF_AD_PKTTYPE
# define SKF_AD_PKTTYPE			4
#endif
#ifndef SKF_AD_IFINDEX
# define SKF_AD_IFINDEX			8
#endif
#ifndef SKF_AD_NLATTR
# define SKF_AD_NLATTR			12
#endif
#ifndef SKF_AD_NLATTR_NEST
# define SKF_AD_NLATTR_NEST		16
#endif
#ifndef SKF_AD_MARK
# define SKF_AD_MARK			20
#endif
#ifndef SKF_AD_QUEUE
# define SKF_AD_QUEUE			24
#endif
#ifndef SKF_AD_HATYPE
# define SKF_AD_HATYPE			28
#endif
#ifndef SKF_AD_RXHASH
# define SKF_AD_RXHASH			32
#endif
#ifndef SKF_AD_CPU
# define SKF_AD_CPU			36
#endif
#ifndef SKF_AD_VLAN_TAG
# define SKF_AD_VLAN_TAG		44
#endif
#ifndef SKF_AD_VLAN_TAG_PRESENT
# define SKF_AD_VLAN_TAG_PRESENT	48
#endif
#ifndef SKF_AD_PAY_OFFSET
# define SKF_AD_PAY_OFFSET		52
#endif

#endif /* BPF_EXT */
CPUID/MSRs and making use for it for GOLDMONT. - TSC adjust MSR validation and sanitizing: The TSC adjust MSR contains the offset to the hardware counter. The sum of the adjust MSR and the counter is the TSC value which is read via RDTSC. On at least two machines from different vendors the BIOS sets the TSC adjust MSR to negative values. This happens on cold and warm boot. While on cold boot the offset is a few milliseconds, on warm boot it basically compensates the power on time of the system. The BIOSes are not even using the adjust MSR to set all CPUs in the package to the same offset. The offsets are different which renders the TSC unusable, What's worse is that the TSC deadline timer has a HW feature^Wbug. It malfunctions when the TSC adjust value is negative or greater equal 0x80000000 resulting in silent boot failures, hard lockups or non firing timers. This looks like some hardware internal 32/64bit issue with a sign extension problem. Intel has been silent so far on the issue. The update contains sanity checks and keeps the adjust register within working limits and in sync on the package. As it looks like this disease is spreading via BIOS crapware, we need to address this urgently as the boot failures are hard to debug for users" * 'x86-timers-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/tsc: Limit the adjust value further x86/tsc: Annotate printouts as firmware bug x86/tsc: Force TSC_ADJUST register to value >= zero x86/tsc: Validate TSC_ADJUST after resume x86/tsc: Validate cpumask pointer before accessing it x86/tsc: Fix broken CONFIG_X86_TSC=n build x86/tsc: Try to adjust TSC if sync test fails x86/tsc: Prepare warp test for TSC adjustment x86/tsc: Move sync cleanup to a safe place x86/tsc: Sync test only for the first cpu in a package x86/tsc: Verify TSC_ADJUST from idle x86/tsc: Store and check TSC ADJUST MSR x86/tsc: Detect random warps x86/tsc: Use X86_FEATURE_TSC_ADJUST in detect_art() x86/tsc: Finalize the split of the TSC_RELIABLE flag x86/tsc: Set TSC_KNOWN_FREQ and TSC_RELIABLE flags on Intel Atom SoCs x86/tsc: Mark Intel ATOM_GOLDMONT TSC reliable x86/tsc: Mark TSC frequency determined by CPUID as known x86/tsc: Add X86_FEATURE_TSC_KNOWN_FREQ flag
Diffstat