On Tue, Jan 21, 2025 at 01:49:10PM -0800, Jacob Pan wrote: > > 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()? > > I don't know the platform impact but just to clarify, are you asking > whether this non-functional IOVA is also under IORT RMR or other FW > tables? I don't think it is. No, I'm asking how can you possibly have a HW platform where MSI_IOVA_BASE is unable to be used for DMA? MSI_IOVA_BASE is 128M, and most ARM platforms put DRAM starting at 0. Most ARM VMMs put DRAM starting at 0 too. So a platform saying that DMA to 128M doesn't work is pretty broken, to the point it is hard to believe there is a HW issue at work here? > But this special IOVA is reflected in iommu_get_resv_regions() the same > way as the hardcoded MSI_IOVA_BASE. So each iommu group's > reserved_regions should show. That's great > > Why not avoid this conflict in your platform software? > I had the same question but it seems there is not enough difference > (than the standard smmu) to justify a platform code. i.e. platform > specific iommu_get_resv_regions(), is that what you are suggesting? And here I mean, why not stop marking it reserved in the ACPI/DT inside your firwmare or hypervisor? This smells like some SW component using the same address Linux uses for some odd purpose. Just change it and let Linux keep using the address it wants? Jason
