On Wed, Jan 28, 2026 at 12:24:25PM -0800, Matthew Brost wrote: > 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.
Why do you need address virtualization on the scale up fabric :( I can see access control but full virtualization sounds like overkill, especially considering how slow it will necessarily be compared to the fabric itself. We are already in a world where even PCI can't manage untranslated requests and a scale up fabric with 3TB/sec of bandwidth is somehow going to have address translation too? Doesn't seem reasonable. > > 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.). DMA API is already bus agnostic, I think there is no issue to plug in a ualink_device or whatever under there and make it do something sensible, and it would be *particularly* easy if the address translation can slot in as an attached iommu. Jason
