Just to make this clear, I won't apply Christoph's patch (the one in this email thread) and instead the only change I will make is to rename dma_limit to dma_mask. On Tue, Apr 30, 2019 at 1:05 PM Robin Murphy <robin.murphy@xxxxxxx> wrote: > > On 30/04/2019 12:32, Christoph Hellwig wrote: > > On Tue, Apr 30, 2019 at 12:27:02PM +0100, Robin Murphy wrote: > >>> Hmm, I don't think we need the DMA mask for the MSI mapping, this > >>> should probably always use a 64-bit mask. > >> > >> If that were true then we wouldn't need DMA masks for regular mappings > >> either. If we have to map the MSI doorbell at all, then we certainly have to > >> place it at an IOVA that the relevant device is actually capable of > >> addressing. > > > > Well, as shown by the patch below we don't even look at the DMA mask > > for the MSI page - we just allocate from bottom to top. > > In the trivial cookie for unmanaged domains, yes, but in that case the > responsibility is on VFIO to provide a suitable (i.e. sub-32-bit) > address range for that cookie in the first place. In the managed case, > allocation uses the streaming mask via iommu_dma_get_msi_page() calling > __iommu_dma_map(). Admittedly the mask can then get overlooked when > reusing an existing mapping, which strictly could pose a problem if you > have multiple devices with incompatible masks in the same group (and > such that the PCI stuff doesn't already mitigate it), but that's such an > obscure corner case that I'm reticent to introduce the complication to > handle it until it's actually proven necessary. > > Robin.
