[PATCH v5 00/27] Update SMMUv3 to the modern iommu API (part 2/3)

[Jason Gunthorpe]

On Mon, Mar 25, 2024 at 09:06:23PM +0000, Mostafa Saleh wrote:
> On Mon, Mar 25, 2024 at 11:35:03AM -0300, Jason Gunthorpe wrote:
> > On Sat, Mar 23, 2024 at 01:38:04PM +0000, Mostafa Saleh wrote:
> > > Hi Jason,
> > > 
> > > On Mon, Mar 04, 2024 at 07:43:48PM -0400, Jason Gunthorpe wrote:
> > > > Continuing the work of part 1 this focuses on the CD, PASID and SVA
> > > > components:
> > > > 
> > > >  - attach_dev failure does not change the HW configuration.
> > > > 
> > > >  - Full PASID API support including:
> > > >     - S1/SVA domains attached to PASIDs
> > > 
> > > I am still going through the series, but I see at the end the main SMMUv3
> > > driver has set_dev_pasid operation, are there any in-tree drivers that
> > > use that? (and how can I test it).
> > 
> > Not yet, but some will be coming. Currently only Intel driver supports
> > it, but Intel HW has other problems making it unusable..
> > 
> > A big part of the effort here is to enable the platform ecosystem so
> > devices and drivers can use it.  Moritz has access to a device that
> > can exercise this, though we are still working on it.
> 
> Just out of curiosity, are there plans to upstream that driver?

I expect so, but until it passes out of the evaluation stage and into
a production stage it isn't something guaranteed. The team working on
it needs a HW/SW ecosystem to test the device on which is only now
just barely starting to exist.

> I see, thanks for confirming, I am still going through the series, but
> I now wonder if this case is worth the extra complexity, unlike the STE
> where the hitless transition was usefull in many cases.

Well, it is worth it to convert everything into 'make' functions for
sure.

At that point it is just re-using the complexity that already
exists. Implementing a special programming logic just for CD that did
the V/0=1 and EPD0 special case as open coded would be more code than
adding ops.

Jason