On Wed, Mar 18, 2020 at 05:14:05PM +0100, Auger Eric wrote: > Hi, > > On 3/18/20 1:00 PM, Robin Murphy wrote: > > On 2020-03-18 11:40 am, Jean-Philippe Brucker wrote: > >> We don't currently support IOMMUs with a page granule larger than the > >> system page size. The IOVA allocator has a BUG_ON() in this case, and > >> VFIO has a WARN_ON(). > > Adding Alex in CC in case he has time to jump in. At the moment I don't > get why this WARN_ON() is here. > > This was introduced in > c8dbca165bb090f926996a572ea2b5b577b34b70 vfio/iommu_type1: Avoid overflow > > >> > >> It might be possible to remove these obstacles if necessary. If the host > >> uses 64kB pages and the guest uses 4kB, then a device driver calling > >> alloc_page() followed by dma_map_page() will create a 64kB mapping for a > >> 4kB physical page, allowing the endpoint to access the neighbouring 60kB > >> of memory. This problem could be worked around with bounce buffers. > > > > FWIW the fundamental issue is that callers of iommu_map() may expect to > > be able to map two or more page-aligned regions directly adjacent to > > each other for scatter-gather purposes (or ring buffer tricks), and > > that's just not possible if the IOMMU granule is too big. Bounce > > buffering would be a viable workaround for the streaming DMA API and > > certain similar use-cases, but not in general (e.g. coherent DMA, VFIO, > > GPUs, etc.) > > > > Robin. > > > >> For the moment, rather than triggering the IOVA BUG_ON() on mismatched > >> page sizes, abort the virtio-iommu probe with an error message. > > I understand this is a introduced as a temporary solution but this > sounds as an important limitation to me. For instance this will prevent > from running a fedora guest exposed with a virtio-iommu with a RHEL host. Looks like you have another argument for nested translation :) We could probably enable 64k-4k for VFIO, but I don't think we can check and fix all uses of iommu_map() across the kernel, even if we disallow IOMMU_DOMAIN_DMA for this case. Thanks, Jean _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
