Hi Jason, Apologies for delayed reponse, > 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? Correct, this is limitation with our HW. Since we can't fix it in hardware, we would need to fix it in Linux. > > 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? even if we reserve it in dts we would still need some address reserved for MSI IOVA > 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? Unfortunately, it is an HW issue. Are you okay with this passing custom MSI_IOVA via DTS approach ? Thanks, Shyam
