[PATCH v2] iommu: Allow device driver to use its own PASID space for SVA

[Joonwon Kang]

> On Tue, May 26, 2026 at 12:36:06PM +0000, Joonwon Kang wrote:
> > > > From: Joonwon Kang <joonwonkang at google.com>
> > > > Sent: Tuesday, May 26, 2026 2:58 PM
> > > > 
> > > > > On Mon, May 25, 2026 at 03:29:24PM +0000, Joonwon Kang wrote:
> > > > >
> > > > > > Currently, the only known expected user of the new kAPI is our team.
> > > > Since
> > > > > > I test if the patch resolves our problem before sending it, I believe it
> > > > > > should be good enough. Do you mean more than our team by
> > > > "accompanied
> > > > > > users"?
> > > > >
> > > > > He means you cannot send patches like this that only serve OOT drivers
> > > > > to the mainline kernel.
> > > > 
> > > > Hmm, it gets back to the chicken-and-egg problem. So, do you recommend
> > > > deferring the patch submission until we find a new in-tree user of the
> > > > new kAPI? I believe we will not make our module in-tree anytime soon.
> > > > Or, is it like I still can send the patch and get it reviewed although we
> > > > cannot merge it to the mainline?
> > > > 
> > > 
> > > It's not chicken-and-egg problem. Just always send them together.
> > > 
> > > so let's wait until your module is ready for in-tree review...
> > 
> > Since adding a new kAPI has this limitation, what do you think about the
> > idea of adding a new boot parameter to enforce disabling ENQCMD at EL0 and
> > using the non-global PASID space in that case? This way, I guess we could
> > resolve our issue without having to wait until we have new in-tree users.
> > Do you think it should have the same limitation?
> 
> No, you can't hack up the kernel for OOT drivers.

Alright, thanks for the confirmation.

Thanks,
Joonwon Kang