On Thu, Jan 16, 2025 at 03:23:04PM -0800, Shyam Saini wrote: > Hi, > > Currently, the MSI_IOVA_BASE address is hard-coded to 0x80000000, > assuming that all platforms have this address available for MSI IOVA > reservation. However, this is not always the case, as some platforms > reserve this address for other purposes. Can you explain this some more? This address is in the kernel controlled IOVA space, there are few ways a platform can impact this. How is the platform impacting it? Is the non-functional IOVA always reflected in the iommu_get_resv_regions()? Why not avoid this conflict in your platform software? > There was an [1] attempt to fix this problem by passing the MSI IOVA > base as a kernel command line parameter. Yuk > In the previous attempt, > Will suggested reserving the MSI IOVA at runtime whenever there is a > conflict with the default MSI_IOVA_BASE. However, dynamically reserving > this address has debuggability concerns, as it becomes difficult to > track IOMMU mapping failures. Still, this approach seems like the best to me.. > This patch series aims to address the issue by introducing a new DTS > property, "arm,smmu-pci-msi-iova-data". This property allows the > configuration of MSI IOVA with a custom MSI base address and a custom > length for IOMMU/SMMU drivers. It accommodates platforms that do not > have the default MSI base address available for MSI reservation. My understand was using DT to set kernel configurables was frowned upon? Ultimately MSI_IOVA_BASE is an arbitary choice by kernel software. Jason