Hi Jason, On Mon, Aug 18, 2025 at 12:53:10PM -0300, Jason Gunthorpe wrote: > On Thu, Aug 14, 2025 at 07:32:36PM -0700, Shyam Saini wrote: > > On Thu, Aug 14, 2025 at 09:39:58PM -0300, Jason Gunthorpe wrote: > > > On Thu, Aug 14, 2025 at 04:30:18PM -0700, Shyam Saini wrote: > > > > or were you referring to [2]? > > > > > > > > In that case, the PCI child node data needs to be parsed, which is > > > > currently handled individually by each host controller driver. > > > > > > Yes, this looks like it may be what I was thinking of, the pci@1,0 > > > specifes the BDF effectively > > > > In that case, we'll need to parse the child DTS nodes properly > > within of_iommu_get_resv_regions(). I'll include this in v4. > > Kinda surprised this isn't happening already? It would be good to > refer to the original specs and describe how whatetever you propose is > aligned there.
Just to confirm, does the v3 version of this series look good to you? If so, I’ll go ahead and respin the series with the iommu_set_sw_msi() change and address the other review comments from Jacob. Otherwise having pci devices nodes in the fdt or dts needs additional handling, let me know your preference :) > > > > Presumably this is a fixed issue of the platform. You never did > > > explain how your system has such werdio behavior, or how something > > > like iommu=pt can function on it... > > Yes, this issue is platform-specific. On this platform, the default MSI IOVA > > range overlaps with an address region that is reserved for another purpose, > > Other than that we haven't observed any obvious issues for DMA operations > > Usually DRAM is at the default MSI IOVA address, so if you run > iommu=pt then presumably your DRAM map has a nice hole in it.. But > maybe the memory map told the OS about that. > our DRAM for this platform starts at higher offset, way beyond MSI_IOVA. Thanks, Shyam
