From: "Li, Ming" <ming4.li@intel.com>
To: Dan Williams <dan.j.williams@intel.com>, <rrichter@amd.com>,
<terry.bowman@amd.com>
Cc: <linux-cxl@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 4/6] PCI/AER: Extend RCH RAS error handling to support VH topology case
Date: Fri, 15 Mar 2024 11:43:01 +0800 [thread overview]
Message-ID: <f2dd9f36-5e69-4c6e-9640-7140a694086c@intel.com> (raw)
In-Reply-To: <65f3b2b29cfe9_aa22294e8@dwillia2-mobl3.amr.corp.intel.com.notmuch>
On 3/15/2024 10:30 AM, Dan Williams wrote:
> Li Ming wrote:
>> When RCEC captures CXL.cachemem protocol errors detected by CXL root
>> port, the recommendation from CXL r3.1 9.18.1.5 is :
>>
>> "Probe all CXL Downstream Ports and determine whether they have logged an
>> error in the CXL.io or CXL.cachemem status registers."
>>
>> The flow is similar with RCH RAS error handling, so reuse it to support
>> above case.
>>
>> Signed-off-by: Li Ming <ming4.li@intel.com>
>> ---
>> drivers/pci/pcie/aer.c | 20 ++++++++++++--------
>> 1 file changed, 12 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
>> index 364c74e47273..79bfa5fb78f4 100644
>> --- a/drivers/pci/pcie/aer.c
>> +++ b/drivers/pci/pcie/aer.c
>> @@ -996,11 +996,15 @@ static bool is_internal_error(struct aer_err_info *info)
>> return info->status & PCI_ERR_UNC_INTN;
>> }
>>
>> -static int cxl_rch_handle_error_iter(struct pci_dev *dev, void *data)
>> +static int cxl_handle_error_iter(struct pci_dev *dev, void *data)
>> {
>> struct aer_err_info *info = (struct aer_err_info *)data;
>> const struct pci_error_handlers *err_handler;
>>
>> + /* Skip the RCiEP devices not associating with RCEC */
>> + if ((pci_pcie_type(dev) == PCI_EXP_TYPE_RC_END) &&
>> + !dev->rcec)
>> + return 0;
>> if (!is_cxl_mem_dev(dev) || !cxl_error_is_native(dev))
>> return 0;
>
> is_cxl_mem_dev(dev) will always be false in the VH case, so how does
> this change help the VH case?
Hi Dan,
I think it won't be false if the CXL memory device is an endpoint.
pcie_walk_rcec_all() will walk all pci_dev in RCEC assocaited bus ranges. So these two checkings can help us to filter:
1. CXL memory device is an RCiEP associated with RCEC in the RCH case
2. CXL memory device is not an RCiEP, so it should be an endpoint in the VH case.
next prev parent reply other threads:[~2024-03-15 3:43 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-13 8:35 [RFC PATCH 0/6] Add support for root port RAS error handling Li Ming
2024-03-13 8:35 ` [RFC PATCH 1/6] PCI/RCEC: Introduce pcie_walk_rcec_all() Li Ming
2024-03-25 20:15 ` Terry Bowman
2024-04-16 4:39 ` Dan Williams
2024-04-22 14:34 ` Terry Bowman
2024-04-22 23:03 ` Dan Williams
2024-04-23 2:33 ` Li, Ming
2024-04-16 7:23 ` Li, Ming
2024-03-13 8:35 ` [RFC PATCH 2/6] PCI/CXL: A new attribute to indicate CXL-capable host bridge Li Ming
2024-03-13 8:35 ` [RFC PATCH 3/6] PCI/AER: Enable RCEC to report internal error for CXL root port Li Ming
2024-03-25 19:42 ` Terry Bowman
2024-04-16 7:27 ` Li, Ming
2024-04-16 14:46 ` Terry Bowman
2024-04-18 5:53 ` Li, Ming
2024-04-18 14:57 ` Dan Williams
2024-04-22 2:06 ` Li, Ming
2024-04-22 23:01 ` Dan Williams
2024-03-13 8:36 ` [RFC PATCH 4/6] PCI/AER: Extend RCH RAS error handling to support VH topology case Li Ming
2024-03-15 2:30 ` Dan Williams
2024-03-15 3:43 ` Li, Ming [this message]
2024-03-15 4:05 ` Dan Williams
2024-03-15 5:08 ` Li, Ming
2024-03-25 19:14 ` Terry Bowman
2024-03-13 8:36 ` [RFC PATCH 5/6] cxl: Use __free() for cxl_pci/mem_find_port() to drop put_device() Li Ming
2024-03-15 2:24 ` Dan Williams
2024-03-15 4:05 ` Li, Ming
2024-03-13 8:36 ` [RFC PATCH 6/6] cxl/pci: Support to handle root port RAS errors captured by RCEC Li Ming
2024-03-15 1:45 ` [RFC PATCH 0/6] Add support for root port RAS error handling Dan Williams
2024-03-15 8:40 ` Li, Ming
2024-03-15 18:21 ` Dan Williams
2024-03-20 12:48 ` Li, Ming
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f2dd9f36-5e69-4c6e-9640-7140a694086c@intel.com \
--to=ming4.li@intel.com \
--cc=dan.j.williams@intel.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rrichter@amd.com \
--cc=terry.bowman@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox