Re: [RFC PATCH v6 05/11] iommu: Add a helper to validate a vIOMMU parent

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, Sep 29, 2026 at 04:15:27PM -0700, Jacob Pan wrote:
> Hi Jason,
> 
> On Tue, 29 Sep 2026 09:30:48 -0300
> Jason Gunthorpe <jgg@nvidia.com> wrote:
> 
> > On Mon, Sep 28, 2026 at 10:55:24PM -0700, Jacob Pan wrote:
> > 
> > > Also, we don't have a T=0 to T=1 transition, our intended external
> > > attach can be transitioned from a blocked domain, not from a paging
> > > domain to external.  
> > 
> > You kind of do, external is close to T=1..
> > 
> > > > I think you are going to have module dependency issues trying to
> > > > get the mshv driver's info into the iommu driver, adding a "TSM"
> > > > like driver would resolve that. ie mshv could just provide the
> > > > viommu. 
> > > I introduced a similar registration interface in hv-common to solve
> > > the module dep issue. Will look into if I can leverage the vIOMMU
> > > helper here.  
> > 
> > That doesn't sound so nice..
> > 
> > If we have to have registrations it is better to have the viommu
> > registration that Aneesh drafted than several schemes inside specific
> > drivers..
> Agreed. Now that the commonality with the TSM provider path is clear, I
> will adapt the MSHV support to use the generic vIOMMU provider
> registration.

Ah, I so I suggested he remove it as it was just for TSM.. We'd have
to ask it to come back

I still prefer the way TSM is shaping up because it solves all these
locking and matching issues nicely. I think you would have the same
general locking problems with a provider (regardless where you put it)
too..

Are you sure it can't be a TSM?

Jason