From: Jason Gunthorpe <jgg@ziepe.ca>
To: Joonwon Kang <joonwonkang@google.com>
Cc: will@kernel.org, robin.murphy@arm.com, joro@8bytes.org,
jpb@kernel.org, nicolinc@nvidia.com, praan@google.com,
kees@kernel.org, amhetre@nvidia.com,
Alexander.Grest@microsoft.com, baolu.lu@linux.intel.com,
smostafa@google.com, linux-arm-kernel@lists.infradead.org,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] iommu: Enable per-device SSID space for SVA
Date: Fri, 24 Apr 2026 10:39:53 -0300 [thread overview]
Message-ID: <20260424133953.GY3611611@ziepe.ca> (raw)
In-Reply-To: <20260424085339.3503582-1-joonwonkang@google.com>
On Fri, Apr 24, 2026 at 08:53:39AM +0000, Joonwon Kang wrote:
> For SVA, the IOMMU core always allocates PASID from the global PASID
> space. The use of this global PASID space comes from the limitation of
> the ENQCMD instruction in Intel CPUs that it fetches its PASID operand
> from IA32_PASID, which is per-task.
That's right, and all the iommu drivers should have no issue with
per-device pasid or they are not following the API contract.. I
believe that has been taking care of already.
So, I don't think this is an iommu driver capability.
Instead, you have to decide if the PASID is per device or not based on
if the system will use ENQCMD or any similar instruction. I
understand ARM has introduced a similar instruction.
So you may be better off with some kind of 'arch has enqcmd like
instruction' to control this instead of involving the iommu driver.
> - The device is not a PCIe device.
> - The device is to use SVA.
> - The supported SSID/PASID space is very small for the device; only 1 to
> 3 SSIDs are supported.
Yuk
> With this setup, when other modules have allocated all the PASIDs that
> our device is expected to use from the global PASID space via APIs like
> iommu_alloc_global_pasid() or iommu_sva_bind_device(), SVA binding to
> our device fails due to the lack of available PASIDs.
So you have multiple SVA using devices as well? Or multiple instances
of the same device?
Jason
next prev parent reply other threads:[~2026-04-24 13:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-24 8:53 [PATCH RFC] iommu: Enable per-device SSID space for SVA Joonwon Kang
2026-04-24 13:39 ` Jason Gunthorpe [this message]
-- strict thread matches above, loose matches on Subject: below --
2026-04-24 8:50 Joonwon Kang
2026-04-24 8:57 ` 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=20260424133953.GY3611611@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=Alexander.Grest@microsoft.com \
--cc=amhetre@nvidia.com \
--cc=baolu.lu@linux.intel.com \
--cc=iommu@lists.linux.dev \
--cc=joonwonkang@google.com \
--cc=joro@8bytes.org \
--cc=jpb@kernel.org \
--cc=kees@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nicolinc@nvidia.com \
--cc=praan@google.com \
--cc=robin.murphy@arm.com \
--cc=smostafa@google.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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