On Wed, Jan 22, 2025 at 12:04:19PM +0100, Simona Vetter wrote:

I'm kinda leaning towards entirely separate dma-buf interfaces for the new phyr stuff, because I fear that adding that to the existing ones will only make the chaos worse.

Lets see when some patches come up, if importers have to deal with several formats a single attach interface would probably be simpler for them..

For the existing dma-buf importers/exporters I'm kinda hoping for a pure dma_addr_t based list eventually.

IMHO the least churn would be to have the old importers call a helper (perhaps implicitly in the core code) to convert phyr into a dma mapped scatterlist and then just keep using their existing code exactly as is.

Performance improvement would come from importers switching to use the new dma api internally and avoiding the scatterlist allocation, but even the extra alocation is not so bad.

Then, perhaps, and I really hesitate to say this, but perhaps to ease the migration we could store a dma mapped list in a phyr using the meta information. That would allow a dmabuf scatterlist exporter to be converted to a phyr with a helper. The importer would have to have a special path to detect the dma mapped mode and skip the normal mapping.

The point would be to let maintained drivers use the new data structures and flows easily and still interoperate with older drivers. Otherwise we have to somehow build parallel scatterlist and phyr code flows into importers :\

Going all the way to a phyr based approach for everyone might be too much churn, there's some real bad cruft there. It's not going to work for every case, but it covers a lot of them and might be less pain for existing importers.

I'd hope we can reach every case.. But I don't know what kind of horrors you guys have :)

But in theory it should be possible to use phyr everywhere eventually, as long as there's no obviously api-rules-breaking way to go from a phyr back to a struct page even when that exists.

I'd say getting a struct page is a perfectly safe operation, from a phyr API perspective.

The dmabuf issue seems to be entirely about following the locking rules, an importer is not allowed to get a struct page and switch from reservation locking to page refcount locking.

I get the appeal for DRM of blocking struct page use because that directly prevents the above. But, in RDMA I want to re-use the same phyr datastructure for tracking pin_user_pages() CPU memory, and I must get the struct page back so I can put_user_page() it when done.

Perhaps we can find some compromise where the phyr data structure has some kind of flag 'disable struct page' and then the phyr_entry_to_page() API will WARN_ON() or something like that.

...

However, soon we will have encrypted P2P MMIO which will stress this hiding strategy.

It's already breaking with stuff like virtual gpu drivers, vmwgfx is fiddling around with these bits (at least last I tried to understand this all) and I think a few others do too.

IMHO, most places I've seen touching this out side arch code feel very hacky. :\

Jason