Re: [PATCH v17 20/26] vfio: cleanup and refactor

["Burakov, Anatoly" <anatoly.burakov@intel.com>]

On 9/22/2026 10:02 AM, David Marchand wrote:
> On Wed, 16 Sept 2026 at 13:20, Burakov, Anatoly
> <anatoly.burakov@intel.com> 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