On 9/22/2026 10:02 AM, David Marchand wrote:
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".
Fair enough. I will pick a better name.
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...
We really do miss a generic IOMMU abstraction but the problem is I don't
like building abstractions that only have one user (VFIO) and that mix
different subsystems into one blob. The one saving grace of such an
approach is that this API is no longer public so we're allowed to do
whatever and experiment.
I agree that a simpler API is a valid goal, and in fact this
refactor/rework is in large part *about* simplifying the container
assignment API. The IOMMU stuff really was tacked on at the last minute
because I noticed that despite earlier talk about how cdev mode is not
going to provide no-IOMMU support, that actually did end up happening,
so I added another axis to my API.
We can't make drivers *not care about VFIO* unless we replace the
terminology wholesale (containers, cdev/group modes, etc), and arguably
while drivers don't care about *internals* of VFIO, some drivers *do*
care about VFIO specifically, and the extra stuff in the API is for
them. DMA mask isn't really about VFIO because it affects physical
addressing ranges too, not just IOVA. So if there is an abstraction here
that maps well onto VFIO API *and* the DMA mask, I'm not quite seeing it.
(not saying it's not there, maybe I'm just tunnel visioning on this
after having spent so much work on VFIO! I'm all for good suggestions on
this front)
--
Thanks,
Anatoly
