brintos

brintos / linux-shallow public Read only

0
0
Text · 9.4 KiB · c52b9da Raw
239 lines · plain
1.. SPDX-License-Identifier: GPL-2.02 3====================4APEI Error INJection5====================6 7EINJ provides a hardware error injection mechanism. It is very useful8for debugging and testing APEI and RAS features in general.9 10You need to check whether your BIOS supports EINJ first. For that, look11for early boot messages similar to this one::12 13  ACPI: EINJ 0x000000007370A000 000150 (v01 INTEL           00000001 INTL 00000001)14 15which shows that the BIOS is exposing an EINJ table - it is the16mechanism through which the injection is done.17 18Alternatively, look in /sys/firmware/acpi/tables for an "EINJ" file,19which is a different representation of the same thing.20 21It doesn't necessarily mean that EINJ is not supported if those above22don't exist: before you give up, go into BIOS setup to see if the BIOS23has an option to enable error injection. Look for something called WHEA24or similar. Often, you need to enable an ACPI5 support option prior, in25order to see the APEI,EINJ,... functionality supported and exposed by26the BIOS menu.27 28To use EINJ, make sure the following are options enabled in your kernel29configuration::30 31  CONFIG_DEBUG_FS32  CONFIG_ACPI_APEI33  CONFIG_ACPI_APEI_EINJ34 35...and to (optionally) enable CXL protocol error injection set::36 37  CONFIG_ACPI_APEI_EINJ_CXL38 39The EINJ user interface is in <debugfs mount point>/apei/einj.40 41The following files belong to it:42 43- available_error_type44 45  This file shows which error types are supported:46 47  ================  ===================================48  Error Type Value	Error Description49  ================  ===================================50  0x00000001        Processor Correctable51  0x00000002        Processor Uncorrectable non-fatal52  0x00000004        Processor Uncorrectable fatal53  0x00000008        Memory Correctable54  0x00000010        Memory Uncorrectable non-fatal55  0x00000020        Memory Uncorrectable fatal56  0x00000040        PCI Express Correctable57  0x00000080        PCI Express Uncorrectable non-fatal58  0x00000100        PCI Express Uncorrectable fatal59  0x00000200        Platform Correctable60  0x00000400        Platform Uncorrectable non-fatal61  0x00000800        Platform Uncorrectable fatal62  ================  ===================================63 64  The format of the file contents are as above, except present are only65  the available error types.66 67- error_type68 69  Set the value of the error type being injected. Possible error types70  are defined in the file available_error_type above.71 72- error_inject73 74  Write any integer to this file to trigger the error injection. Make75  sure you have specified all necessary error parameters, i.e. this76  write should be the last step when injecting errors.77 78- flags79 80  Present for kernel versions 3.13 and above. Used to specify which81  of param{1..4} are valid and should be used by the firmware during82  injection. Value is a bitmask as specified in ACPI5.0 spec for the83  SET_ERROR_TYPE_WITH_ADDRESS data structure:84 85    Bit 086      Processor APIC field valid (see param3 below).87    Bit 188      Memory address and mask valid (param1 and param2).89    Bit 290      PCIe (seg,bus,dev,fn) valid (see param4 below).91 92  If set to zero, legacy behavior is mimicked where the type of93  injection specifies just one bit set, and param1 is multiplexed.94 95- param196 97  This file is used to set the first error parameter value. Its effect98  depends on the error type specified in error_type. For example, if99  error type is memory related type, the param1 should be a valid100  physical memory address. [Unless "flag" is set - see above]101 102- param2103 104  Same use as param1 above. For example, if error type is of memory105  related type, then param2 should be a physical memory address mask.106  Linux requires page or narrower granularity, say, 0xfffffffffffff000.107 108- param3109 110  Used when the 0x1 bit is set in "flags" to specify the APIC id111 112- param4113  Used when the 0x4 bit is set in "flags" to specify target PCIe device114 115- notrigger116 117  The error injection mechanism is a two-step process. First inject the118  error, then perform some actions to trigger it. Setting "notrigger"119  to 1 skips the trigger phase, which *may* allow the user to cause the120  error in some other context by a simple access to the CPU, memory121  location, or device that is the target of the error injection. Whether122  this actually works depends on what operations the BIOS actually123  includes in the trigger phase.124 125CXL error types are supported from ACPI 6.5 onwards (given a CXL port126is present). The EINJ user interface for CXL error types is at127<debugfs mount point>/cxl. The following files belong to it:128 129- einj_types:130 131  Provides the same functionality as available_error_types above, but132  for CXL error types133 134- $dport_dev/einj_inject:135 136  Injects a CXL error type into the CXL port represented by $dport_dev,137  where $dport_dev is the name of the CXL port (usually a PCIe device name).138  Error injections targeting a CXL 2.0+ port can use the legacy interface139  under <debugfs mount point>/apei/einj, while CXL 1.1/1.0 port injections140  must use this file.141 142 143BIOS versions based on the ACPI 4.0 specification have limited options144in controlling where the errors are injected. Your BIOS may support an145extension (enabled with the param_extension=1 module parameter, or boot146command line einj.param_extension=1). This allows the address and mask147for memory injections to be specified by the param1 and param2 files in148apei/einj.149 150BIOS versions based on the ACPI 5.0 specification have more control over151the target of the injection. For processor-related errors (type 0x1, 0x2152and 0x4), you can set flags to 0x3 (param3 for bit 0, and param1 and153param2 for bit 1) so that you have more information added to the error154signature being injected. The actual data passed is this::155 156	memory_address = param1;157	memory_address_range = param2;158	apicid = param3;159	pcie_sbdf = param4;160 161For memory errors (type 0x8, 0x10 and 0x20) the address is set using162param1 with a mask in param2 (0x0 is equivalent to all ones). For PCI163express errors (type 0x40, 0x80 and 0x100) the segment, bus, device and164function are specified using param1::165 166         31     24 23    16 15    11 10      8  7        0167	+-------------------------------------------------+168	| segment |   bus  | device | function | reserved |169	+-------------------------------------------------+170 171Anyway, you get the idea, if there's doubt just take a look at the code172in drivers/acpi/apei/einj.c.173 174An ACPI 5.0 BIOS may also allow vendor-specific errors to be injected.175In this case a file named vendor will contain identifying information176from the BIOS that hopefully will allow an application wishing to use177the vendor-specific extension to tell that they are running on a BIOS178that supports it. All vendor extensions have the 0x80000000 bit set in179error_type. A file vendor_flags controls the interpretation of param1180and param2 (1 = PROCESSOR, 2 = MEMORY, 4 = PCI). See your BIOS vendor181documentation for details (and expect changes to this API if vendors182creativity in using this feature expands beyond our expectations).183 184 185An error injection example::186 187  # cd /sys/kernel/debug/apei/einj188  # cat available_error_type		# See which errors can be injected189  0x00000002	Processor Uncorrectable non-fatal190  0x00000008	Memory Correctable191  0x00000010	Memory Uncorrectable non-fatal192  # echo 0x12345000 > param1		# Set memory address for injection193  # echo 0xfffffffffffff000 > param2		# Mask - anywhere in this page194  # echo 0x8 > error_type			# Choose correctable memory error195  # echo 1 > error_inject			# Inject now196 197You should see something like this in dmesg::198 199  [22715.830801] EDAC sbridge MC3: HANDLING MCE MEMORY ERROR200  [22715.834759] EDAC sbridge MC3: CPU 0: Machine Check Event: 0 Bank 7: 8c00004000010090201  [22715.834759] EDAC sbridge MC3: TSC 0202  [22715.834759] EDAC sbridge MC3: ADDR 12345000 EDAC sbridge MC3: MISC 144780c86203  [22715.834759] EDAC sbridge MC3: PROCESSOR 0:306e7 TIME 1422553404 SOCKET 0 APIC 0204  [22716.616173] EDAC MC3: 1 CE memory read error on CPU_SrcID#0_Channel#0_DIMM#0 (channel:0 slot:0 page:0x12345 offset:0x0 grain:32 syndrome:0x0 -  area:DRAM err_code:0001:0090 socket:0 channel_mask:1 rank:0)205 206A CXL error injection example with $dport_dev=0000:e0:01.1::207 208    # cd /sys/kernel/debug/cxl/209    # ls210    0000:e0:01.1 0000:0c:00.0211    # cat einj_types                # See which errors can be injected212	0x00008000  CXL.mem Protocol Correctable213	0x00010000  CXL.mem Protocol Uncorrectable non-fatal214	0x00020000  CXL.mem Protocol Uncorrectable fatal215    # cd 0000:e0:01.1               # Navigate to dport to inject into216    # echo 0x8000 > einj_inject     # Inject error217 218Special notes for injection into SGX enclaves:219 220There may be a separate BIOS setup option to enable SGX injection.221 222The injection process consists of setting some special memory controller223trigger that will inject the error on the next write to the target224address. But the h/w prevents any software outside of an SGX enclave225from accessing enclave pages (even BIOS SMM mode).226 227The following sequence can be used:228  1) Determine physical address of enclave page229  2) Use "notrigger=1" mode to inject (this will setup230     the injection address, but will not actually inject)231  3) Enter the enclave232  4) Store data to the virtual address matching physical address from step 1233  5) Execute CLFLUSH for that virtual address234  6) Spin delay for 250ms235  7) Read from the virtual address. This will trigger the error236 237For more information about EINJ, please refer to ACPI specification238version 4.0, section 17.5 and ACPI 5.0, section 18.6.239