From nobody Wed May 15 18:12:44 2024 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 05E075F87A; Wed, 17 Apr 2024 06:16:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713334615; cv=none; b=l3zse1GhDj3PJj4b4/RU7xg6XAXNZQWzN3meF2xWWatYDcid5aMNNrqUL3PnwKN/gvt+E5DeJBAs1yAXBIR2J/476/RiRmbuVEcUjsCi+AIHeTv7H7mI8DQyM8GV7CfXsmf2dJh/2jLr7+MvK8ZVGJk110pUF0tbvbBRGc1zzec= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713334615; c=relaxed/simple; bh=BqoM4zaVZfGiETADZW0gzYBEuZf8Ez/YCjsv5m5EXAc=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=VcxVU7zu3J+1qMZFbJJqnZpCjTNmeT0cLhibT4Xr+aqD8Lfs04ApIkKUz1uASJL8+xQtbKN0GqIejNfvpcSj3XHBDFElHpwuvFokqunaFvLGCzWRiHCsF74CIUA8WAs/AQY40P8xsQApumO/ijO5+wJKXDQHYp7t4AynuqGC3b8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=IM/IPFjM; arc=none smtp.client-ip=192.198.163.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="IM/IPFjM" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1713334614; x=1744870614; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=BqoM4zaVZfGiETADZW0gzYBEuZf8Ez/YCjsv5m5EXAc=; b=IM/IPFjMTbFAIE0/uAu/SVgE+CbgNb4iLPeEctidvIJuutHUGEKd0tjy GLUuokJV4Hy0kQgKytkrjuU8YGWzt8InthuhBIJnfMDJw8+z7oKlgE3TR +06KrOaDqOnK8/lAe+11NIswI9uNzYN4/6rj7t58MO2jvvvJQ8ExzoAXr ntxAfMhnkhlkGDfyscr9yKofc94ML6tsyA0FdEmWD80Gw5/OwO0gNz9O4 Q6WyL/ZREIg//OvDzx8qrnkDKQbpA1JuHNkPZ0r42z9XLh+q3FwS1ooFo xL9UjOk8w14ugJdLwfyA9qxoeKod34LiHqVUx7JbFAkBNWnBRNe/XO0P5 w==; X-CSE-ConnectionGUID: uRdvOT9qQhyDWuNUOCw3Cg== X-CSE-MsgGUID: yVjbTI6PTCS+2nh4OQ4ozw== X-IronPort-AV: E=McAfee;i="6600,9927,11046"; a="11750796" X-IronPort-AV: E=Sophos;i="6.07,208,1708416000"; d="scan'208";a="11750796" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Apr 2024 23:16:53 -0700 X-CSE-ConnectionGUID: EBgVsiYaQGe/LmO1T0R3Dw== X-CSE-MsgGUID: Th4pgpKbT1ecuQYWXiSYgw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,208,1708416000"; d="scan'208";a="23109033" Received: from unknown (HELO SPR-S2600BT.bj.intel.com) ([10.240.192.124]) by orviesa008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Apr 2024 23:16:44 -0700 From: Zhenzhong Duan To: linux-pci@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-acpi@vger.kernel.org Cc: rafael@kernel.org, lenb@kernel.org, james.morse@arm.com, tony.luck@intel.com, bp@alien8.de, dave@stgolabs.net, jonathan.cameron@huawei.com, dave.jiang@intel.com, alison.schofield@intel.com, vishal.l.verma@intel.com, ira.weiny@intel.com, bhelgaas@google.com, helgaas@kernel.org, mahesh@linux.ibm.com, oohall@gmail.com, linmiaohe@huawei.com, shiju.jose@huawei.com, adam.c.preble@intel.com, leoyang.li@nxp.com, lukas@wunner.de, Smita.KoralahalliChannabasappa@amd.com, rrichter@amd.com, linux-cxl@vger.kernel.org, linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org, erwin.tsaur@intel.com, sathyanarayanan.kuppuswamy@intel.com, dan.j.williams@intel.com, feiting.wanyan@intel.com, yudong.wang@intel.com, chao.p.peng@intel.com, qingshun.wang@linux.intel.com, Zhenzhong Duan Subject: [PATCH v3 1/3] PCI/AER: Store UNCOR_STATUS bits that might be ANFE in aer_err_info Date: Wed, 17 Apr 2024 14:14:05 +0800 Message-Id: <20240417061407.1491361-2-zhenzhong.duan@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240417061407.1491361-1-zhenzhong.duan@intel.com> References: <20240417061407.1491361-1-zhenzhong.duan@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" In some cases the detector of a Non-Fatal Error(NFE) is not the most appropriate agent to determine the type of the error. For example, when software performs a configuration read from a non-existent device or Function, completer will send an ERR_NONFATAL Message. On some platforms, ERR_NONFATAL results in a System Error, which breaks normal software probing. Advisory Non-Fatal Error(ANFE) is a special case that can be used in above scenario. It is predominantly determined by the role of the detecting agent (Requester, Completer, or Receiver) and the specific error. In such cases, an agent with AER signals the NFE (if enabled) by sending an ERR_COR Message as an advisory to software, instead of sending ERR_NONFATAL. When processing an ANFE, ideally both correctable error(CE) status and uncorrectable error(UE) status should be cleared. However, there is no way to fully identify the UE associated with ANFE. Even worse, a Fatal Error(FE) or Non-Fatal Error(NFE) may set the same UE status bit as ANFE. Treating an ANFE as NFE will reproduce above mentioned issue, i.e., breaking softwore probing; treating NFE as ANFE will make us ignoring some UEs which need active recover operation. To avoid clearing UEs that are not ANFE by accident, the most conservative route is taken here: If any of the FE/NFE Detected bits is set in Device Status, do not touch UE status, they should be cleared later by the UE handler. Otherwise, a specific set of UEs that may be raised as ANFE according to the PCIe specification will be cleared if their corresponding severity is Non-Fatal. To achieve above purpose, store UNCOR_STATUS bits that might be ANFE in aer_err_info.anfe_status. So that those bits could be printed and processed later. Tested-by: Yudong Wang Co-developed-by: "Wang, Qingshun" Signed-off-by: "Wang, Qingshun" Signed-off-by: Zhenzhong Duan --- drivers/pci/pci.h | 1 + drivers/pci/pcie/aer.c | 45 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 46 insertions(+) diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h index 17fed1846847..3f9eb807f9fd 100644 --- a/drivers/pci/pci.h +++ b/drivers/pci/pci.h @@ -412,6 +412,7 @@ struct aer_err_info { =20 unsigned int status; /* COR/UNCOR Error Status */ unsigned int mask; /* COR/UNCOR Error Mask */ + unsigned int anfe_status; /* UNCOR Error Status for ANFE */ struct pcie_tlp_log tlp; /* TLP Header */ }; =20 diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c index ac6293c24976..27364ab4b148 100644 --- a/drivers/pci/pcie/aer.c +++ b/drivers/pci/pcie/aer.c @@ -107,6 +107,12 @@ struct aer_stats { PCI_ERR_ROOT_MULTI_COR_RCV | \ PCI_ERR_ROOT_MULTI_UNCOR_RCV) =20 +#define AER_ERR_ANFE_UNC_MASK (PCI_ERR_UNC_POISON_TLP | \ + PCI_ERR_UNC_COMP_TIME | \ + PCI_ERR_UNC_COMP_ABORT | \ + PCI_ERR_UNC_UNX_COMP | \ + PCI_ERR_UNC_UNSUP) + static int pcie_aer_disable; static pci_ers_result_t aer_root_reset(struct pci_dev *dev); =20 @@ -1196,6 +1202,41 @@ void aer_recover_queue(int domain, unsigned int bus,= unsigned int devfn, EXPORT_SYMBOL_GPL(aer_recover_queue); #endif =20 +static void anfe_get_uc_status(struct pci_dev *dev, struct aer_err_info *i= nfo) +{ + u32 uncor_mask, uncor_status; + u16 device_status; + int aer =3D dev->aer_cap; + + if (pcie_capability_read_word(dev, PCI_EXP_DEVSTA, &device_status)) + return; + /* + * Take the most conservative route here. If there are + * Non-Fatal/Fatal errors detected, do not assume any + * bit in uncor_status is set by ANFE. + */ + if (device_status & (PCI_EXP_DEVSTA_NFED | PCI_EXP_DEVSTA_FED)) + return; + + pci_read_config_dword(dev, aer + PCI_ERR_UNCOR_STATUS, &uncor_status); + pci_read_config_dword(dev, aer + PCI_ERR_UNCOR_MASK, &uncor_mask); + /* + * According to PCIe Base Specification Revision 6.1, + * Section 6.2.3.2.4, if an UNCOR error is raised as + * Advisory Non-Fatal error, it will match the following + * conditions: + * a. The severity of the error is Non-Fatal. + * b. The error is one of the following: + * 1. Poisoned TLP (Section 6.2.3.2.4.3) + * 2. Completion Timeout (Section 6.2.3.2.4.4) + * 3. Completer Abort (Section 6.2.3.2.4.1) + * 4. Unexpected Completion (Section 6.2.3.2.4.5) + * 5. Unsupported Request (Section 6.2.3.2.4.1) + */ + info->anfe_status =3D uncor_status & ~uncor_mask & ~info->severity & + AER_ERR_ANFE_UNC_MASK; +} + /** * aer_get_device_error_info - read error status from dev and store it to = info * @dev: pointer to the device expected to have a error record @@ -1213,6 +1254,7 @@ int aer_get_device_error_info(struct pci_dev *dev, st= ruct aer_err_info *info) =20 /* Must reset in this function */ info->status =3D 0; + info->anfe_status =3D 0; info->tlp_header_valid =3D 0; =20 /* The device might not support AER */ @@ -1226,6 +1268,9 @@ int aer_get_device_error_info(struct pci_dev *dev, st= ruct aer_err_info *info) &info->mask); if (!(info->status & ~info->mask)) return 0; + + if (info->status & PCI_ERR_COR_ADV_NFAT) + anfe_get_uc_status(dev, info); } else if (type =3D=3D PCI_EXP_TYPE_ROOT_PORT || type =3D=3D PCI_EXP_TYPE_RC_EC || type =3D=3D PCI_EXP_TYPE_DOWNSTREAM || --=20 2.34.1 From nobody Wed May 15 18:12:44 2024 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C1870537ED; Wed, 17 Apr 2024 06:17:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713334625; cv=none; b=sYQaQM+OznebDpvEsQiggCLoiEbOjKvvf5M5w77bVv9khTkwGMI0KH3BiuOm+bLt0b2DPEFmMxRAy36fP3k28fzxuve/imoMpOZKznttG+3R5qXyKRiC6j8fRGBtsnZNot86NXAzmYGt2IJfryLyGKCb8ytuQWLyvsw2SaqSTrY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713334625; c=relaxed/simple; bh=ub6kq74U0aYFIEC3DfFei2mAsfVCPJ20ozkIwFL9EQY=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=j6iwkYHvvwMlNiHq4orv0FcEIWCE4xyp3oKyezIZuAQTEJJHwW4hJ5cLgxzJR7/l7hXR54t6XpZBLVV4PoFw3JuR+UxqzEl/eh+01QjgO6FOrR1+cNAKChM7O7HxH0+ma2ODqQq9J/3U/qj1s6EY6XGYPOJspmjase7NsAYeL/I= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=oAplKs2H; arc=none smtp.client-ip=192.198.163.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="oAplKs2H" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1713334624; x=1744870624; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=ub6kq74U0aYFIEC3DfFei2mAsfVCPJ20ozkIwFL9EQY=; b=oAplKs2HuWAYr+LA54zvzXW4vYha1WUsQpPen/r8cb1EpZVDnsQwyJnJ 903+oW8nXlYhtNGA5ASuDDRQCuQZls53FvWSf+esGnbiFoS87++/mS4oy 5ZcdGJA0Wf8Lg6oCDJ0odMnyDHfvkuP5qs0OFdYK2T8W2V6HWg2VnqY0J FNGc63co+8SeYWpd9kRphH27OmSC7pdog7MXrBpONZ9nIcSLfmR05L/NK DWhNKEu6DbNEOPb7xYAs7E3Y2IXpFR2m2p8UVP3btqCnw8kLYYky3V84P a0TN5rc+G0+/OJAS5TNZX2EzBSIGaiL37o03yW/X8gtJZhwrEkB7jFiF6 w==; X-CSE-ConnectionGUID: 7irgcBpMRg6+wN07igDiCQ== X-CSE-MsgGUID: JrkHt6DpTnKyGPh816tfBg== X-IronPort-AV: E=McAfee;i="6600,9927,11046"; a="11750823" X-IronPort-AV: E=Sophos;i="6.07,208,1708416000"; d="scan'208";a="11750823" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Apr 2024 23:17:02 -0700 X-CSE-ConnectionGUID: abTWy6MlTSue4rwbuM6wug== X-CSE-MsgGUID: QIvtvlAbQQmcqJ/4U5WcuQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,208,1708416000"; d="scan'208";a="23109064" Received: from unknown (HELO SPR-S2600BT.bj.intel.com) ([10.240.192.124]) by orviesa008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Apr 2024 23:16:53 -0700 From: Zhenzhong Duan To: linux-pci@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-acpi@vger.kernel.org Cc: rafael@kernel.org, lenb@kernel.org, james.morse@arm.com, tony.luck@intel.com, bp@alien8.de, dave@stgolabs.net, jonathan.cameron@huawei.com, dave.jiang@intel.com, alison.schofield@intel.com, vishal.l.verma@intel.com, ira.weiny@intel.com, bhelgaas@google.com, helgaas@kernel.org, mahesh@linux.ibm.com, oohall@gmail.com, linmiaohe@huawei.com, shiju.jose@huawei.com, adam.c.preble@intel.com, leoyang.li@nxp.com, lukas@wunner.de, Smita.KoralahalliChannabasappa@amd.com, rrichter@amd.com, linux-cxl@vger.kernel.org, linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org, erwin.tsaur@intel.com, sathyanarayanan.kuppuswamy@intel.com, dan.j.williams@intel.com, feiting.wanyan@intel.com, yudong.wang@intel.com, chao.p.peng@intel.com, qingshun.wang@linux.intel.com, Zhenzhong Duan Subject: [PATCH v3 2/3] PCI/AER: Print UNCOR_STATUS bits that might be ANFE Date: Wed, 17 Apr 2024 14:14:06 +0800 Message-Id: <20240417061407.1491361-3-zhenzhong.duan@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240417061407.1491361-1-zhenzhong.duan@intel.com> References: <20240417061407.1491361-1-zhenzhong.duan@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When an Advisory Non-Fatal error(ANFE) triggers, both correctable error(CE) status and ANFE related uncorrectable error(UE) status will be printed: AER: Correctable error message received from 0000:b7:02.0 PCIe Bus Error: severity=3DCorrectable, type=3DTransaction Layer, (Receiv= er ID) device [8086:0db0] error status/mask=3D00002000/00000000 [13] NonFatalErr Uncorrectable errors that may cause Advisory Non-Fatal: [18] TLP Tested-by: Yudong Wang Co-developed-by: "Wang, Qingshun" Signed-off-by: "Wang, Qingshun" Signed-off-by: Zhenzhong Duan --- drivers/pci/pcie/aer.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c index 27364ab4b148..870e1d1a5159 100644 --- a/drivers/pci/pcie/aer.c +++ b/drivers/pci/pcie/aer.c @@ -681,6 +681,7 @@ static void __aer_print_error(struct pci_dev *dev, { const char **strings; unsigned long status =3D info->status & ~info->mask; + unsigned long anfe_status =3D info->anfe_status; const char *level, *errmsg; int i; =20 @@ -701,6 +702,20 @@ static void __aer_print_error(struct pci_dev *dev, info->first_error =3D=3D i ? " (First)" : ""); } pci_dev_aer_stats_incr(dev, info); + + if (!anfe_status) + return; + + strings =3D aer_uncorrectable_error_string; + pci_printk(level, dev, "Uncorrectable errors that may cause Advisory Non-= Fatal:\n"); + + for_each_set_bit(i, &anfe_status, 32) { + errmsg =3D strings[i]; + if (!errmsg) + errmsg =3D "Unknown Error Bit"; + + pci_printk(level, dev, " [%2d] %s\n", i, errmsg); + } } =20 void aer_print_error(struct pci_dev *dev, struct aer_err_info *info) --=20 2.34.1 From nobody Wed May 15 18:12:44 2024 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4617D65E02; Wed, 17 Apr 2024 06:17:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713334632; cv=none; b=UtClXVG0KLln0Zb0Ywn0DZ4TWNFsL5eIZXyTz3VbfGDbruWwxvmHNaMJDSSdt0OQeP9ipCNHEBLVfYL5pqcT2UiI8Twf5wD/1yPLKDaEXODrn7FLgg8gu7FyZLXeo3xmXNbObTuUP+c0aiENA6p3+b0CZYQLIDkNuzye9CM+kvA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713334632; c=relaxed/simple; bh=NFuVsgVJfZaAOKFxHZp//9+GJ3/IPPtO5nxnrAmlirg=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=Bo7CFjT9eZUODPPC987phEe4QHtqFb8B6CeHqzd4Unii2FGc5mM/7+vz/4umFym/YulFr8k+v8V+dloekhs+6Hb6b1qIusAWh6HeH6tjlvaJUkuU80nHV9FUo8+E24zRnq3X35OUptCJi5dxJXbc5GicmG9XpMUmvJOLk4JN9RQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=QZqOGcod; arc=none smtp.client-ip=192.198.163.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="QZqOGcod" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1713334631; x=1744870631; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=NFuVsgVJfZaAOKFxHZp//9+GJ3/IPPtO5nxnrAmlirg=; b=QZqOGcod0JIxF3PzDW5Gi9WmFD3cBjGLpU9eJxgDu1O0L2nu8NMY5l1P qVLFqoGDvr60qrVbm6C0m2HFJKYCBR+R/RZm7qfN3SqpT9m54VzjZxsC0 r6kcx91LzI2CZm6KcdXsL75WsKSzB40sBrL+PeZKL7zs9+Q61J32ODbx/ i5l3Nboq4QudruL9nL7FJM+nwAUczTphat5fIlv5lw8JfXlQi6vPfX/p7 WSvMjDLGyUTXZObdKYXbOEePx+3qTf7FMmQnkFcaZnule/nKknLMOhbjk 8ITTyEcKUWSE2FhS6vOOvaiEXVpAHBynfxd0OAHf6Mu6J8kPKH5ILP5RX w==; X-CSE-ConnectionGUID: F9tpuU7eR+CfYOmG4z/83Q== X-CSE-MsgGUID: IaUAebC8SvGtLeENUWpdJQ== X-IronPort-AV: E=McAfee;i="6600,9927,11046"; a="11750849" X-IronPort-AV: E=Sophos;i="6.07,208,1708416000"; d="scan'208";a="11750849" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Apr 2024 23:17:10 -0700 X-CSE-ConnectionGUID: j57zaDkGTVClbWw+FTtrHA== X-CSE-MsgGUID: qsmEAh3gSmqncLDcL9tXNQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,208,1708416000"; d="scan'208";a="23109086" Received: from unknown (HELO SPR-S2600BT.bj.intel.com) ([10.240.192.124]) by orviesa008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Apr 2024 23:17:02 -0700 From: Zhenzhong Duan To: linux-pci@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-acpi@vger.kernel.org Cc: rafael@kernel.org, lenb@kernel.org, james.morse@arm.com, tony.luck@intel.com, bp@alien8.de, dave@stgolabs.net, jonathan.cameron@huawei.com, dave.jiang@intel.com, alison.schofield@intel.com, vishal.l.verma@intel.com, ira.weiny@intel.com, bhelgaas@google.com, helgaas@kernel.org, mahesh@linux.ibm.com, oohall@gmail.com, linmiaohe@huawei.com, shiju.jose@huawei.com, adam.c.preble@intel.com, leoyang.li@nxp.com, lukas@wunner.de, Smita.KoralahalliChannabasappa@amd.com, rrichter@amd.com, linux-cxl@vger.kernel.org, linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org, erwin.tsaur@intel.com, sathyanarayanan.kuppuswamy@intel.com, dan.j.williams@intel.com, feiting.wanyan@intel.com, yudong.wang@intel.com, chao.p.peng@intel.com, qingshun.wang@linux.intel.com, Zhenzhong Duan Subject: [PATCH v3 3/3] PCI/AER: Clear UNCOR_STATUS bits that might be ANFE Date: Wed, 17 Apr 2024 14:14:07 +0800 Message-Id: <20240417061407.1491361-4-zhenzhong.duan@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240417061407.1491361-1-zhenzhong.duan@intel.com> References: <20240417061407.1491361-1-zhenzhong.duan@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When processing an ANFE, ideally both correctable error(CE) status and uncorrectable error(UE) status should be cleared. However, there is no way to fully identify the UE associated with ANFE. Even worse, a Fatal Error(FE) or Non-Fatal Error(NFE) may set the same UE status bit as ANFE. Treating an ANFE as NFE will reproduce above mentioned issue, i.e., breaking softwore probing; treating NFE as ANFE will make us ignoring some UEs which need active recover operation. To avoid clearing UEs that are not ANFE by accident, the most conservative route is taken here: If any of the FE/NFE Detected bits is set in Device Status, do not touch UE status, they should be cleared later by the UE handler. Otherwise, a specific set of UEs that may be raised as ANFE according to the PCIe specification will be cleared if their corresponding severity is Non-Fatal. For instance, previously when kernel receives an ANFE with Poisoned TLP in OS native AER mode, only status of CE will be reported and cleared: AER: Correctable error message received from 0000:b7:02.0 PCIe Bus Error: severity=3DCorrectable, type=3DTransaction Layer, (Receiv= er ID) device [8086:0db0] error status/mask=3D00002000/00000000 [13] NonFatalErr If the kernel receives a Malformed TLP after that, two UEs will be reported, which is unexpected. Malformed TLP Header is lost since the previous ANFE gated the TLP header logs: PCIe Bus Error: severity=3D"Uncorrectable (Fatal), type=3DTransaction Lay= er, (Receiver ID) device [8086:0db0] error status/mask=3D00041000/00180020 [12] TLP (First) [18] MalfTLP Now, for the same scenario, both CE status and related UE status will be reported and cleared after ANFE: AER: Correctable error message received from 0000:b7:02.0 PCIe Bus Error: severity=3DCorrectable, type=3DTransaction Layer, (Receiv= er ID) device [8086:0db0] error status/mask=3D00002000/00000000 [13] NonFatalErr Uncorrectable errors that may cause Advisory Non-Fatal: [18] TLP Tested-by: Yudong Wang Co-developed-by: "Wang, Qingshun" Signed-off-by: "Wang, Qingshun" Signed-off-by: Zhenzhong Duan --- drivers/pci/pcie/aer.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c index 870e1d1a5159..6ebe320eb0f7 100644 --- a/drivers/pci/pcie/aer.c +++ b/drivers/pci/pcie/aer.c @@ -1115,9 +1115,14 @@ static void pci_aer_handle_error(struct pci_dev *dev= , struct aer_err_info *info) * Correctable error does not need software intervention. * No need to go through error recovery process. */ - if (aer) + if (aer) { pci_write_config_dword(dev, aer + PCI_ERR_COR_STATUS, info->status); + if (info->anfe_status) + pci_write_config_dword(dev, + aer + PCI_ERR_UNCOR_STATUS, + info->anfe_status); + } if (pcie_aer_is_native(dev)) { struct pci_driver *pdrv =3D dev->driver; =20 --=20 2.34.1