From patchwork Tue Jul 25 11:17:30 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Shameerali Kolothum Thodi X-Patchwork-Id: 108638 Delivered-To: patch@linaro.org Received: by 10.140.101.44 with SMTP id t41csp446276qge; Tue, 25 Jul 2017 04:19:58 -0700 (PDT) X-Received: by 10.98.79.29 with SMTP id d29mr18629582pfb.57.1500981598724; Tue, 25 Jul 2017 04:19:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1500981598; cv=none; d=google.com; s=arc-20160816; b=uVYF/8htfrUkDIfQNSDsXJ0j1CqDbwZIfQbJHpLPNmD/iPMLxOuZYelTIBTObzioR2 7yUb89h6jzb9o2PQtNnDsfOcRffxWKFdBffk1G7cAaHGU1xDYmMlkhzk+tOZYsi7iYAu SnuX8TwjpcfVaGRF4M7eNfAJd3ZBe9bILW73c2HMU3vOY2nbVFcP41ychi6x1eCWcKkd AUPuwLa1tjBGSIVr/Ioa1kjZ6tWBHVsWT9g5lP4zsBqmom9jlcCIuTQYqIeTicFMScKd 0L9w+5y5se2R+6kYpvFELXFaaw9kZ1KI6ZNliTMhE7NZo7TOHSlD9RRpPsVVhj//vTOq YIVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from:arc-authentication-results; bh=N5oVpvfY4RigVP0P+ncQPESKVqLWM2+o2p/PzUeehbQ=; b=Ygi9vTn0mquyV/e9QAtiufImOUREU5S6DMoEv2CEmm4VkJ5rdi7JID0iqflKbNcpzK BWGBIkr7vEn8mdqdvAsXfQq86KD5RbZaqMvJ3O0fMO27vTBM/OJ57hvNKrktCYjnGttJ rsdY0eHN6HJBpWgd/ZbiRRLuhzSn9YvY4ObXJf/f6iVVeZu9hUhjMoFyk70FVco07B4j ApsMiLTSrGXIGx3aKX7BcIHW0BsfiLl89g31ERG4E1xzVEvGRY52kl+UaLSo7ciG8I3I j4z4yvWyB8kPkTCLlDO9hRYtT+Oi67RmkFBFOCi6k8V60amYw8A3cyHi4t8FVFyAOxEu cdmQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-acpi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-acpi-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 195si1764344pfb.63.2017.07.25.04.19.58; Tue, 25 Jul 2017 04:19:58 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-acpi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-acpi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-acpi-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751553AbdGYLT4 (ORCPT + 7 others); Tue, 25 Jul 2017 07:19:56 -0400 Received: from szxga01-in.huawei.com ([45.249.212.187]:10264 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750851AbdGYLTk (ORCPT ); Tue, 25 Jul 2017 07:19:40 -0400 Received: from 172.30.72.55 (EHLO dggeml406-hub.china.huawei.com) ([172.30.72.55]) by dggrg01-dlp.huawei.com (MOS 4.4.6-GA FastPath queued) with ESMTP id ASZ13825; Tue, 25 Jul 2017 19:19:38 +0800 (CST) Received: from S00345302A-PC.china.huawei.com (10.203.177.212) by dggeml406-hub.china.huawei.com (10.3.17.50) with Microsoft SMTP Server id 14.3.301.0; Tue, 25 Jul 2017 19:19:26 +0800 From: Shameer Kolothum To: , , , , , CC: , , , , , , , , , Shameer Kolothum Subject: [PATCH v4 0/2] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI) Date: Tue, 25 Jul 2017 12:17:30 +0100 Message-ID: <20170725111732.41792-1-shameerali.kolothum.thodi@huawei.com> X-Mailer: git-send-email 2.12.0.windows.1 MIME-Version: 1.0 X-Originating-IP: [10.203.177.212] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.5977294A.00A0, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 160b609818c89546ff83657fe223178e Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On certain HiSilicon platforms (Hip06/Hip07) the GIC ITS and PCIe RC deviates from the standard implementation and this breaks PCIe MSI functionality when SMMU is enabled. The HiSilicon erratum 161010801 describes this limitation of certain HiSilicon platforms to support the SMMU mappings for MSI transactions. On these platforms GICv3 ITS translator is presented with the deviceID by extending the MSI payload data to 64 bits to include the deviceID. Hence, the PCIe controller on this platforms has to differentiate the MSI payload against other DMA payload and has to modify the MSI payload. This basically makes it difficult for this platforms to have a SMMU translation for MSI. To implement this quirk, the following changes are incorporated: 1. Added a generic helper function to IORT code to retrieve and reserve the HW ITS address regions. 2. Modified iommu_dma_get_resv_regions() to reserve the hw msi regions which means these address regions will not be translated and will be excluded from iova allocations. Thanks, Shameer Changelog: v3 --> v4 Rebased on 4.13-rc1. Addressed comments from Robin, Will and Lorenzo: -As suggested by Robin, moved the ITS msi reservation into iommu_dma_get_resv_regions(). -Added its_count != resv region failure case(patch #1). v2 --> v3 Addressed comments from Lorenzo and Robin: -Removed dev_is_pci() check in smmuV3 driver. -Don't treat device not having an ITS mapping as an error in iort helper function. v1 --> v2 -patch 2/2: Invoke iort helper fn based on fwnode type(acpi). RFCv2 -->PATCH -Incorporated Lorenzo's review comments. RFC v1 --> RFC v2 Based on Robin's review comments, -Removed the generic erratum framework. -Using IORT/MADT tables to retrieve the ITS base addr instead of vendor specific CSRT table. Shameer Kolothum (2): acpi:iort: Add an IORT helper function to reserve HW ITS address regions for IOMMU drivers iommu/dma: Add HW MSI address regions reservation for IOMMU drivers drivers/acpi/arm64/iort.c | 91 ++++++++++++++++++++++++++++++++++++++-- drivers/iommu/dma-iommu.c | 8 +++- drivers/irqchip/irq-gic-v3-its.c | 3 +- include/linux/acpi_iort.h | 8 +++- 4 files changed, 104 insertions(+), 6 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html