On Wed, Sep 7, 2022 at 5:30 PM Christoph Hellwig <hch@xxxxxxxxxxxxx> 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
