Re: Question about reserved_regions w/ Intel IOMMU

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2023-06-20 18:47, Alexander Duyck wrote:
On Tue, Jun 20, 2023 at 9:55 AM Jason Gunthorpe <jgg@xxxxxxxxxx> wrote:

On Tue, Jun 20, 2023 at 07:57:57AM -0700, Alexander Duyck wrote:

I think this may have gone off down a rathole as my original question
wasn't anything about adding extra reserved regions. It was about
exposing what the IOVA is already reserving so it could be user
visible.

Your question points out that dma-iommu.c uses a different set of
reserved regions than everything else, and its set is closer to
functionally correct.

IMHO the resolution to what you are talking about is not to add more
debugging to dma-iommu but to make the set of reserved regions
consistently correct for everyone, which will make them viewable in
sysfs.

Okay, that makes sense to me, and I agree. If we had a consistent set
of reserved regions then it would make it easier to understand.

It would also be wrong, unfortunately, because it's conflating multiple different things (there are overlapping notions of "reserve" at play here...). IOMMU API reserved regions are specific things that the IOMMU driver knows are special and all IOMMU domain users definitely need to be aware of. iommu-dma is merely one of those users; it is another layer on top of the API which manages its own IOVA space how it sees fit, just like VFIO or other IOMMU-aware drivers. It honours those reserved regions (via iommu_group_create_direct_mappings()), but it also carves out plenty of IOVA space which is probably perfectly usable - some of which is related to possible upstream bus constraints, to save the hassle of checking; some purely for its own convenience, like the page at IOVA 0 - but it still *doesn't* carve out more IOVA regions which are also unusable overall due to other upstream bus or endpoint constraints, since those are handled dynamically in its allocator instead (dma_mask, bus_dma_limit etc.)

If
nothing else my request would be to expose the iova reserved regions
and then most likely the other ones could be deprecated since they
seem to all be consolidated in the IOVA anyway.

FWIW there's no upstream provision for debugging iommu-dma from userspace since it's not something that anyone other than me has ever had any apparent need to do, and you can get an idea of how long it's been since even I thought about that from when I seem to have given up rebasing my local patches for it[1] :)

Thanks,
Robin.

[1] https://gitlab.arm.com/linux-arm/linux-rm/-/commits/iommu/misc/



[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux