All of lore.kernel.org
 help / color / mirror / Atom feed
From: Easwar Hariharan <easwar.hariharan@linux.microsoft.com>
To: Joonwon Kang <joonwonkang@google.com>
Cc: will@kernel.org, robin.murphy@arm.com, joro@8bytes.org,
	jpb@kernel.org, easwar.hariharan@linux.microsoft.com,
	jgg@ziepe.ca, 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: Tue, 28 Apr 2026 10:38:37 -0700	[thread overview]
Message-ID: <e9de1b01-d075-487d-a00a-e2420b909f69@linux.microsoft.com> (raw)
In-Reply-To: <20260424085339.3503582-1-joonwonkang@google.com>

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@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)




  parent reply	other threads:[~2026-04-28 17:39 UTC|newest]

Thread overview: 21+ 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
2026-05-07  8:15   ` Tian, Kevin
2026-05-09 17:03     ` Jason Gunthorpe
2026-05-07  9:58   ` Joonwon Kang
2026-05-09 17:10     ` Jason Gunthorpe
2026-05-11 12:39       ` Robin Murphy
2026-05-11 13:21         ` Jason Gunthorpe
2026-05-12  9:57           ` Joonwon Kang
2026-05-12 12:40             ` Jason Gunthorpe
2026-05-12 13:53               ` Robin Murphy
2026-05-12 14:51                 ` Joonwon Kang
2026-05-12 15:11                   ` Jason Gunthorpe
2026-05-13 17:03                     ` Joonwon Kang
2026-05-13 17:10                       ` Jason Gunthorpe
2026-05-14  4:12                         ` Joonwon Kang
2026-05-12 10:07       ` Joonwon Kang
2026-04-28 17:38 ` Easwar Hariharan [this message]
2026-04-28 17:44   ` Jason Gunthorpe
  -- 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=e9de1b01-d075-487d-a00a-e2420b909f69@linux.microsoft.com \
    --to=easwar.hariharan@linux.microsoft.com \
    --cc=Alexander.Grest@microsoft.com \
    --cc=amhetre@nvidia.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@ziepe.ca \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.