From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: "Kumar G, Naresh" <naresh.kumar.g@intel.com>,
intel-xe@lists.freedesktop.org
Cc: himal.prasad.ghimiray@intel.com, Matthew Brost <matthew.brost@intel.com>
Subject: Re: [PATCH 0/6] ATS/PASID SVA support and PRI-less fault servicing
Date: Thu, 22 Oct 2026 13:12:13 +0200 [thread overview]
Message-ID: <49204d78b2ebd1211663b0fedfec9037a09bdd59.camel@linux.intel.com> (raw)
In-Reply-To: <7c0b318c-3074-4c6c-aacd-5a8d6aa4a3b9@intel.com>
On Thu, 2026-10-22 at 12:00 +0530, Kumar G, Naresh wrote:
> Hi Thomas,
>
> On 10/21/2026 8:55 PM, Thomas Hellström wrote:
> > Hi!
> >
> > On Wed, 2026-10-21 at 09:41 +0530, Nareshkumar Gollakoti wrote:
> > > This series adds initial Shared Virtual Addressing (SVA) support
> > > for
> > > xe
> > > on platforms where ATS and PASID are available but PRI is not
> > > enabled
> > > or
> > > not supported.
> > >
> > > For SVA, the device must be able to issue memory transactions
> > > tagged
> > > with a PASID so that address translation is performed in the
> > > process
> > > address space rather than in a driver owned address space. This
> > > series
> > > adds the xe side infrastructure needed for that flow: VM support
> > > for
> > > SVA
> > > PASID state, PASID retriveal helpers, and programming of
> > > CTX_SYS_PASID
> > > for ATS and PASID enabled contexts.
> > >
> > > On systems with PRI, device page faults can be surfaced and
> > > resolved
> > > through the hardware page request interface, so the driver does
> > > not
> > > need
> > > to implement a separate fault servicing path for SVA.
> > > On non PRI systems, that hardware assisted fault path is
> > > unavailable.In
> > > that case, the driver still needs a way to resolve faults against
> > > the
> > > backing process address space so execution can proceed.
> > >
> > > To support that case, this series introduces a CPU mirror VMA and
> > > uses
> > > it as part of a driver managed SVM path for SVA faults without
> > > PRI.The
> > > purpose of the CPU mirror VMA is to provide a CPU side VMA
> > > representation for the address range being accesses through
> > > SVA,so
> > > the
> > > driver can rely on the kernel MM/VMA machinery to validate
> > > mappings
> > > and
> > > resolve backing pages for fault handling in the absence of PRI.In
> > > other words, since the device cannot issue PRI requests, the
> > > driver
> > > needs a CPU visible VMA context that mirrors the GPU SVA range
> > > closely
> > > enough to let faults be service through normal MM paths.
> > >
> > > At a high level, this series does the following:
> > >
> > > 1. log ATS/PASID enablement state during probe,
> > > 2. add VM infrastructure needed for SVA PASID support,
> > > 3. add a helper to retrieve the VM SVA PASID,
> > > 4. program CTX_SYS_PASID for ATS/PASID-enabled contexts,
> > > 5. add a PCI helper for ATS/PASID operation without PRI,
> > > 6. add a CPU mirror VMA for handling SVA faults on non PRI
> > > platforms
> > >
> > > Patches 1-5 provide the ATS/PASID and VM/context plumbing needed
> > > for
> > > this flow and have been validated internally.Patch 6 adds the non
> > > PRI
> > > fault servicing path, and feedback on that overall approach would
> > > be
> > > especially appreciated.
> > I was under the impression that we'd integrate this with current
> > SVM so
> > that we can still migrate to VRAM and use page-table mirroring or
> > keep
> > data in system memory and use SVA page-table sharing *OR* page-
> > table-
> > mirroring depending on user-space's wish?
> >
> > Thanks,
> > Thomas
>
> IMO, Yes, that is the intended model. Userspace picks between the two
> approaches with the bind.
>
> Bind with CPU_ADDR_MIRROR → existing SVM. GPU page fault, optional
> VRAM
> migrate, PPGTT mirroring and this path is unchanged.
>
> Do not bind → SVA page-table sharing. IOMMU walks the CPU page tables
> with ATS+PASID. Backing has to stay in system memory. This is the
> end-to-end share flow, and it needs ATS+PASID+PRI.
>
> If PRI is missing, an ATS miss cannot be healed by the IOMMU. The
> device
> then reports a GPU page fault. Instead of NACKing that unbound fault,
> we
> create a CPU-mirror VMA and service it with the same SVM path so the
> GPU
> gets a PPGTT mapping.
>
>
> So, ATS+PASID+PRI → share works as user space asked (no bind). Bind
> with CPU_ADDR_MIRROR → SVM, independent of PRI. *PRI-less is only the
> recovery path when share cannot complete at the IOMMU*.(This is one
> of
> the proposal)
>
>
> Let me know if anything am missing.
Yes, first on the (implicit) UAPI, KMD must never implicitly create a
GPU_VMA. This is done to be able to handle page-faults for non-PRI
capable hardware. Couldn't that be done much easier with a separate
page-fault handler that just calls fixup_user_fault() or a similar in-
kernel API and mark the gpu fault as handled? Then I assume the
ATS+PASID request will be retried?
On the implicit "Everything not having a GPU vma will be using
ATS/PASID" I strongly oppose that. Was this discussed on the UAPI
channel? Does NEO have any patches published to back this up?
ATS/PASID enables us to HW optimize a subset of the existing SVM
functionality, and IMO KMD is the best judge of whether to use it or
not, possibly with a UMD madvise hint. IMO we should require a
CPU_ADDR_MIRROR vma covering also the ATS/PASID regions and add an
MADVISE setting for user-space to prefer ATS/PASID lookups over current
hmm mirroring. If user-space then selects an MADVISE setting that is
incompatible with ATS/PASID (like different PAT, VRAM preferred region
etc.) Then KMD can transparently move over to that. We can also reuse
existing igts and user-space. If UMD needs to detect whether ATS/PASID
is usable on the VM then I figure we also must consider that.
Finally, it looks like you don't use the XE_PAGE_FORCE_FAULT bit, like
in here:
https://patchwork.freedesktop.org/patch/657641/?series=149886&rev=3
How would you then stop the hardware from attempting an ATS/PASID
lookup rather than faulting in mapped VMA?
Thanks,
Thomas
>
>
> Thanks,
>
> Naresh
>
> >
> > > Himal Prasad Ghimiray (1):
> > > drm/xe/vm: Setup SVA infrastructure for PASID support
> > >
> > > Nareshkumar Gollakoti (5):
> > > drm/xe/pci: log ATS/PASID enablement state at probe
> > > drm/xe/vm: add helper to retrieve VM SVA PASID
> > > drm/xe/lrc: program CTX_SYS_PASID for ATS/PASID-enabled
> > > contexts
> > > drm/xe/pci: add helper for ATS/PASID without PRI
> > > drm/xe/pagefault: add CPU mirror VMA for SVA faults without
> > > PRI
> > >
> > > drivers/gpu/drm/xe/regs/xe_lrc_layout.h | 6 +++
> > > drivers/gpu/drm/xe/xe_lrc.c | 37 ++++++++++++++++
> > > drivers/gpu/drm/xe/xe_pagefault.c | 49
> > > ++++++++++++++++++++++
> > > drivers/gpu/drm/xe/xe_pagefault_types.h | 6 +++
> > > drivers/gpu/drm/xe/xe_pci.c | 7 ++++
> > > drivers/gpu/drm/xe/xe_pci.h | 15 +++++++
> > > drivers/gpu/drm/xe/xe_vm.c | 56
> > > +++++++++++++++++++++++++
> > > drivers/gpu/drm/xe/xe_vm.h | 2 +
> > > drivers/gpu/drm/xe/xe_vm_types.h | 6 +++
> > > 9 files changed, 184 insertions(+)
next prev parent reply other threads:[~2026-10-22 11:24 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-21 4:11 [PATCH 0/6] ATS/PASID SVA support and PRI-less fault servicing Nareshkumar Gollakoti
2026-10-21 4:11 ` [PATCH 1/6] drm/xe/pci: log ATS/PASID enablement state at probe Nareshkumar Gollakoti
2026-10-21 4:32 ` sashiko-bot
2026-10-21 4:11 ` [PATCH 2/6] drm/xe/vm: Setup SVA infrastructure for PASID support Nareshkumar Gollakoti
2026-10-21 4:30 ` sashiko-bot
2026-10-21 4:11 ` [PATCH 3/6] drm/xe/vm: add helper to retrieve VM SVA PASID Nareshkumar Gollakoti
2026-10-21 4:11 ` [PATCH 4/6] drm/xe/lrc: program CTX_SYS_PASID for ATS/PASID-enabled contexts Nareshkumar Gollakoti
2026-10-21 4:11 ` [PATCH 5/6] drm/xe/pci: add helper for ATS/PASID without PRI Nareshkumar Gollakoti
2026-10-21 4:11 ` [PATCH 6/6] drm/xe/pagefault: add CPU mirror VMA for SVA faults " Nareshkumar Gollakoti
2026-10-21 4:35 ` sashiko-bot
2026-10-21 4:21 ` ✗ CI.KUnit: failure for ATS/PASID SVA support and PRI-less fault servicing Patchwork
2026-10-21 15:25 ` [PATCH 0/6] " Thomas Hellström
2026-10-22 6:30 ` Kumar G, Naresh
2026-10-22 11:12 ` Thomas Hellström [this message]
2026-10-21 21:24 ` Matthew Brost
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=49204d78b2ebd1211663b0fedfec9037a09bdd59.camel@linux.intel.com \
--to=thomas.hellstrom@linux.intel.com \
--cc=himal.prasad.ghimiray@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.brost@intel.com \
--cc=naresh.kumar.g@intel.com \
/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