Re: [RFC PATCH v3 06/11] drm/pagemap: Add IOVA interface to DRM pagemap

[Matthew Brost <matthew.brost@intel.com>]

On Wed, Jan 28, 2026 at 03:35:09PM -0400, Jason Gunthorpe wrote:
> On Wed, Jan 28, 2026 at 10:42:53AM -0800, Matthew Brost wrote:
> > Yes, this is exactly what I envision here. First, let me explain the
> > possible addressing modes on the UAL fabric:
> > 
> >  - Physical (akin to IOMMU passthrough)
> >  - Virtual (akin to IOMMU enabled)
> > 
> > Physical mode is straightforward — resolve the PFN to a cross-device
> > physical address, then install it into the initiator’s page tables along
> > with a bit indicating routing over the network. In this mode, the vfuncs
> > here are basically NOPs.
> 
> Ugh of course they would invent something so complicated.
> 

Why wouldn't we... But conceptually really fairly close to IOMMU
paththrough vs. enabled.

> I'm not convinced this should be hidden inside DRM. The DMA API is the


Well, what I’m suggesting isn’t in DRM. A UAL API would be its own
layer, much like the DMA API. Of course we could stick this in the DMA
API and make it high-speed-fabric-generic, etc., but I do think the
fabric functions would have their own signatures and semantics (see my
explanation around device_ual_alloc reclaim rules, what locks it is
allowed to take, etc.).

> place to make things mappable and for an open standard like UALink it
> would make sense that the DMA API is the broker to connect things as
> it will be more than just one GPU driver talking to itself.
> 

I agree that a UAL API would just be a broker, similar to the DMA API.
It should support multiple devices and drivers communicating with each
other. If the UAL API only works with, let’s say, two Xe devices, then
we’d be broken.

> There is a journey to get there, but I don't think it is too
> complicated. It also probably ties in fairly nicely with the ideas

I agree it will be a journey and really shouldn't be too complicated.
Open to other ideas here.

> coming for multi path PCIe fabrics.
> 
> > So, if it isn’t clear — these vfuncs hide whether PCIe P2P is being used
> > (IOMMU in passthrough or enabled) or UAL is being used (physical or
> > virtual) for DRM common layer. They manage the resources for the
> > connection and provide the information needed to program the initiator
> > PTEs (address + “use interconnect” vs. “use PCIe P2P bit”).
> 
> This looks like it is taking the DMA API and sticking drm_ in front of
> it :( I don't think this is a good direction for the kernel, DRM
> should not be internally building such key infrastructure.
>

Again, it’s not my intent to stick DRM into this. The DRM parts are
specific to how we do SVM (locking, migrations, page collections for
bindings, etc.) so each driver doesn’t reinvent this piece (see AMD’s
and Nouveau’s implementations), but the UAL mapping logic should be
generic, also being able to used in dma-buf, etc. Also, all of the DRM
SVM parts can be pulled into the device layer if needed as there really
isn't anything DRM specific in it and parts the existing DRM SVM code
could be pushed down into HMM type helpers too. The DRM SVM code only
has a single user for now (Xe) and this will evolve as others just in. 

I can park the latter half of this series for now, as it isn’t really
required aside from multi-GPU performance work, and with larger device
pages this really shouldn’t matter anyway.

My feeling is we probably need to circle back to some high-speed-fabric
API consensus within the next 6-9 months though.

This was just a PoC I started thinking about when converting to IOVA
link for dma-map and UAL ideas popped into my head.

> I'm confident we will see NICs and storage wired up to these fabrics
> as well.
> 

Yes, I agree eventually this will happen.

Matt

> Jason