On Tue, 23 Aug 2022 21:38:08 -0300 Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > So, I would prefer to comment it like this and if someone comes with a > driver that wants to use it in some other way they have to address > these problems so it works generally and correctly. I don't want to > write more code to protect against something that auditing tells us > doesn't happen today. > > The whole thing should naturally become fixed fairly soon, as once we > have Yishai and Joao's changes there will be no use for the dirty > tracking code in type1 that is causing this problem. I assume this is referring to the DMA logging interface and implementation for mlx5[1], but I don't see anyone else getting on board with that proposal (or reviewing). AIUI, most are waiting for system IOMMU DMA logging, so the above seems a bit of a bold claim. Do we expect system IOMMU logging flowing through this device feature or will there be an interface at the shared IOMMU context level? Do we expect mdev drivers supporting migration to track their dirty iovas locally and implement this feature? And touching on this question that wasn't addressed... On Tue, 23 Aug 2022 01:31:11 +0000 "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote: > > From: Alex Williamson <alex.williamson@xxxxxxxxxx> > > Sent: Tuesday, August 23, 2022 2:36 AM > > It's related to the dirty page scope. Use of the pinned page interface > > is essentially a contract with the IOMMU back-end that only pinned pages > > will be considered for the dirty page scope. However, type1 operates > > on groups, therefore we needed to create a restriction that only > > singleton groups could make use of page pinning such that the dirty > > page scope could be attached to the group. > > I get the former part but not the latter. Can you elaborate why > multi-device group can not be attached by the dirty page scope? > It's kind of sharing the scope by all devices in the group. There's no fundamental reason we couldn't do it. At the time it wasn't necessary and wasn't convenient since type1 operated exclusively on groups. Now maybe we'd expand the device_list beyond just devices with dma_unmap callbacks and link page pinning to the device rather than the group to get better granularity, but that all seems to be work in the opposite direction from where we want the IOMMU uAPI to go. If type1 dirty logging goes away and moves to the drivers, we could scrap the singleton requirement, but as Jason notes, expanding its use to hack around regions that can't fault is a bit of an abuse of the intended use case. Thanks, Alex [1]20220815151109.180403-1-yishaih@xxxxxxxxxx
