From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B0CCFC433EF for ; Wed, 27 Oct 2021 05:31:24 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 76DC260F02 for ; Wed, 27 Oct 2021 05:31:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 76DC260F02 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Zns0HPiJMsuO0Hwnq2Tn258WK79xVngRQTySc9x1a0o=; b=UfkFCpQINMZ7n8 Sk7OVrtk9X+RhGgArDJrCQ9oXkUw8kkdibv3YizXlA+picVZ7CJDjJkL/tbvCsmexsFY2nj1/2Dg3 POKek6yBScnTE38jLt81xGLeIeK+FphquQLT6CkA0+V1Dq1U+ro6Gem31SsYCKQUx4X5SLtkZq+iJ 45XlOzS1VkefphZY+HGsFuCtZhSsbQIVR9kCgkrMiukQAkkRMesiQ6xBPdFo3hPAaonBGd7AEWni2 fgdJKwLACrHNpwqmqhd8iyghgzYPqRfdKw5WdZLdx5CGk5upOEySyKYssaWgImqSutJgIWhH+tAWy FCFs3e9aa9BqekBbP0Mg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mfbVh-003u29-Fq; Wed, 27 Oct 2021 05:30:01 +0000 Received: from out30-42.freemail.mail.aliyun.com ([115.124.30.42]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mfbVc-003u1H-Mb for linux-arm-kernel@lists.infradead.org; Wed, 27 Oct 2021 05:29:58 +0000 X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R501e4; CH=green; DM=||false|; DS=||; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e01e04407; MF=xuesong.chen@linux.alibaba.com; NM=1; PH=DS; RN=16; SR=0; TI=SMTPD_---0Utr8L.._1635312590; Received: from 30.225.212.53(mailfrom:xuesong.chen@linux.alibaba.com fp:SMTPD_---0Utr8L.._1635312590) by smtp.aliyun-inc.com(127.0.0.1); Wed, 27 Oct 2021 13:29:51 +0800 Message-ID: Date: Wed, 27 Oct 2021 13:29:49 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [PATCH v3 2/2] ACPI: APEI: Filter the PCI MCFG address with an arch-agnostic method To: Bjorn Helgaas Cc: catalin.marinas@arm.com, lorenzo.pieralisi@arm.com, james.morse@arm.com, will@kernel.org, rafael@kernel.org, tony.luck@intel.com, bp@alien8.de, mingo@kernel.org, bhelgaas@google.com, linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Huang Ying , xuesong.chen@linux.alibaba.com References: <20211026204722.GA158130@bhelgaas> From: Xuesong Chen In-Reply-To: <20211026204722.GA158130@bhelgaas> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211026_222956_948394_D9AFAA75 X-CRM114-Status: GOOD ( 29.15 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 27/10/2021 04:47, Bjorn Helgaas wrote: > On Tue, Oct 26, 2021 at 05:16:47PM +0800, Xuesong Chen wrote: >> On 26/10/2021 07:37, Bjorn Helgaas wrote: > >>> My point was that when ECAM is implemented correctly, a CPU does a >>> single MMIO load to do a PCI config read and a single MMIO store to do >>> a PCI config write. In that case there no need for any locking, so >>> there's no need for APEI to reserve those resources. >> >> Ah, got it. That means the PCI ECAM has a implicit mutual exclusion with EINJ >> if the hardware implemention is correct, so we can remove the MCFG from >> the APEI's safely. > > Well, not quite. ECAM doesn't *need* mutual exclusion. Single loads > and stores are atomic by definition. > OK, because ECAM config access has intrinsic atomic primitive, so no need to reserve those ECAM config space resources for APEI, that's why commit d91525eb8ee6 ("ACPI, EINJ: Enhance error injection tolerance level") fix make sense... >>> I think apei_resources_request() should continue to reserve MCFG areas >>> on tegra194 and xgene, but it does not need to reserve them on other >>> ARM64 platforms. >> >> As a summary: we need to reserve the MCFG areas on those platforms with a >> quirk ECAM implementation since there's no lockless method to access the >> configuration space, on other platforms we don't need to reserve the MCFG >> resources (so can remove it safely). >> >> So we need to add another patch to handle the case of tegra194 and xgene... >> I will try to figure it out. > > I looked through these again and found another problem case (thunder). > Here are my notes from my research. > > Normal ECAM users require no device-specific support. The platform > supplies an MCFG table, the generic code works, no mutual exclusion is > required, and APEI doesn't need to reserve the MCFG areas. > > The problem cases are platforms that supply an MCFG table but require > some device-specific workarounds. We can identify these because they > have quirks in pci-mcfg.c. Here are the existing quirks and the > pci_ecam_ops structs they supply: > > AL_ECAM al_pcie_ops # OK > QCOM_ECAM32 pci_32b_ops # OK > HISI_QUAD_DOM hisi_pcie_ops # OK > THUNDER_PEM_QUIRK thunder_pem_ecam_ops # problem > THUNDER_PEM_QUIRK thunder_pem_ecam_ops # problem > THUNDER_ECAM_QUIRK pci_thunder_ecam_ops # OK > tegra tegra194_pcie_ops # problem > XGENE_V1_ECAM_MCFG xgene_v1_pcie_ecam_ops # problem > XGENE_V2_ECAM_MCFG xgene_v2_pcie_ecam_ops # problem > ALTRA_ECAM_QUIRK pci_32b_read_ops # OK > > The ones marked "OK" have .map_bus(), .read(), and .write() methods > that need no mutual exclusion because they boil down to just a single > MMIO load or store. These are fine and there shouldn't be a problem > if an EINJ action accesses the ECAM space. > > The others do require mutual exclusion: > > - thunder_pem_ecam_ops: thunder_pem_config_read() calls > thunder_pem_bridge_read(), which does a writeq() to PEM_CFG_RD > followed by a readq(). The writeq() and readq() must be atomic to > avoid corruption. > > - tegra194_pcie_ops: tegra194_map_bus() programs the ATU. This and > the subsequent ECAM read/write must be atomic. > > - xgene_v1_pcie_ecam_ops and xgene_v2_pcie_ecam_ops: > xgene_pcie_map_bus() sets the RTID. This and the subsequent ECAM > read/write must be atomic. > > I had to look at all these ops individually to find them, so I don't > see an easy way to identify these problem cases at run-time. > > I personally would not have an issue with having APEI try to reserve > the MCFG regions for any platform that has an MCFG quirk. That would > prevent the al, qcom, hisi, thunder-ecam, and altra drivers from using > EINJ even though it would probably be safe for them. But we already > know those platforms are not really ACPI-compliant, so ... OK, understood. Since those platforms are not really ACPI-compliant, so we can unify all the quirks together. Let me send an inital solution about this for your review and see if there's room for further improvement... Thanks, Xuesong > > Bjorn > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel