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/
