From: Joonwon Kang <joonwonkang@google•com>
To: kevin.tian@intel•com
Cc: Alexander.Grest@microsoft•com,
alexander.shishkin@linux•intel.com, amhetre@nvidia•com,
baolu.lu@linux•intel.com, bp@alien8•de,
dave.hansen@linux•intel.com,
easwar.hariharan@linux•microsoft.com, hpa@zytor•com,
iommu@lists•linux.dev, jacob.jun.pan@linux•intel.com,
jgg@ziepe•ca, joonwonkang@google•com, joro@8bytes•org,
jpb@kernel•org, kas@kernel•org, kees@kernel•org,
linux-arm-kernel@lists•infradead.org,
linux-kernel@vger•kernel.org, mingo@redhat•com,
nicolinc@nvidia•com, peterz@infradead•org, praan@google•com,
robin.murphy@arm•com, ryasuoka@redhat•com, smostafa@google•com,
sohil.mehta@intel•com, tglx@kernel•org, will@kernel•org,
x86@kernel•org, xin@zytor•com
Subject: RE: [PATCH v2] iommu: Allow device driver to use its own PASID space for SVA
Date: Mon, 25 May 2026 15:29:24 +0000 [thread overview]
Message-ID: <20260525152924.524721-1-joonwonkang@google.com> (raw)
In-Reply-To: <BL1PR11MB52710D3CCFA2F75F6B540A468C0A2@BL1PR11MB5271.namprd11.prod.outlook.com>
Hi Kevin, thanks for your review.
> > This commit resolves the issue by allowing device driver to maintain its
> > own PASID space and assign a PASID from that for the process-device bond
> > via a new API called `iommu_sva_bind_device_pasid(dev, mm, pasid)`. Doing
> > that, however, will disallow the process to execute the ENQCMD-like
> > instructions at EL0. It is because the process cannot change its PASID in
> > IA32_PASID(or ACCDATA_EL1 on ARM) for each device without the kernel's
> > intervention. For this reason, calling `iommu_sva_bind_device()` and then
> > `iommu_sva_bind_device_pasid()` for the same process will not be allowed
> > and vice versa.
> >
> > Currently, there is a limitation that a process simultaneously doing SVA
> > with multiple devices with different PASIDs is not supported. So, calling
> > `iommu_sva_bind_device_pasid()` multiple times for the same process with
> > different devices will not be allowed for now while that for
> > `iommu_sva_bind_device()` will be.
> >
> > Another limitation is that a process cannot do `iommu_sva_bind_device()`
> > if it has ever done `iommu_sva_bind_device_pasid()` even though it has
> > been unbound after use.
>
> Why not making it clean in one step instead of leaving many unsupported
> cases which are likely required soon in this "1" to "many" transition?
>
Since I did not know much about the IOMMU team's future plans on the IOMMU
core structure, I narrowed down the scope just enough to resolve our
specific problem and avoided introducing big change. But now that I have
two queries to support the 1-to-many relationships in this patchset, not
in a later one, I think it is fair enough to start working on it now. I
will try it and lift the limitations.
> for each mm:
> - one global pasid for ENQCMD or ST64BV0
> - an array of device local pasids tracked in [struct device *, pasid] tuple.
>
> upon gp fault or equivalent, fetch the global pasid.
>
> upon device-specific bind, match [dev, pasid].
>
> >
> > Suggested-by: Jason Gunthorpe <jgg@ziepe•ca>
> > Suggested-by: Kevin Tian <kevin.tian@intel•com>
> > Signed-off-by: Joonwon Kang <joonwonkang@google•com>
> > ---
> > v2: Reuse iommu_mm->pasid after SVA bound by
> > iommu_sva_bind_device_pasid()
> > is unbound.
>
> No idea what it talks about.
>
There was a bug in v1 that the second call for `iommu_sva_bind_device_pasid()`
failed after the first call with a different PASID was released. Will
rephrase it in a clearer language in v3.
> btw a new kAPI always needs accompanied users to review together.
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"?
Thanks,
Joonwon Kang
next prev parent reply other threads:[~2026-05-25 15:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-20 15:07 [PATCH v2] iommu: Allow device driver to use its own PASID space for SVA Joonwon Kang
2026-05-21 7:39 ` Baolu Lu
2026-05-21 8:25 ` Joonwon Kang
2026-05-25 8:10 ` Tian, Kevin
2026-05-25 15:29 ` Joonwon Kang [this message]
2026-05-25 16:47 ` Jason Gunthorpe
2026-05-26 6:58 ` Joonwon Kang
2026-05-26 7:21 ` Tian, Kevin
2026-05-26 8:44 ` Joonwon Kang
2026-05-26 12:36 ` Joonwon Kang
2026-05-26 12:39 ` Jason Gunthorpe
2026-05-26 12:46 ` Joonwon Kang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260525152924.524721-1-joonwonkang@google.com \
--to=joonwonkang@google$(echo .)com \
--cc=Alexander.Grest@microsoft$(echo .)com \
--cc=alexander.shishkin@linux$(echo .)intel.com \
--cc=amhetre@nvidia$(echo .)com \
--cc=baolu.lu@linux$(echo .)intel.com \
--cc=bp@alien8$(echo .)de \
--cc=dave.hansen@linux$(echo .)intel.com \
--cc=easwar.hariharan@linux$(echo .)microsoft.com \
--cc=hpa@zytor$(echo .)com \
--cc=iommu@lists$(echo .)linux.dev \
--cc=jacob.jun.pan@linux$(echo .)intel.com \
--cc=jgg@ziepe$(echo .)ca \
--cc=joro@8bytes$(echo .)org \
--cc=jpb@kernel$(echo .)org \
--cc=kas@kernel$(echo .)org \
--cc=kees@kernel$(echo .)org \
--cc=kevin.tian@intel$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=mingo@redhat$(echo .)com \
--cc=nicolinc@nvidia$(echo .)com \
--cc=peterz@infradead$(echo .)org \
--cc=praan@google$(echo .)com \
--cc=robin.murphy@arm$(echo .)com \
--cc=ryasuoka@redhat$(echo .)com \
--cc=smostafa@google$(echo .)com \
--cc=sohil.mehta@intel$(echo .)com \
--cc=tglx@kernel$(echo .)org \
--cc=will@kernel$(echo .)org \
--cc=x86@kernel$(echo .)org \
--cc=xin@zytor$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox