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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 48105C001DE for ; Wed, 26 Jul 2023 09:51:37 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=FWlKMk8N; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4R9q134vfrz2yV0 for ; Wed, 26 Jul 2023 19:51:35 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=FWlKMk8N; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=linux.intel.com (client-ip=134.134.136.24; helo=mga09.intel.com; envelope-from=baolu.lu@linux.intel.com; receiver=lists.ozlabs.org) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4R9q002gpdz2yJT for ; Wed, 26 Jul 2023 19:50:38 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1690365041; x=1721901041; h=message-id:date:mime-version:cc:subject:to:references: from:in-reply-to:content-transfer-encoding; bh=R4Zidp2fJsuWVie8ZjWjKRcfxPMAX8NCKddofG0H9Oc=; b=FWlKMk8NZ+T7H5lonobcNBmB0Ak/3ej2B+8SdgY/wfWUjf5FSxMT0i+x 2XVLKhw1yGoS95TfvsqSRXL5qwBEHHI3lYjNacauLcO/SeP7tWpAjy58b nFQ8zxYUwsVvA+7x6Gp6++bkWlx0VojKT6VSkjFRk5X0Ja4V3xEEyg6bS +zoHBCVsyeVCf0uu4P9D7bB3ZLBiXzP2e1neiQXiky6R8I7QBN3R8FXto xK67bMqwTiT2Qrs798RowzQP+fqNYm9ZisJrsvJOEQykAhh23WWL3N98G EP7ZvmF6HajbJppJ48HNrVathDyntF6Vyd/033s/6BTOKBvkr8XgNSRuq g==; X-IronPort-AV: E=McAfee;i="6600,9927,10782"; a="370645342" X-IronPort-AV: E=Sophos;i="6.01,231,1684825200"; d="scan'208";a="370645342" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Jul 2023 02:50:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.01,202,1684825200"; d="scan'208";a="869813981" Received: from blu2-mobl.ccr.corp.intel.com (HELO [10.254.208.129]) ([10.254.208.129]) by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Jul 2023 02:50:25 -0700 Message-ID: <219fb054-c5a7-92e5-dfa4-af6a5a404c3e@linux.intel.com> Date: Wed, 26 Jul 2023 17:50:21 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH v5 21/25] iommu: Require a default_domain for all iommu drivers Content-Language: en-US To: Jason Gunthorpe , Andy Gross , Alim Akhtar , Bjorn Andersson , AngeloGioacchino Del Regno , Baolin Wang , Christophe Leroy , Gerald Schaefer , Heiko Stuebner , iommu@lists.linux.dev, Jernej Skrabec , Jonathan Hunter , Joerg Roedel , Kevin Tian , Konrad Dybcio , Krzysztof Kozlowski , linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, linux-mediatek@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-s390@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-sunxi@lists.linux.dev, linux-tegra@vger.kernel.org, Russell King , linuxppc-dev@lists.ozlabs.org, Matthias Brugger , Matthew Rosato , Michael Ellerman , Nicholas Piggin , Orson Zhai , Rob Clark , Robin Murphy , Samuel Holland , Thierry Reding , Krishna Reddy , Chen-Yu Tsai , Will Deacon , Yong Wu , Chunyan Zhang References: <21-v5-d0a204c678c7+3d16a-iommu_all_defdom_jgg@nvidia.com> From: Baolu Lu In-Reply-To: <21-v5-d0a204c678c7+3d16a-iommu_all_defdom_jgg@nvidia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Thierry Reding , Niklas Schnelle , Steven Price , Nicolin Chen , Dmitry Osipenko , baolu.lu@linux.intel.com, Marek Szyprowski Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On 2023/7/25 1:22, Jason Gunthorpe wrote: > At this point every iommu driver will cause a default_domain to be > selected, so we can finally remove this gap from the core code. > > The following table explains what each driver supports and what the > resulting default_domain will be: > > ops->defaut_domain > IDENTITY DMA PLATFORM v ARM32 dma-iommu ARCH > amd/iommu.c Y Y N/A either > apple-dart.c Y Y N/A either > arm-smmu.c Y Y IDENTITY either > qcom_iommu.c G Y IDENTITY either > arm-smmu-v3.c Y Y N/A either > exynos-iommu.c G Y IDENTITY either > fsl_pamu_domain.c Y N/A N/A PLATFORM > intel/iommu.c Y Y N/A either > ipmmu-vmsa.c G Y IDENTITY either > msm_iommu.c G IDENTITY N/A > mtk_iommu.c G Y IDENTITY either > mtk_iommu_v1.c G IDENTITY N/A > omap-iommu.c G IDENTITY N/A > rockchip-iommu.c G Y IDENTITY either > s390-iommu.c Y Y N/A N/A PLATFORM > sprd-iommu.c Y N/A DMA > sun50i-iommu.c G Y IDENTITY either > tegra-smmu.c G Y IDENTITY IDENTITY > virtio-iommu.c Y Y N/A either > spapr Y Y N/A N/A PLATFORM > * G means ops->identity_domain is used > * N/A means the driver will not compile in this configuration > > ARM32 drivers select an IDENTITY default domain through either the > ops->identity_domain or directly requesting an IDENTIY domain through > alloc_domain(). > > In ARM64 mode tegra-smmu will still block the use of dma-iommu.c and > forces an IDENTITY domain. > > S390 uses a PLATFORM domain to represent when the dma_ops are set to the > s390 iommu code. > > fsl_pamu uses an IDENTITY domain. > > POWER SPAPR uses PLATFORM and blocking to enable its weird VFIO mode. > > The x86 drivers continue unchanged. > > After this patch group->default_domain is only NULL for a short period > during bus iommu probing while all the groups are constituted. Otherwise > it is always !NULL. > > This completes changing the iommu subsystem driver contract to a system > where the current iommu_domain always represents some form of translation > and the driver is continuously asserting a definable translation mode. > > It resolves the confusion that the original ops->detach_dev() caused > around what translation, exactly, is the IOMMU performing after > detach. There were at least three different answers to that question in > the tree, they are all now clearly named with domain types. > > Tested-by: Heiko Stuebner > Tested-by: Niklas Schnelle > Tested-by: Steven Price > Tested-by: Marek Szyprowski > Tested-by: Nicolin Chen > Signed-off-by: Jason Gunthorpe > --- > drivers/iommu/iommu.c | 21 +++++++-------------- > 1 file changed, 7 insertions(+), 14 deletions(-) Reviewed-by: Lu Baolu