[PATCH RFC] iommu: Enable per-device SSID space for SVA
Easwar Hariharan
easwar.hariharan at linux.microsoft.com
Tue Apr 28 10:38:37 PDT 2026
On 4/24/2026 1:53 AM, 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.
>
> Due to this nature, SVA with ARM SMMU v3 has been found not working in
> our environment when other modules/devices compete for PASID. The
> environment looks as follows:
>
> - 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.
> - There is a custom way of transmitting the SSID from the kernel to the
> device.
>
> 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.
>
> Since SSID/PASID is supported per-SID in ARM SMMU v3, this commit
> leverages the fact and lifts the use of the global PASID space if
> possible. What it does includes:
>
> - Introduce a new IOMMU capability IOMMU_CAP_PER_DEV_PASID_SPACE, which
> represents whether the IOMMU supports an independent PASID space per-
> device, not shared across devices. ARM SMMU v3 is the case.
> - Open a new API iommu_attach_device_pasid_any() to allocate any
> available PASID and attach an IOMMU domain to it.
> - Opt out the use of the global PASID space for SVA if the IOMMU has
> that capability, and use the new API to allocate a PASID in that case.
>
> Signed-off-by: Joonwon Kang <joonwonkang at google.com>
> ---
> v1: Request comments for this approach, other possible approaches and/or
> other aspects to consider more. Code is not sanitized and commits are
> not separated appropriately in this version.
>
<snip>
This may be a a basic question, but how does this reconcile with the fact
that the process ID space is global? Even with PID namespacing, I understand
that each process in a PID namespace has a "parent" PID in the parent namespace,
unless I'm grossly mistaken.
Also, with the per-device PASID space, different SVA-capable devices
being used by the same process would have different PASIDs referring to the same
process address space, and would break the DSA<->IAA kind of interaction where the
device drivers can communicate the PASID among each other to operate on the same
process address space. Is that a scenario that does not matter to your use case?
Thanks,
Easwar (he/him)
More information about the linux-arm-kernel
mailing list