Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp1561438rwl; Wed, 12 Apr 2023 15:11:28 -0700 (PDT) X-Google-Smtp-Source: AKy350acXuO9hy2niVVp/2zSHfKXkzJu85uq/vG4HEFoN6J0+a8A07axETOzuYQsLJkga0DQqrmC X-Received: by 2002:a17:906:340e:b0:94a:71f2:c3a0 with SMTP id c14-20020a170906340e00b0094a71f2c3a0mr288879ejb.54.1681337488315; Wed, 12 Apr 2023 15:11:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681337488; cv=none; d=google.com; s=arc-20160816; b=mvwnhGH1WgwmzwJIKj+gLHdspdJ3/76usIr8h+bZylga4a4zG/J+ZuKgAV4vb///O7 T2viV6R+NKdg4lwYJfxX2JZCOiLVji2EaEOOFTCOnGFXHfx8BLr/25U3A7iErjTeOhXi pUROR/N6dDNR6VsUwJUekF/M1l0nsLQUQlXz92zhc7LQ1Y+lbTFI6yBVcRlKQgoFEDZ5 BMnr72zMJ3mZuuiEJPtgUG/gqHMN3m/T9vHL+g/3Vw2IAgQ5Q+mdJUKfoRRlAfX9UzBh zAfMcJCoOVFPn8AzyEd8ILz2OZ4Vtj8NLgD/F1+TV0pYTqqeSF1uJAAW95SEYbXf3yCQ z6sA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :message-id:subject:cc:to:from:date:dkim-signature; bh=KjMZr+KY/1eVxURUqJBh5m8vd1hFOLP/Vx3Ex2ox8Mc=; b=lFDdnjXGP25742lm7R45FWGBaL+rqHUh5RDWe3U4sZEAVJTHomStslpixKTg9PtByN 4HmReb6G3xbqlXnnjGXuDqGiYY/0SuL7NhqxrOUcQM9PTnf8LqdagdCOzCbTCmRJQizJ nRc5hK2ODqv6sat8wWptsQkBpIaDlSy1xE+zDLcK7CEjTG40vS8qTu9fScnYmfpEysj5 WX0bG4mKgyQng8pLmTSJY9lK9/Rq/WuTqlY3hgBGYSH+kf4Uvqb8YGlZo9eQc8MIo75n OvjuLJDb8+VSQlnSVrLFzwQ7ZcJIXr/d2aqAWJUY2gZfic48x0U98HiR7ztQA3TDV9rt WZsQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=hqh8QIOj; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a1-20020a170906468100b0093297d89d19si10401445ejr.979.2023.04.12.15.11.00; Wed, 12 Apr 2023 15:11:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=hqh8QIOj; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229828AbjDLWCk (ORCPT + 99 others); Wed, 12 Apr 2023 18:02:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52830 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229719AbjDLWCh (ORCPT ); Wed, 12 Apr 2023 18:02:37 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6EEFF59E1; Wed, 12 Apr 2023 15:02:36 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 0B09E62CF0; Wed, 12 Apr 2023 22:02:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2F9ADC433D2; Wed, 12 Apr 2023 22:02:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1681336955; bh=DW7xegFaolvGBJ2256BboSBdl8fEqguZRrLmrPW4TmI=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=hqh8QIOjLdcYMhEeayRe/x4dSNqv0nAJhYcaNWOdwmX09SoP2D1m+KhFUKRubudy0 0Nx2GLxTH4kjLmMTB527zhjFDr7pyfwW5C/K6uTT+0b5EeFp64vgTjle9IDGu3Fusq jpBTRS4fpo0qnni2wFEQmvGNJS1Coav6iIWgHikwKvKoFjjH7LgK8LM/TH1dtxrcL4 R/QsXR3gHIr2A19pIvhm0fttAKndCcX1D968Q+bxwVDencpDJd0oLv3jRyPJQ58frS 53scneCqXonwVY4kNiBJheysykYMzIIcqPp6qdIO7PGTmb2YIYzfDy27GnCyYLNJ8d +XKssHD0RqpCQ== Date: Wed, 12 Apr 2023 17:02:33 -0500 From: Bjorn Helgaas To: Terry Bowman Cc: alison.schofield@intel.com, vishal.l.verma@intel.com, ira.weiny@intel.com, bwidawsk@kernel.org, dan.j.williams@intel.com, dave.jiang@intel.com, Jonathan.Cameron@huawei.com, linux-cxl@vger.kernel.org, rrichter@amd.com, linux-kernel@vger.kernel.org, bhelgaas@google.com, Oliver O'Halloran , Mahesh J Salgaonkar , linuxppc-dev@lists.ozlabs.org, linux-pci@vger.kernel.org Subject: Re: [PATCH v3 5/6] PCI/AER: Forward RCH downstream port-detected errors to the CXL.mem dev handler Message-ID: <20230412220233.GA83215@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230411180302.2678736-6-terry.bowman@amd.com> X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 11, 2023 at 01:03:01PM -0500, Terry Bowman wrote: > From: Robert Richter > > In Restricted CXL Device (RCD) mode a CXL device is exposed as an > RCiEP, but CXL downstream and upstream ports are not enumerated and > not visible in the PCIe hierarchy. Protocol and link errors are sent > to an RCEC. > > Restricted CXL host (RCH) downstream port-detected errors are signaled > as internal AER errors, either Uncorrectable Internal Error (UIE) or > Corrected Internal Errors (CIE). The error source is the id of the > RCEC. A CXL handler must then inspect the error status in various CXL > registers residing in the dport's component register space (CXL RAS > cap) or the dport's RCRB (AER ext cap). [1] > > Errors showing up in the RCEC's error handler must be handled and > connected to the CXL subsystem. Implement this by forwarding the error > to all CXL devices below the RCEC. Since the entire CXL device is > controlled only using PCIe Configuration Space of device 0, Function > 0, Capitalize "device" and "Function" the same way (also appears in comment below). > only pass it there [2]. These devices have the Memory Device class > code set (PCI_CLASS_MEMORY_CXL, 502h) and the existing cxl_pci driver > can implement the handler. In addition to errors directed to the CXL > endpoint device, the handler must also inspect the CXL downstream > port's CXL RAS and PCIe AER external capabilities that is connected to "AER external capabilities" -- is that referring to the "AER *Extended* capability"? If so, we usually don't bother including the "extended" part because it's usually not relevant. But if you intended "external", I don't know what it means. > the device. > > Since CXL downstream port errors are signaled using internal errors, > the handler requires those errors to be unmasked. This is subject of a > follow-on patch. > > The reason for choosing this implementation is that a CXL RCEC device > is bound to the AER port driver, but the driver does not allow it to > register a custom specific handler to support CXL. Connecting the RCEC > hard-wired with a CXL handler does not work, as the CXL subsystem > might not be present all the time. The alternative to add an > implementation to the portdrv to allow the registration of a custom > RCEC error handler isn't worth doing it as CXL would be its only user. > Instead, just check for an CXL RCEC and pass it down to the connected > CXL device's error handler. With this approach the code can entirely > be implemented in the PCIe AER driver and is independent of the CXL > subsystem. The CXL driver only provides the handler. Can you make this more concrete with an example topology so we can work through how this all works? Correct me when I go off the rails here: The current code uses pcie_walk_rcec() in this path, which basically searches below a Root Port or RCEC for devices that have an AER error status bit set, add them to the e_info[] list, and call handle_error_source() for each one: aer_isr_one_error # get e_src from aer_fifo find_source_device(e_src) pcie_walk_rcec(find_device_iter) find_device_iter is_error_source # read PCI_ERR_COR_STATUS or PCI_ERR_UNCOR_STATUS if (error-source) add_error_device # add device to e_info[] list # now call handle_error_source for everything in e_info[] aer_process_err_devices for (i = 0; i < e_info->err_dev_num; i++) handle_error_source IIUC, this patch basically says that an RCEC should have an AER error status bit (UIE or CIE) set, but the devices "below" the RCEC will not, so they won't get added to e_info[]. So we insert cxl_handle_error() in handle_error_source(), where it gets called for the RCEC, and then it uses pcie_walk_rcec() again to forcibly call handle_error_source() for *every* device "below" the RCEC (even though they don't have AER error status bits set). Then handle_error_source() ultimately calls the CXL driver err_handler entry points (.cor_error_detected(), .error_detected(), etc), which can look at the CXL-specific error status in the CXL RAS or RCRB or whatever. So this basically looks like a workaround for the fact that the AER code only calls handle_error_source() when it finds AER error status, and CXL doesn't *set* that AER error status. There's not that much code here, but it seems like a quite a bit of complexity in an area that is already pretty complicated. Here's another idea: the ACPI GHES code (ghes_handle_aer()) basically receives a packet of error status from firmware and queues it for recovery via pcie_do_recovery(). What if you had a CXL module that knew how to look for the CXL error status, package it up similarly, and queue it via aer_recover_queue()? > [1] CXL 3.0 spec, 12.2.1.1 RCH Downstream Port-detected Errors > [2] CXL 3.0 spec, 8.1.3 PCIe DVSEC for CXL Devices > > Co-developed-by: Terry Bowman > Signed-off-by: Robert Richter > Signed-off-by: Terry Bowman > Cc: "Oliver O'Halloran" > Cc: Bjorn Helgaas > Cc: Mahesh J Salgaonkar > Cc: linuxppc-dev@lists.ozlabs.org > Cc: linux-pci@vger.kernel.org > --- > drivers/pci/pcie/Kconfig | 8 ++++++ > drivers/pci/pcie/aer.c | 61 ++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 69 insertions(+) > > diff --git a/drivers/pci/pcie/Kconfig b/drivers/pci/pcie/Kconfig > index 228652a59f27..b0dbd864d3a3 100644 > --- a/drivers/pci/pcie/Kconfig > +++ b/drivers/pci/pcie/Kconfig > @@ -49,6 +49,14 @@ config PCIEAER_INJECT > gotten from: > https://git.kernel.org/cgit/linux/kernel/git/gong.chen/aer-inject.git/ > > +config PCIEAER_CXL > + bool "PCI Express CXL RAS support" > + default y > + depends on PCIEAER && CXL_PCI > + help > + This enables CXL error handling for Restricted CXL Hosts > + (RCHs). > + > # > # PCI Express ECRC > # > diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c > index 7a25b62d9e01..171a08fd8ebd 100644 > --- a/drivers/pci/pcie/aer.c > +++ b/drivers/pci/pcie/aer.c > @@ -946,6 +946,65 @@ static bool find_source_device(struct pci_dev *parent, > return true; > } > > +#ifdef CONFIG_PCIEAER_CXL > + > +static bool is_cxl_mem_dev(struct pci_dev *dev) > +{ > + /* > + * A CXL device is controlled only using PCIe Configuration > + * Space of device 0, Function 0. > + */ > + if (dev->devfn != PCI_DEVFN(0, 0)) > + return false; > + > + /* Right now there is only a CXL.mem driver */ > + if ((dev->class >> 8) != PCI_CLASS_MEMORY_CXL) > + return false; > + > + return true; > +} > + > +static bool is_internal_error(struct aer_err_info *info) > +{ > + if (info->severity == AER_CORRECTABLE) > + return info->status & PCI_ERR_COR_INTERNAL; > + > + return info->status & PCI_ERR_UNC_INTN; > +} > + > +static void handle_error_source(struct pci_dev *dev, struct aer_err_info *info); > + > +static int cxl_handle_error_iter(struct pci_dev *dev, void *data) > +{ > + struct aer_err_info *e_info = (struct aer_err_info *)data; > + > + if (!is_cxl_mem_dev(dev)) > + return 0; > + > + /* pci_dev_put() in handle_error_source() */ > + dev = pci_dev_get(dev); > + if (dev) > + handle_error_source(dev, e_info); > + > + return 0; > +} > + > +static void cxl_handle_error(struct pci_dev *dev, struct aer_err_info *info) > +{ > + /* > + * CXL downstream port errors are signaled as RCEC internal > + * errors. Forward them to all CXL devices below the RCEC. > + */ > + if (pci_pcie_type(dev) == PCI_EXP_TYPE_RC_EC && > + is_internal_error(info)) > + pcie_walk_rcec(dev, cxl_handle_error_iter, info); > +} > + > +#else > +static inline void cxl_handle_error(struct pci_dev *dev, > + struct aer_err_info *info) { } > +#endif > + > /** > * handle_error_source - handle logging error into an event log > * @dev: pointer to pci_dev data structure of error source device > @@ -957,6 +1016,8 @@ static void handle_error_source(struct pci_dev *dev, struct aer_err_info *info) > { > int aer = dev->aer_cap; > > + cxl_handle_error(dev, info); > + > if (info->severity == AER_CORRECTABLE) { > /* > * Correctable error does not need software intervention. > -- > 2.34.1 >