Am 07.09.22 um 14:03 schrieb Christoph Hellwig:
On Tue, Sep 06, 2022 at 12:38:44PM +0200, Christian König wrote:
The problem is once more that this is MMIO space, in other words register BARs which needs to be exported/imported.
Everything used for P2P is bar space.
Adding struct pages for it generally sounds like the wrong approach here. You can't even access this with the CPU or would trigger potentially unwanted hardware actions.
How would an access from the CPU vs anther device make any difference?
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...
See what happens here is not really P2P DMA transfer, but rather P2P signaling of events.
For a simple example think of a camera and a video codec. The camera is pumping video data into system memory the video codec should encode into an H264 stream.
So after every frame the camera hardware issues a P2P write into the BAR of the video codec to signal that the frame is completed and it can start decoding.
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.
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?
Regards, Christian.