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 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.