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 57B5CC433EF for ; Tue, 26 Oct 2021 20:48:54 +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 1FAAC60E8F for ; Tue, 26 Oct 2021 20:48:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1FAAC60E8F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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:MIME-Version:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:References: List-Owner; bh=QKESRBXHGdwFA603EfdVq6gXka7iPwwsvn9u1GnVW5w=; b=psKl4rxYxhfy3M HXqBlRzhT5ITMMUFR5VoQ5ln7mnByODtFPySe147VwbXEyIpTG1YD+GP/JM5YaiVfMQmg/MJP4hZI Qy7VYPmFAdi1F5eMl7xKNRukiuD+4YFjCLIPmL8VB2K1sSSwQ1Stp2aqlDo1GDlBcv/3X64J9iQ/C 8jDujO7eyRowgArZs1jZleSmhVkHBMQhZUL4FgERjCdkhR4dTJJbjCIVurGcV3rzWzNzjCw+mzAgv OiRi5U37wV8P1B3gJPbl69jxh0oMw2KYBgYAFZjRN8V2R8EjF7B9BU/K7marE0RPXkyImhphuYtM6 X7VqVC8NsrYm+DHMrdgQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mfTM2-0032Zv-24; Tue, 26 Oct 2021 20:47:30 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mfTLz-0032Z7-2W for linux-arm-kernel@lists.infradead.org; Tue, 26 Oct 2021 20:47:28 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id BA23860296; Tue, 26 Oct 2021 20:47:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1635281244; bh=hZut5nm2pKDxCAJpJ+gN/iH1oUKj9aOLGboxGFVJ5YI=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=olXKZbS4UT5e405M23mZjkauGYD3HC0pijTZ9JfGB85dm7/+Z6cjvMsAexbv6QabS R4DiczunAOaGB5dG9uqMRBkOl2CsKwA0WEDMSjr88MIYYxS4NQ8LlLjjfc5Y224Vol mU06RB6CXLdgk8QoKjczkeFwWQ2yH8CV/7rJxqVHW3TC1QUMXf40CnVabGu+cIgOqC xrRc/XC85baK33Dtmt6OP2dS0xP+YLBwUsnYgN8q+jg/Ixw7JOBQ0sckmuxqxJRl9U VeTwHiJq+FB3YWx6UCGZePvE20G6irMcDY1/ooBaVJl43GhbA4hdxYBhTVcYkrMuha ES5QdyUDrAtOw== Date: Tue, 26 Oct 2021 15:47:22 -0500 From: Bjorn Helgaas To: Xuesong Chen 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 Subject: Re: [PATCH v3 2/2] ACPI: APEI: Filter the PCI MCFG address with an arch-agnostic method Message-ID: <20211026204722.GA158130@bhelgaas> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1e186336-aa68-d845-307e-aa6e1133322f@linux.alibaba.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211026_134727_180524_0C3071BB X-CRM114-Status: GOOD ( 24.80 ) 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 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. > > 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 ... Bjorn _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel