[RFC 1/5] mm/hmm: HMM API to enable P2P DMA for device private pages
Jason Gunthorpe
jgg at ziepe.ca
Tue Jan 28 17:21:23 UTC 2025
On Tue, Jan 28, 2025 at 05:32:23PM +0100, Thomas Hellström wrote:
> > This series supports three case:
> >
> > 1) pgmap->owner == range->dev_private_owner
> > This is "driver private fast interconnect" in this case HMM
> > should
> > immediately return the page. The calling driver understands the
> > private parts of the pgmap and computes the private interconnect
> > address.
> >
> > This requires organizing your driver so that all private
> > interconnect has the same pgmap->owner.
>
> Yes, although that makes this map static, since pgmap->owner has to be
> set at pgmap creation time. and we were during initial discussions
> looking at something dynamic here. However I think we can probably do
> with a per-driver owner for now and get back if that's not sufficient.
The pgmap->owner doesn't *have* to fixed, certainly during early boot before
you hand out any page references it can be changed. I wouldn't be
surprised if this is useful to some requirements to build up the
private interconnect topology?
> > 2) The page is DEVICE_PRIVATE and get_dma_pfn_for_device() exists.
> > The exporting driver has the option to return a P2P struct page
> > that can be used for PCI P2P without any migration. In a PCI GPU
> > context this means the GPU has mapped its local memory to a PCI
> > address. The assumption is that P2P always works and so this
> > address can be DMA'd from.
>
> So do I understand it correctly, that the driver then needs to set up
> one device_private struct page and one pcie_p2p struct page for each
> page of device memory participating in this way?
Yes, for now. I hope to remove the p2p page eventually.
> > If you are just talking about your private multi-path, then that is
> > already handled..
>
> No, the issue I'm having with this is really why would
> hmm_range_fault() need the new pfn when it could easily be obtained
> from the device-private pfn by the hmm_range_fault() caller?
That isn't the API of HMM, the caller uses hmm to get PFNs it can use.
Deliberately returning PFNs the caller cannot use is nonsensical to
it's purpose :)
> So anyway what we'll do is to try to use an interconnect-common owner
> for now and revisit the problem if that's not sufficient so we can come
> up with an acceptable solution.
That is the intention for sure. The idea was that the drivers under
the private pages would somehow generate unique owners for shared
private interconnect segments.
I wouldn't say this is the end all of the idea, if there are better
ways to handle accepting private pages they can certainly be
explored..
Jason
More information about the dri-devel
mailing list