From: Baolu Lu <baolu.lu@linux.intel.com>
To: Zong Li <zong.li@sifive.com>, Anup Patel <apatel@ventanamicro.com>
Cc: baolu.lu@linux.intel.com, Tomasz Jeznach <tjeznach@rivosinc.com>,
Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Albert Ou <aou@eecs.berkeley.edu>,
linux@rivosinc.com, linux-kernel@vger.kernel.org,
Sebastien Boeuf <seb@rivosinc.com>,
iommu@lists.linux.dev, Palmer Dabbelt <palmer@dabbelt.com>,
Nick Kossifidis <mick@ics.forth.gr>,
linux-riscv@lists.infradead.org
Subject: Re: [PATCH 03/11] dt-bindings: Add RISC-V IOMMU bindings
Date: Wed, 26 Jul 2023 11:21:34 +0800 [thread overview]
Message-ID: <592edb17-7fa4-3b5b-2803-e8c50c322eee@linux.intel.com> (raw)
In-Reply-To: <CANXhq0q7R9Srx6U=fReq7LDLFgW6rMmjKH=o6MzDT5AWNRXP6w@mail.gmail.com>
On 2023/7/24 21:23, Zong Li wrote:
>>>>> In RISC-V IOMMU, certain devices can be set to bypass mode when the
>>>>> IOMMU is in translation mode. To identify the devices that require
>>>>> bypass mode by default, does it be sensible to add a property to
>>>>> indicate this behavior?
>>>> Bypass mode for a device is a property of that device (similar to dma-coherent)
>>>> and not of the IOMMU. Other architectures (ARM and x86) never added such
>>>> a device property for bypass mode so I guess it is NOT ADVISABLE to do it.
>>>>
>>>> If this is REALLY required then we can do something similar to the QCOM
>>>> SMMU driver where they have a whitelist of devices which are allowed to
>>>> be in bypass mode (i.e. IOMMU_DOMAIN_IDENTITY) based their device
>>>> compatible string and any device outside this whitelist is blocked by default.
>>>>
>>> I have considered that adding the property of bypass mode to that
>>> device would be more appropriate. However, if we want to define this
>>> property for the device, it might need to go through the generic IOMMU
>>> dt-bindings, but I'm not sure if other IOMMU devices need this. I am
>>> bringing up this topic here because I would like to explore if there
>>> are any solutions on the IOMMU side, such as a property that indicates
>>> the phandle of devices wishing to set bypass mode, somewhat similar to
>>> the whitelist you mentioned earlier. Do you think we should address
>>> this? After all, this is a case of RISC-V IOMMU supported.
>> Bypass mode is a common feature across IOMMUs. Other IOMMUs don't
>> have a special property for bypass mode at device-level or at IOMMU level,
>> which clearly indicates that defining a RISC-V specific property is not the
>> right way to go.
>>
>> The real question is how do we set IOMMU_DOMAIN_IDENTITY (i.e.
>> bypass/identity domain) as the default domain for certain devices ?
>>
>> One possible option is to implement def_domain_type() IOMMU operation
>> for RISC-V IOMMU which will return IOMMU_DOMAIN_IDENTITY for
>> certain devices based on compatible string matching (i.e. whitelist of
>> devices). As an example, refer qcom_smmu_def_domain_type()
>> of drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>
> That is indeed one way to approach it, and we can modify the
> compatible string when we want to change the mode. However, it would
> be preferable to explore a more flexible approach to achieve this
> goal. By doing so, we can avoid hard coding anything in the driver or
> having to rebuild the kernel whenever we want to change the mode for
> certain devices. While I have considered extending a cell in the
> 'iommus' property to indicate a device's desire to set bypass mode, it
> doesn't comply with the iommu documentation and could lead to
> ambiguous definitions.
Hard coding the matching strings in the iommu driver is definitely not a
preferable way. A feasible solution from current code's point of view is
that platform opt-in the device's special requirements through DT or
ACPI. And in the def_domain_type callback, let the iommu core know that,
hence it can allocate a right type of domain for the device.
Thoughts?
Best regards,
baolu
next prev parent reply other threads:[~2023-07-26 3:21 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-19 19:33 [PATCH 00/13] Linux RISC-V IOMMU Support Tomasz Jeznach
2023-07-19 19:33 ` [PATCH 01/11] RISC-V: drivers/iommu: Add RISC-V IOMMU - Ziommu support Tomasz Jeznach
2023-07-19 20:49 ` Conor Dooley
2023-07-19 21:43 ` Tomasz Jeznach
2023-07-20 19:27 ` Conor Dooley
2023-07-21 9:44 ` Conor Dooley
2023-07-20 10:38 ` Baolu Lu
2023-07-20 12:31 ` Baolu Lu
2023-07-20 17:30 ` Tomasz Jeznach
2023-07-28 2:42 ` Zong Li
2023-08-02 20:15 ` Tomasz Jeznach
2023-08-02 20:25 ` Conor Dooley
2023-08-03 3:37 ` Zong Li
2023-08-03 0:18 ` Jason Gunthorpe
2023-08-03 8:27 ` Zong Li
2023-08-16 18:05 ` Robin Murphy
2024-04-13 10:15 ` Xingyou Chen
2023-07-19 19:33 ` [PATCH 02/11] RISC-V: arch/riscv/config: enable RISC-V IOMMU support Tomasz Jeznach
2023-07-19 20:22 ` Conor Dooley
2023-07-19 21:07 ` Tomasz Jeznach
2023-07-20 6:37 ` Krzysztof Kozlowski
2023-07-19 19:33 ` [PATCH 03/11] dt-bindings: Add RISC-V IOMMU bindings Tomasz Jeznach
2023-07-19 20:19 ` Conor Dooley
[not found] ` <CAH2o1u6CZSb7pXcaXmh7dJQmNZYh3uORk4x7vJPrb+uCwFdU5g@mail.gmail.com>
2023-07-19 20:57 ` Conor Dooley
2023-07-19 21:37 ` Rob Herring
2023-07-19 23:04 ` Tomasz Jeznach
2023-07-24 8:03 ` Zong Li
2023-07-24 10:02 ` Anup Patel
2023-07-24 11:31 ` Zong Li
2023-07-24 12:10 ` Anup Patel
2023-07-24 13:23 ` Zong Li
2023-07-26 3:21 ` Baolu Lu [this message]
2023-07-26 4:26 ` Zong Li
2023-07-26 12:17 ` Jason Gunthorpe
2023-07-27 2:42 ` Zong Li
2023-08-09 14:57 ` Jason Gunthorpe
2023-08-15 1:28 ` Zong Li
2023-08-15 18:38 ` Jason Gunthorpe
2023-08-16 2:16 ` Zong Li
2023-08-16 4:10 ` Baolu Lu
2023-07-19 19:33 ` [PATCH 04/11] MAINTAINERS: Add myself for RISC-V IOMMU driver Tomasz Jeznach
2023-07-20 12:42 ` Baolu Lu
2023-07-20 17:32 ` Tomasz Jeznach
2023-07-19 19:33 ` [PATCH 05/11] RISC-V: drivers/iommu/riscv: Add sysfs interface Tomasz Jeznach
2023-07-20 6:38 ` Krzysztof Kozlowski
2023-07-20 18:30 ` Tomasz Jeznach
2023-07-20 21:37 ` Krzysztof Kozlowski
2023-07-20 22:08 ` Conor Dooley
2023-07-21 3:49 ` Tomasz Jeznach
2023-07-20 12:50 ` Baolu Lu
2023-07-20 17:47 ` Tomasz Jeznach
2023-07-19 19:33 ` [PATCH 06/11] RISC-V: drivers/iommu/riscv: Add command, fault, page-req queues Tomasz Jeznach
2023-07-20 3:11 ` Nick Kossifidis
2023-07-20 18:00 ` Tomasz Jeznach
2023-07-20 18:43 ` Conor Dooley
2023-07-24 9:47 ` Zong Li
2023-07-28 5:18 ` Tomasz Jeznach
2023-07-28 8:48 ` Zong Li
2023-07-20 13:08 ` Baolu Lu
2023-07-20 17:49 ` Tomasz Jeznach
2023-07-29 12:58 ` Zong Li
2023-07-31 9:32 ` Nick Kossifidis
2023-07-31 13:15 ` Zong Li
2023-07-31 23:35 ` Nick Kossifidis
2023-08-01 0:37 ` Zong Li
2023-08-02 20:28 ` Tomasz Jeznach
2023-08-02 20:50 ` Tomasz Jeznach
2023-08-03 8:24 ` Zong Li
2023-08-16 18:49 ` Robin Murphy
2023-07-19 19:33 ` [PATCH 07/11] RISC-V: drivers/iommu/riscv: Add device context support Tomasz Jeznach
2023-08-16 19:08 ` Robin Murphy
2023-07-19 19:33 ` [PATCH 08/11] RISC-V: drivers/iommu/riscv: Add page table support Tomasz Jeznach
2023-07-25 13:13 ` Zong Li
2023-07-31 7:19 ` Zong Li
2023-08-16 21:04 ` Robin Murphy
2023-07-19 19:33 ` [PATCH 09/11] RISC-V: drivers/iommu/riscv: Add SVA with PASID/ATS/PRI support Tomasz Jeznach
2023-07-31 9:04 ` Zong Li
2023-07-19 19:33 ` [PATCH 10/11] RISC-V: drivers/iommu/riscv: Add MSI identity remapping Tomasz Jeznach
2023-07-31 8:02 ` Zong Li
2023-08-16 21:43 ` Robin Murphy
2023-07-19 19:33 ` [PATCH 11/11] RISC-V: drivers/iommu/riscv: Add G-Stage translation support Tomasz Jeznach
2023-07-31 8:12 ` Zong Li
2023-08-16 21:13 ` Robin Murphy
[not found] ` <CAHCEehJKYu3-GSX2L6L4_VVvYt1MagRgPJvYTbqekrjPw3ZSkA@mail.gmail.com>
2024-02-23 14:04 ` [PATCH 00/13] Linux RISC-V IOMMU Support Zong Li
2024-04-04 17:37 ` Tomasz Jeznach
2024-04-10 5:38 ` Zong Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=592edb17-7fa4-3b5b-2803-e8c50c322eee@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=aou@eecs.berkeley.edu \
--cc=apatel@ventanamicro.com \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux@rivosinc.com \
--cc=mick@ics.forth.gr \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=robin.murphy@arm.com \
--cc=seb@rivosinc.com \
--cc=tjeznach@rivosinc.com \
--cc=will@kernel.org \
--cc=zong.li@sifive.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).