On Wed, 16 Sept 2026 at 13:20, Burakov, Anatoly <[email protected]> wrote: > > > > The main concern for drivers is the "class" (physical, virtual) of > > addresses. > > The noiommu notion was simple in that drivers understood they had to > > handle physical addresses. > > That is arguably still the case. It is the same semantic meaning, just > wrapped under a different name because I wanted to signal that using > no-iommu mode is bad practice. It's still effectively IOMMU vs no-IOMMU.
Drivers do not care about this "bad practice". No user will ever see this. Most of the code now is generated by AI. If you mix concerns in API, I am pretty sure the original intent will be lost/distorted and we will just see some funny claims like "such code is unsafe". > > > > There is some other concern about iommu capability that is not > > captured in the new API. > > Take a look at the PCI bus for example, where some decision is taken > > on a DMA mask. > > Arguably this is not *VFIO* related (it's rather the property of IOMMU) > so there is little place for that notion in this API except to group all > IOMMU stuff under the same roof, which may or may not be semantically > coherent depending on your view of what this API should be. Well, yes, but drivers do not care about VFIO in the first place. We may have a cleaner VFIO API now, but then drivers need to understand it. I just want to preach for a simple API for the drivers, and maybe we are missing an abstraction... > > > > In the end, it may mean that the whole iommu class discovery (that > > impacts IOVA mode) should get revisited too... ? > > > > At least, with an *internal* VFIO API, we can revisit more easily in > > the future, so those comments are not blocking the series. > > > > > > We can do all sorts of things now that we are allowed to, yes! ... but ok, I won't insist. We will see in the future... -- David Marchand
