Hi all, On 10/5/20 3:08 PM, Christoph Hellwig wrote: > On Mon, Oct 05, 2020 at 11:44:10AM +0100, Lorenzo Pieralisi wrote: >>> I see that there are both OF and ACPI hooks in pci_dma_configure() and >>> both modify dev->dma_mask, which is what pci-sysfs is exposing here, >>> but I'm not convinced this even does what it's intended to do. The >>> driver core calls this via the bus->dma_configure callback before >>> probing a driver, but then what happens when the driver calls >>> pci_set_dma_mask()? This is just a wrapper for dma_set_mask() and I >>> don't see anywhere that would take into account the existing >>> dev->dma_mask. It seems for example that pci_dma_configure() could >>> produce a 42 bit mask as we have here, then the driver could override >>> that with anything that the dma_ops.dma_supported() callback finds >>> acceptable, and I don't see any instances where the current >>> dev->dma_mask is considered. Am I overlooking something? >> >> I don't think so but Christoph and Robin can provide more input on >> this - it is a long story. >> >> ACPI and OF bindings set a default dma_mask (and dev->bus_dma_limit), >> this does not prevent a driver from overriding the dev->dma_mask but DMA >> mapping code still takes into account the dev->bus_dma_limit. >> >> This may help: >> >> git log -p 03bfdc31176c
Thank you Lorenzo for the pointer. > > This is at best a historic artefact. Bus drivers have no business > messing with the DMA mask, dev->bus_dma_limit is the way to communicate > addressing limits on the bus (or another interconnect closer to the CPU). > Then could I envision to use the dev->bus_dma_limit instead of the dev->dma_mask? Nevertheless, I would need a way to let the userspace know that the usable IOVA ranges reported by VFIO_IOMMU_TYPE1_INFO_CAP_IOVA_RANGE takes into account the addressing limits of the bus. Thanks Eric