On Wed, Sep 7, 2022 at 5:30 PM Christoph Hellwig hch@infradead.org wrote:
On Wed, Sep 07, 2022 at 09:33:11AM -0300, Jason Gunthorpe wrote:
Yes, you said that, and I said that when the AMD driver first merged it - but it went in anyhow and now people are using it in a bunch of places.
drm folks made up their own weird rules, if they internally stick to it they have to listen to it given that they ignore review comments, but it violates the scatterlist API and has not business anywhere else in the kernel. And yes, there probably is a reason or two why the drm code is unusually error prone.
Why would small BARs be problematic for the pages? The pages are more a problem for gigantic BARs do the memory overhead.
How do I get a struct page * for a 4k BAR in vfio?
I guess we have different definitions of small then :)
But unless my understanding of the code is out out of data, memremap_pages just requires the (virtual) start address to be 2MB aligned, not the size. Adding Dan for comments.
That being said, what is the point of mapping say a 4k BAR for p2p? You're not going to save a measurable amount of CPU overhead if that is the only place you transfer to.
I don't know what Jason had in mind, but I can see a use for that for writing to doorbells of a device. Today, usually what happens is that peer A reads/writes to peer B's memory through the large bar and then signals the host the operation was completed. Then the host s/w writes to the doorbell of the peer B to let him know he can continue with the execution as the data is now ready (or can be recycled). I can imagine peer A writing directly to the doorbell of peer B, and usually for that we would like to expose a very small area, probably a single 4K page.
Oded