From patchwork Mon Feb 27 19:54:16 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jean-Philippe Brucker X-Patchwork-Id: 9593967 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 6EEF0604AB for ; Mon, 27 Feb 2017 20:12:10 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6292327B13 for ; Mon, 27 Feb 2017 20:12:10 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 571BA27F8C; Mon, 27 Feb 2017 20:12:10 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id DD45227B13 for ; Mon, 27 Feb 2017 20:12:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751882AbdB0ULz (ORCPT ); Mon, 27 Feb 2017 15:11:55 -0500 Received: from foss.arm.com ([217.140.101.70]:58574 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751568AbdB0ULP (ORCPT ); Mon, 27 Feb 2017 15:11:15 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 35E8F1435; Mon, 27 Feb 2017 11:58:17 -0800 (PST) Received: from e106794-lin.cambridge.arm.com (e106794-lin.cambridge.arm.com [10.1.210.60]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 8B9F93F3E1; Mon, 27 Feb 2017 11:58:14 -0800 (PST) From: Jean-Philippe Brucker Cc: Harv Abdulhamid , Will Deacon , Shanker Donthineni , Bjorn Helgaas , Sinan Kaya , Lorenzo Pieralisi , Catalin Marinas , Robin Murphy , Joerg Roedel , Nate Watterson , Alex Williamson , David Woodhouse , linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org, iommu@lists.linux-foundation.org, kvm@vger.kernel.org Subject: [RFC PATCH 05/30] iommu/arm-smmu-v3: Disable tagged pointers when ATS is in use Date: Mon, 27 Feb 2017 19:54:16 +0000 Message-Id: <20170227195441.5170-6-jean-philippe.brucker@arm.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20170227195441.5170-1-jean-philippe.brucker@arm.com> References: <20170227195441.5170-1-jean-philippe.brucker@arm.com> To: unlisted-recipients:; (no To-header on input) Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The ARM architecture has a "Top Byte Ignore" (TBI) option that makes the MMU mask out bits [63:56] of an address, allowing a userspace application to store data in its pointers. The ATS doesn't have an architected mechanism to enable TBI, and might create ATC entries for addresses that include a tag. Software would then have to send ATC invalidation packets for each 255 possible alias of an address, or just wipe the whole address space. This is not a viable option, so disable TBI when ATS is in use. It is unclear for the moment how this restriction will affect user applications. One example I can imagine (with my complete lack of knowledge about JIT engines and their use of tagged pointers) is a JIT translating a WebCL applications that uses SVM. Since this kind of interpreted language doesn't expose addresses, the interpreter and SVM implementations will be given the opportunity to do the right thing and remove tags before handing pointers to devices. Ideally we should remove TBI only for domains that are susceptible to use ATS. But at the point we're writing the context descriptor of a domain, we are still probing the first device in the group. If that device doesn't have an ATC but the next one does, we would then have to clear the TBI bit, invalidate the ATCs of previous devices, and notify the drivers that their devices cannot use tagged pointers anymore. Such a level of complexity doesn't make any sense here since it is unlikely devices will use tagged pointers at all. Signed-off-by: Jean-Philippe Brucker --- drivers/iommu/arm-smmu-v3.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c index e7b940146ae3..06b29d4fcf65 100644 --- a/drivers/iommu/arm-smmu-v3.c +++ b/drivers/iommu/arm-smmu-v3.c @@ -987,7 +987,7 @@ static void arm_smmu_cmdq_issue_cmd(struct arm_smmu_device *smmu, } /* Context descriptor manipulation functions */ -static u64 arm_smmu_cpu_tcr_to_cd(u64 tcr) +static u64 arm_smmu_cpu_tcr_to_cd(struct arm_smmu_device *smmu, u64 tcr) { u64 val = 0; @@ -1000,7 +1000,8 @@ static u64 arm_smmu_cpu_tcr_to_cd(u64 tcr) val |= ARM_SMMU_TCR2CD(tcr, EPD0); val |= ARM_SMMU_TCR2CD(tcr, EPD1); val |= ARM_SMMU_TCR2CD(tcr, IPS); - val |= ARM_SMMU_TCR2CD(tcr, TBI0); + if (!(smmu->features & ARM_SMMU_FEAT_ATS)) + val |= ARM_SMMU_TCR2CD(tcr, TBI0); return val; } @@ -1014,7 +1015,7 @@ static void arm_smmu_write_ctx_desc(struct arm_smmu_device *smmu, * We don't need to issue any invalidation here, as we'll invalidate * the STE when installing the new entry anyway. */ - val = arm_smmu_cpu_tcr_to_cd(cfg->cd.tcr) | + val = arm_smmu_cpu_tcr_to_cd(smmu, cfg->cd.tcr) | #ifdef __BIG_ENDIAN CTXDESC_CD_0_ENDI | #endif