Hi Jason, On Thu, 10 Apr 2025 20:00:08 -0300 Jason Gunthorpe <j...@ziepe.ca> wrote:
> On Thu, Apr 10, 2025 at 03:50:27PM -0700, 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. Consequently, these > > platforms cannot reserve the MSI_IOVA_BASE address for MSI. > > The fundamental question remains: why is using IOVA 0x80000000, an arbitrarily chosen virtual address, a hardware issue? > > There was an [1] attempt to fix this problem by passing the MSI IOVA > > base as a kernel command line parameter. > > > > This patch series aims to address the issue by introducing a new DTS > > property, "arm,smmu-faulty-msi-iova" which can be used to hold > > faulty MSI IOVA address. This property can be passed to ARM SMMU > > drivers via device tree so that the drivers can select appropriate > > MSI IOVA base address which doesn't intersect with the faulty MSI > > IOVA address. > > I thought we already talked about this and you were not going to be > doing a DT proposal for a software knob? > > And then you didn't even link to the recent discussion :( > > https://lore.kernel.org/linux-iommu/20250403232619.ga681...@ziepe.ca/ > > It is easily solved in the smmuv3 driver without out any DT. Please > do that. Given the above fundamental question answered, then we do have a platform specific IOVA range to avoid, IMHO it must be enumerated via DT or some other means to avoid conflict. Per last discussion "SMMU driver have a list of potential addresses and select the first one that does not intersect with the non-working IOVA ranges.". If we don't know what the "non-working IOVA" is, how do we know it does not intersect the "potential addresses"? Thanks, Jacob
