Re: [PATCH 03/11] dt-bindings: Add RISC-V IOMMU bindings

[Baolu Lu]

On 2023/8/16 10:16, Zong Li wrote:
> On Wed, Aug 16, 2023 at 2:38 AM Jason Gunthorpe<jgg@xxxxxxxx>  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<jgg@xxxxxxxx>  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