Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
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(+)

  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