Linux CXL
 help / color / mirror / Atom feed
From: Dan Williams <dan.j.williams@intel.com>
To: "Li, Ming" <ming4.li@intel.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Terry Bowman <Terry.Bowman@amd.com>, <rrichter@amd.com>
Cc: <linux-cxl@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 3/6] PCI/AER: Enable RCEC to report internal error for CXL root port
Date: Mon, 22 Apr 2024 16:01:21 -0700	[thread overview]
Message-ID: <6626ec41da372_690a294df@dwillia2-xfh.jf.intel.com.notmuch> (raw)
In-Reply-To: <8a304a97-7825-4b02-a716-f25d0e9d4718@intel.com>

Li, Ming wrote:
> On 4/18/2024 10:57 PM, Dan Williams wrote:
> > Li, Ming wrote:
> >> On 4/16/2024 10:46 PM, Terry Bowman wrote:
> >>> The driver support is much simpler if RCEC does not handle VH protocol errors. Is there 
> >>> a reason to forward root port VH mode protocol errors to an RCEC rather than consume 
> >>> in the root port's AER driver and forward to CXL error handler? 
> >>>
> >> I agree that is simpler if only root port handle VH protocol errors,
> >> but I think that software has no chance to choose if VH protocol
> >> errors reported to RCEC or root port, it depends on platform
> >> implementation. So I think we should support both cases.
> > 
> > The question is whether the CXL spec RDPAS behavior causes any problems
> > for platforms that follow PCIe rather than CXL reporting flows for
> > root-port errors. I.e. does it cause problems if Linux starts scanning
> > root ports on RCEC notifications?
> > 
> > I do think the lookup needs to change to be based on CXL host-bridge
> > detection and not CXL-type-3 endpoint detection, but otherwise it looks
> > like CXL spec wants to invalidate PCIe spec expectations.
> 
> Hi Dan, if my understanding is correct, the CXL host-bridge detection
> you mentioned is that iterating all root ports under RCEC associated
> bus range for RCEC reported VH protocol errors case, and the
> CXL-type-3 detection is that iterating all CXL-type-3 endpoint under
> RCEC associated bus range. is it right?

I think this error checking needs to be tightly scoped to only scan for
CXL.cachemem errors and not CXL.io or typical PCIe errors. That way we
are not technically running afoul of the PCIe expectations that *PCIe*
root-port errors are only reported by their local AER block and not an
RCEC.

So the scanning should be limited to just the root-ports that have
negotiated a CXL.cachemem link.

  reply	other threads:[~2024-04-22 23:01 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 [this message]
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
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=6626ec41da372_690a294df@dwillia2-xfh.jf.intel.com.notmuch \
    --to=dan.j.williams@intel.com \
    --cc=Terry.Bowman@amd.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ming4.li@intel.com \
    --cc=rrichter@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