Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp16915pxv; Wed, 21 Jul 2021 14:11:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzlgh+9EN10WZgxjscHYOHxvCrjrKrmcfBIG5R0OqPHWxo0p3QmROacOAg+sjiq/FRQdBYu X-Received: by 2002:a92:3009:: with SMTP id x9mr24490644ile.49.1626901526241; Wed, 21 Jul 2021 14:05:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626901526; cv=none; d=google.com; s=arc-20160816; b=SEJ1GZVoCWOmU1G1YKsmpnfJQQAsF0H4go0qPTS/pOanxAN6ao4Jxgq/svvAiRfNtw l9G+TZd0FWvyWML5FAVFXJyJhUvFVbW3uBjOFt3cryj4ryTq0f1uqrA1iVT6SWM7YJ4x 7FrWW866D+tsPipEugNgFbU+stFWYZjcXx6cy14mg+LpKDjeK2LmQApqW7X3XNDlvGb6 DaQs8pswLtRcCb4QZSCqOdu/YqCTafRlj4wWUxf6rx40uKJ8vAy0QPqQ+QFIbuGZO/hN TDIApiBhBOH5TPGQ2ONisTE3S7k0dfZuYOzEft22sigKWasKJb5cszCFycFaHYhNtm6+ hl8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=qHuKL1/R352XpaRQ+0+J71ymQvbDEKPaxLxbQ+Pr5FA=; b=nUWzwYauBItGg0tpPKXOppKmmaj7/EQnaDordfdeaz4mtOR8s+yjX9ClpDS5gwvIvL oDHF8vAYCcZvU/N8TJHtT49oAVX0FoFtZ77xtqfrHrfCpwB9HSa9sLVby1iOVLP0m5dN TGhcRo8Gu+bpE3Y5N6Fc0UFHhr6mXyDvAJ1KbkolYxglvl6KLBB4ICnMpRJ5RxLYldm8 BlLijxg1kNz0t/1jvfePH0oHpj3D3oq3j6PPq3u+247YFyMpXYzwn1gyv8IVeYxTxlUz vdni/RnrNaQMN7xVJy8sC6OEuh/Dikf162txHETaBRCNHpqL2rt+EHX5DSmbtrSZdOhU dXAA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j30si26751361ila.56.2021.07.21.14.05.14; Wed, 21 Jul 2021 14:05:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238944AbhGURlS (ORCPT + 99 others); Wed, 21 Jul 2021 13:41:18 -0400 Received: from foss.arm.com ([217.140.110.172]:33524 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238369AbhGURkr (ORCPT ); Wed, 21 Jul 2021 13:40:47 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8F9FE13A1; Wed, 21 Jul 2021 11:21:23 -0700 (PDT) Received: from 010265703453.arm.com (unknown [10.57.36.146]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 1ED343F694; Wed, 21 Jul 2021 11:21:21 -0700 (PDT) From: Robin Murphy To: joro@8bytes.org, will@kernel.org Cc: iommu@lists.linux-foundation.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, suravee.suthikulpanit@amd.com, baolu.lu@linux.intel.com, john.garry@huawei.com, dianders@chromium.org Subject: [PATCH 22/23] iommu: Allow enabling non-strict mode dynamically Date: Wed, 21 Jul 2021 19:20:33 +0100 Message-Id: <5b3933e8c5c57dae52d398e4dcf3fdfec9779539.1626888445.git.robin.murphy@arm.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Allocating and enabling a flush queue is in fact something we can reasonably do while a DMA domain is active, without having to rebuild it from scratch. Thus we can allow a strict -> non-strict transition from sysfs without requiring to unbind the device's driver, which is of particular interest to users who want to make selective relaxations to critical devices like the one serving their root filesystem. Disabling and draining a queue also seems technically possible to achieve without rebuilding the whole domain, but would certainly be more involved. Furthermore there's not such a clear use-case for tightening up security *after* the device may already have done whatever it is that you don't trust it not to do, so we only consider the relaxation case. Signed-off-by: Robin Murphy --- drivers/iommu/iommu.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index 4fad6d427d9d..43a2041d9629 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -3130,6 +3130,13 @@ static int iommu_change_dev_def_domain(struct iommu_group *group, goto out; } + /* We can bring up a flush queue without tearing down the domain */ + if (type == IOMMU_DOMAIN_DMA_FQ && prev_dom->type == IOMMU_DOMAIN_DMA) { + prev_dom->type = IOMMU_DOMAIN_DMA_FQ; + ret = iommu_dma_init_fq(prev_dom); + goto out; + } + /* Sets group->default_domain to the newly allocated domain */ ret = iommu_group_alloc_default_domain(dev->bus, group, type); if (ret) @@ -3170,9 +3177,9 @@ static int iommu_change_dev_def_domain(struct iommu_group *group, } /* - * Changing the default domain through sysfs requires the users to ubind the - * drivers from the devices in the iommu group. Return failure if this doesn't - * meet. + * Changing the default domain through sysfs requires the users to unbind the + * drivers from the devices in the iommu group, except for a DMA -> DMA-FQ + * transition. Return failure if this isn't met. * * We need to consider the race between this and the device release path. * device_lock(dev) is used here to guarantee that the device release path @@ -3248,7 +3255,8 @@ static ssize_t iommu_group_store_type(struct iommu_group *group, /* Check if the device in the group still has a driver bound to it */ device_lock(dev); - if (device_is_bound(dev)) { + if (device_is_bound(dev) && !(req_type == IOMMU_DOMAIN_DMA_FQ && + group->default_domain->type == IOMMU_DOMAIN_DMA)) { pr_err_ratelimited("Device is still bound to driver\n"); ret = -EBUSY; goto out; -- 2.25.1