On Wed, Sep 07, 2022 at 05:08:37PM +0200, Christian König wrote: > The key point is that you can't do any CPU fallback with this as long as the > CPU wouldn't do exactly the same thing as the original hardware device. E.g. > not write combine nor do any fully page copies etc... That is true for MMIO in general. You need to use the mmio accessors, and even then it needs to match what the hardware expects > This is not even a memory write, but rather just some trigger event. That's > essentially the background why I think having struct pages and sg_tables > doesn't make any sense at all for this use case. Well, Jasons patch uses a sg_table, just in a very broken way. > > > Would you mind if I start to tackle this problem? > > Yes, I've been waiting forever for someone to tacke how the scatterlist > > is abused in dma-buf.. > > How about we separate the scatterlist into page and DMA address container? As said before that is fundamentally the right thing to do. It just takes a lot of work. I think on the dma mapping side we're finally getting ready for it now that arm uses the common dma-direct code, although getting rid of the arm iommu ops first would be even better. Note that this only solves the problem of needing the pages to hold the physical address. The other thing the pages are used for in p2p is that (through the pgmap) it points to the owning device of the p2p memory and thus allows figuring out how it needs to be accessed.
