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

[Joonwon Kang <joonwonkang@google.com>]

> > From: Joonwon Kang <joonwonkang@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?

Thanks,
Joonwon Kang