Received: by 2002:ac0:e34a:0:0:0:0:0 with SMTP id g10csp508837imn; Thu, 28 Jul 2022 07:25:47 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vc2U0EzktUJf9GRe2OQPL0U9F6I1JYD/dS/8GI90Z6bBpyPTIUj1EHp1FJSD+XO8ITLVtZ X-Received: by 2002:a17:90a:bb15:b0:1f2:2a7d:7e05 with SMTP id u21-20020a17090abb1500b001f22a7d7e05mr10742251pjr.70.1659018347103; Thu, 28 Jul 2022 07:25:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659018347; cv=none; d=google.com; s=arc-20160816; b=YDeTjNmYjBlctOfJTSceSZx+yGxtiMFYYZu7zNKovL8I2mGR7h8FY70QwAaz5i1cK/ +IxdblBtTvK6BaadYhVdHB+tcuz6JINNl6ed3FFsv3JmDOPLCh4/JWUesfTPvNsMUqIL AU4zS2ahOt14BkxIKggZ5PGXipJGUzJj4zVS0w207iM1Yiy3zxMDPGrEFnmv8hQbutlk LdHuS2Bhno2OCNUwo0NEMUR+lowX1qwUIAXQmxp6NkDy/wsfhyyV37K6dHcmfshrpYEQ dc8AWLfZHqnS4E0986H8DzremrFowJCpN1jo1UZYpOl8Cz7cPpS7TzHlmirhDREmTQ+q TrsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=fKmWo9cDEe+BslhI1cABXNtyNJ6xgSZxEgsqKntqjKw=; b=SMF5WPWuruyn/YfJc12rYcHlOvwbYba4Rr1LGx9QO++RTnSdWyesRHHONyold61WEt NWO/H9LJQwyazQ6fZ3Ld7lvtzKmz5Kls60W1jB4e/uifLZZ9tXXoYybUy9oIeYYcnPEe KlJ8UaDjqmCq059KfVC9H1evRflejNPLbY9fvHgj4PbMkX1l6T/ySmvJSNPdOpSx0B1u qiabhiVfeHsfW0IRqJwAfHMUJLHY7r1zOX4tVKkIj5DGL8EU0rCyEkzQrI7KE/eYZsDS UlQ3sBmB4bDWivmcnVTYnBiu0cVo0xeSE5Saud1FoNDWCPEVDUx/aOs3e/SMTzJPdlxf a2/w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=NLgoZx2G; 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=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id pf18-20020a17090b1d9200b001ef888bd595si6570673pjb.118.2022.07.28.07.25.31; Thu, 28 Jul 2022 07:25:47 -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=@intel.com header.s=Intel header.b=NLgoZx2G; 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229796AbiG1NiQ (ORCPT + 99 others); Thu, 28 Jul 2022 09:38:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45082 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230043AbiG1NiI (ORCPT ); Thu, 28 Jul 2022 09:38:08 -0400 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3CB8A54673; Thu, 28 Jul 2022 06:38:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1659015487; x=1690551487; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=L2FRLYaTBI7F5ftQ6oi1R3XDVtj/kTzSoGnS9O2fMz0=; b=NLgoZx2G4Pih9yiocwB+cazIVanC/HY/T2YOajpVQaqKa75pbmiov6iT Y3mH3uehpVQn9bkmoohuJPVolJmW9cqkG89Im4XWpsjdFPJICUMHeBJ9R dc6Jd3ZLGaZJCTZGGICwjvHR8XJrCeMjS9y+p/MXnXgq2QWLeIDF62WfY 1gtggE3hz+weiA4CJ3XixVvu7yLPibAXxSK61lgdfuKq2hSloHUfnNFu4 n7kXGzRq0KX7r4dlh2g27itjedXTJKy8jvJ24YwlEnxFyZ0c4e+ev14XZ nCX4jvnE2qxgwUpJAhbpHOcQFTi9k4P3xKuMnb9UyX5iBB4VTWiAHKWx4 w==; X-IronPort-AV: E=McAfee;i="6400,9594,10421"; a="275394349" X-IronPort-AV: E=Sophos;i="5.93,198,1654585200"; d="scan'208";a="275394349" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jul 2022 06:38:06 -0700 X-IronPort-AV: E=Sophos;i="5.93,198,1654585200"; d="scan'208";a="690318074" Received: from hurleyst-mobl.amr.corp.intel.com (HELO [10.209.106.108]) ([10.209.106.108]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jul 2022 06:38:06 -0700 Message-ID: Date: Thu, 28 Jul 2022 06:38:06 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.11.0 Subject: Re: [External] Re: [PATCH v1] PCI/DPC: Skip EDR init when BIOS disable OS native DPC Content-Language: en-US To: Xiaochun XC17 Li , Xiaochun Lee , "linux-pci@vger.kernel.org" Cc: "bhelgaas@google.com" , "linux-kernel@vger.kernel.org" References: <1658919957-53006-1-git-send-email-lixiaochun.2888@163.com> <3dc43f00-0b01-1b02-74dc-6938f6db6e29@linux.intel.com> From: Sathyanarayanan Kuppuswamy In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE 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 7/28/22 3:11 AM, Xiaochun XC17 Li wrote: > Hi, >> -----Original Message----- >> From: Sathyanarayanan Kuppuswamy >> >> Sent: Wednesday, July 27, 2022 10:24 PM >> To: Xiaochun Lee ; linux-pci@vger.kernel.org >> Cc: bhelgaas@google.com; linux-kernel@vger.kernel.org; Xiaochun XC17 Li >> >> Subject: [External] Re: [PATCH v1] PCI/DPC: Skip EDR init when BIOS disable >> OS native DPC >> >> Hi, >> >> On 7/27/22 4:05 AM, Xiaochun Lee wrote: >>> From: Xiaochun Lee >>> >>> ACPI BIOS may disable OS native AER and DPC support to notify OS that >>> our platform doesn't support AER and DPC via the _OSC method. >>> BIOS also might leave the containment be accomplished purely in HW. >>> When firmware is set to non-aware OS DPC, we skip to install EDR >>> handler to an ACPI device. >> >> No, EDR is used when firmware controls the DPC. >> >> When the Firmware owns Downstream Port Containment, it is expected to >> use the new “Error Disconnect Recover” notification to alert OSPM of a >> Downstream Port Containment event. > > Thank you for correcting me on that. Could you please share more information > about the below questions? Many thanks! > As you mentioned, when Firmware is set to the platform not to support > OS native DPC, should OS still have to handle DPC flow from an EDR event? During OSC negotiation, OS will advertise its support for EDR, if it is available. If DPC is owned by firmware, then it can leverage the EDR support, to let OS handle the error recovery. > In my systems, when I disable native DPC in UEFI BIOS, kernel messages > show the "platform does not support [SHPCHotplug AER DPC]" as follows, > and it says OS now controls capabilities that do not include AER DPC. > > [ 2.400996] acpi PNP0A08:04: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI EDR HPX-Type3] > [ 2.402227] acpi PNP0A08:04: _OSC: platform does not support [SHPCHotplug AER DPC] > [ 2.402520] acpi PNP0A08:04: _OSC: OS now controls [PCIeHotplug PME PCIeCapability LTR] > [ 2.402521] acpi PNP0A08:04: FADT indicates ASPM is unsupported, using BIOS configuration > > After I injected a PCIE CTO UCE DER event received and DPC started > running as you said, But there is a little bit of confusion as to why I > disable OS native DCP, it still be triggered. > The injection message listed as below. > > [ 832.834785] pcieport 0000:a7:01.0: EDR: EDR event received > [ 832.835232] pcieport 0000:a7:01.0: DPC: containment event, status:0x1f09 source:0x0000 > [ 832.835239] pcieport 0000:a7:01.0: DPC: unmasked uncorrectable error detected > [ 832.835246] pcieport 0000:a7:01.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID) > [ 832.835253] pcieport 0000:a7:01.0: device [8086:352a] error status/mask=00004000/00180020 > [ 832.835258] pcieport 0000:a7:01.0: [14] CmpltTO (First) > [ 903.394837] pcieport 0000:a7:01.0: AER: device recovery successful EDR is the hybird mode. In this case, the firmware owns the DPC and will detect the DPC event. But for error recovery, it will let OS handle it to EDR notification. You can find more details in the latest PCIe firmware specification and APCI specification. > > On the contrary, if we keep OS native AER DPC enabled on BIOS, > we can see the message as below, OS now controls AER DPC. > Under these settings, who should handle DPC if an error is coming? If native DPC is enabled then OS will handle the DPC detection and error recover. In firmwre DPC mode, firmware will do the DPC detection and it can optionally use OS for error recovery using EDR> > Is it the EDR event or the DPC interrupt (dpc_irq)? > Does the BIOS participate in the DPC process in this situation? If BIOS > do not notify OS EDR via send WHEASCI, do we need to install edr notifier > handler in function pci_acpi_add_edr_notifier? > How about we skip EDR init when OS native AER/DPC enabled? Because we > now trigger DPC that be notified by an interrupt of DPC Control (DPCCTL) > register, install EDR handler seems redundant on OS native AER/DPC enabled. Installing handler will just register callback with ACPI device. AFAIK, preventing it in OS native DPC case is not going to fix anything or optimize the path. > Thanks! > [ 2.350709] acpi PNP0A08:04: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI EDR HPX-Type3] > [ 2.351799] acpi PNP0A08:04: _OSC: platform does not support [SHPCHotplug] > [ 2.353144] acpi PNP0A08:04: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability LTR DPC] > [ 2.353145] acpi PNP0A08:04: FADT indicates ASPM is unsupported, using BIOS configuration > >> >>> >>> Signed-off-by: Xiaochun Lee >>> --- >>> drivers/pci/pcie/edr.c | 16 ++++++++++++++++ >>> 1 file changed, 16 insertions(+) >>> >>> diff --git a/drivers/pci/pcie/edr.c b/drivers/pci/pcie/edr.c index >>> a6b9b47..97a680b 100644 >>> --- a/drivers/pci/pcie/edr.c >>> +++ b/drivers/pci/pcie/edr.c >>> @@ -19,6 +19,17 @@ >>> #define EDR_OST_SUCCESS 0x80 >>> #define EDR_OST_FAILED 0x81 >>> >>> +static int pcie_dpc_is_native(struct pci_dev *dev) { >>> + struct pci_host_bridge *host = pci_find_host_bridge(dev->bus); >>> + >>> + if (!dev->dpc_cap) >>> + return 0; >>> + >>> + return pcie_ports_dpc_native || host->native_dpc; } >>> + >>> + >>> /* >>> * _DSM wrapper function to enable/disable DPC >>> * @pdev : PCI device structure >>> @@ -212,6 +223,11 @@ void pci_acpi_add_edr_notifier(struct pci_dev >> *pdev) >>> return; >>> } >>> >>> + if (!pcie_dpc_is_native(pdev) && !pcie_aer_is_native(pdev)) { >>> + pci_dbg(pdev, "OS doesn't control DPC, skipping EDR init\n"); >>> + return; >>> + } >>> + >>> status = acpi_install_notify_handler(adev->handle, >> ACPI_SYSTEM_NOTIFY, >>> edr_handle_event, pdev); >>> if (ACPI_FAILURE(status)) { >> >> -- >> Sathyanarayanan Kuppuswamy >> Linux Kernel Developer -- Sathyanarayanan Kuppuswamy Linux Kernel Developer