On Tue, Jul 12, 2022 at 07:34:48PM +0100, Joao Martins wrote: > > In general I saw three options here: > > > > a) 'try and fail' when creating the domain. It succeeds only when > > all iommus support tracking; > > > > b) capability reported on iommu domain. The capability is reported true > > only when all iommus support tracking. This allows domain property > > to be set after domain is created. But there is no much gain of doing > > so when comparing to a). > > > > c) capability reported on device. future compatible for heterogenous > > platform. domain property is specified at domain creation and domains > > can have different properties based on tracking capability of attached > > devices. > > > > I'm inclined to c) as it is more aligned to Robin's cleanup effort on > > iommu_capable() and iommu_present() in the iommu layer which > > moves away from global manner to per-device style. Along with > > that direction I guess we want to discourage adding more APIs > > assuming 'all iommus supporting certain capability' thing? > > > > Not sure where we are left off on this one, so hopefully just for my own > clarification on what we see is the path forward. I prefer we stick to the APIs we know we already need. We need an API to create an iommu_domain for a device with a bunch of parameters. "I want dirty tracking" is a very reasonable parameter to put here. This can support "try and fail" if we want. We certainly need "c", somehow the userspace needs to know what inputs the create domain call will accept - minimally it needs to know what the IOMMU driver is under the device so it knows how to ask for a user space page table. This could also report other paramters that are interesting, like "device could support dirty tracking" Having the domain set to dirty tracking also means that it will refuse to attach to any device that doesn't have dirty tracking support (eg if there are non-uniformity in the iommu) - this composes will with the EMEDIUMTYPE work So, I would only change from your proposal to move to the create domain command. Which we should really pull out of one of the HW branchs and lock down RSN.. Jason
