On Tue, Oct 15, 2024 at 09:47:23AM -0300, Jason Gunthorpe wrote: > On Tue, Oct 15, 2024 at 08:13:28AM +0000, Pranjal Shrivastava wrote: > > > Umm.. this was specific for rmr not a generic thing. I'd suggest to > > avoid meddling with the STEs directly for acheiving bypass. Playing > > with the iommu domain type could be neater. Perhaps, modify the > > ops->def_domain_type to return an appropriate domain? > > Yeah, that is the expected way, to force the def_domain_type to > IDENTITY and refuse to attach a PAGING/BLOCKED domain. > > If this is a common thing we could have the core code take on more of > the job. Yes! I've seen the IOMMU being bypassed at multiple places, primarily for performance, people like bypassing the iommu for "trusted" devices. A few examples that are publically accessible: Qcomm SoCs [1], [2]. Seems like Qualcomm have a DT property `qcomm-s1-bypass` to achieve something similar. In fact, *blast from the past*, I tried to do something similar sometime ago with [3]. Although, perhaps that wasn't the best way (and I was a kernel newbie :)) A little off-topic, but I think there has been some interest to bypass the default substream as well while still maintaining PASID isolation.[4] Although, as far as arm-smmu-v3 is concerned, IIRC, I think there was a way to tell that the region is reserved and don't map it. > > Jason Thanks, Pranjal [1] https://github.com/realme-kernel-opensource/realme5-kernel-source/blob/master/arch/arm64/boot/dts/qcom/sa8155-vm-qupv3.dtsi#L22 [2] https://android.googlesource.com/kernel/msm/+/android-7.1.0_r0.2/Documentation/devicetree/bindings/platform/msm/ipa.txt#28 [3] https://lore.kernel.org/all/20230707104857.348353-1-praan@xxxxxxxxxx/ [4] https://lore.kernel.org/all/CAGfWUPziSWNMc_px4E-i+_V_Jxdb_WSwOLXHZ+PANz2Tv5pFPA@xxxxxxxxxxxxxx/