From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ADF373D92 for ; Wed, 16 Aug 2023 04:11:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1692159081; x=1723695081; h=message-id:date:mime-version:cc:subject:to:references: from:in-reply-to:content-transfer-encoding; bh=4+AGSqBUOkC77nRQkn+4Zy4NeYFwDDx95fpuE62seCM=; b=Me3UT6+KDJBcxloLv1S1jyaCLD56u7NYOUBh3FkONOt0f62Qtagp72Y2 uO2VJ3Ig8Qo4Z/EfbdV8b10qbyBaw+Z7f41aDnrMJCpubxw4amFXCNgJS i9uG1AKYbdwZzFm7FDvAnq77206Mi/IXi5OYnG7EcE/IlWZAZAz+GjDdp ZV8kU6oT63Jt1IjR6OzAmKn7/a8IfvxVkM8nGvKgSP7lAA390d5Yw8i4S zBQ7g8aMKwJbNUhtp1iNhGRYX8+PcqKt3bLWbhvmQgPG+hA05E3LbY9vR ojJImtdZisuNVf+/ha7HwKjq5BowBBCgpz4M4kQEfFLR8l49Pzpm9XX1r w==; X-IronPort-AV: E=McAfee;i="6600,9927,10803"; a="352023644" X-IronPort-AV: E=Sophos;i="6.01,175,1684825200"; d="scan'208";a="352023644" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Aug 2023 21:10:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10803"; a="737140064" X-IronPort-AV: E=Sophos;i="6.01,175,1684825200"; d="scan'208";a="737140064" Received: from blu2-mobl.ccr.corp.intel.com (HELO [10.254.209.88]) ([10.254.209.88]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Aug 2023 21:10:28 -0700 Message-ID: Date: Wed, 16 Aug 2023 12:10:26 +0800 Precedence: bulk X-Mailing-List: iommu@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 Cc: baolu.lu@linux.intel.com, Anup Patel , Tomasz Jeznach , Joerg Roedel , Will Deacon , Robin Murphy , Paul Walmsley , Albert Ou , linux@rivosinc.com, linux-kernel@vger.kernel.org, Sebastien Boeuf , iommu@lists.linux.dev, Palmer Dabbelt , Nick Kossifidis , linux-riscv@lists.infradead.org Subject: Re: [PATCH 03/11] dt-bindings: Add RISC-V IOMMU bindings Content-Language: en-US To: Zong Li , Jason Gunthorpe References: <592edb17-7fa4-3b5b-2803-e8c50c322eee@linux.intel.com> From: Baolu Lu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2023/8/16 10:16, Zong Li wrote: > On Wed, Aug 16, 2023 at 2:38 AM Jason Gunthorpe wrote: >> On Tue, Aug 15, 2023 at 09:28:54AM +0800, Zong Li wrote: >>> On Wed, Aug 9, 2023 at 10:57 PM Jason Gunthorpe wrote: >>>> On Thu, Jul 27, 2023 at 10:42:47AM +0800, Zong Li wrote: >>>> >>>>> Perhaps this question could be related to the scenarios in which >>>>> devices wish to be in bypass mode when the IOMMU is in translation >>>>> mode, and why IOMMU defines/supports this case. Currently, I could >>>>> envision a scenario where a device is already connected to the IOMMU >>>>> in hardware, but it is not functioning correctly, or there are >>>>> performance impacts. If modifying the hardware is not feasible, a >>>>> default configuration that allows bypass mode could be provided as a >>>>> solution. There might be other scenarios that I might have overlooked. >>>>> It seems to me since IOMMU supports this configuration, it would be >>>>> advantageous to have an approach to achieve it, and DT might be a >>>>> flexible way. >>>> So far we've taken the approach that broken hardware is quirked in the >>>> kernel by matching OF compatible string pattners. This is HW that is >>>> completely broken and the IOMMU doesn't work at all for it. >>>> >>>> HW that is slow or whatever is not quirked and this is an admin policy >>>> choice where the system should land on the security/performance >>>> spectrum. >>>> >>>> So I'm not sure adding DT makes sense here. >>>> >>> Hi Jason, >>> Sorry for being late here, I hadn't noticed this reply earlier. The >>> approach seems to address the situation. Could you kindly provide >>> information about the location of the patches? I was wondering about >>> further details regarding this particular implementation. Thanks >> There are a couple versions, eg >> arm_smmu_def_domain_type() >> qcom_smmu_def_domain_type() >> > I thought what you mentioned earlier is that there is a new approach > being considered for this. I think what you point out is the same as > Anup mentioned. However, as I mentioned earlier, I am exploring a more > flexible approach to achieve this objective. This way, we can avoid > hard coding anything (i.e.list compatible string) in the driver or > requiring a kernel rebuild every time we need to change the mode for > specific devices. For example, the driver could parse the device node > to determine and record if a device will be set to bypass, and then > the .def_domain_type could be used to set to IOMMU_DOMAIN_IDENTITY by > the record. I'm not sure if it makes sense for everyone, it seems to > me that it would be great if there is a way to do this. 😄 What you described applies to the case where the device is *quirky*, it "is not functioning correctly" when the IOMMU is configured in DMA translation mode. But it could not be used in another case, as described above, where IOMMU translation has performance impacts on the device's DMA efficiency. This is a kind of a user policy and should not be achieved through the "DT/APCI + def_domain_type" mechanism. The iommu subsystem has provided a sysfs interface that users can use to change the domain type for devices. This means that users can change the domain type at their wishes, without having to modify the kernel configuration. Best regards, baolu