dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Leon Romanovsky <leon@kernel.org>,
	kvm@vger.kernel.org, linux-rdma@vger.kernel.org,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Oded Gabbay <ogabbay@kernel.org>,
	Cornelia Huck <cohuck@redhat.com>,
	dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
	Alex Williamson <alex.williamson@redhat.com>,
	Jason Gunthorpe <jgg@nvidia.com>,
	Maor Gottlieb <maorg@nvidia.com>,
	Sumit Semwal <sumit.semwal@linaro.org>,
	linux-media@vger.kernel.org
Subject: Re: [PATCH v2 4/4] vfio/pci: Allow MMIO regions to be exported through dma-buf
Date: Wed, 7 Sep 2022 17:08:37 +0200	[thread overview]
Message-ID: <58d6e892-82df-7aa7-4798-9e5da7c634ad@amd.com> (raw)
In-Reply-To: <YxiIkh/yeWQkZ54x@infradead.org>

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.

      parent reply	other threads:[~2022-09-07 15:09 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-31 23:12 [PATCH v2 0/4] Allow MMIO regions to be exported through dma-buf Jason Gunthorpe
2022-08-31 23:12 ` [PATCH v2 1/4] dma-buf: Add dma_buf_try_get() Jason Gunthorpe
2022-09-01  7:55   ` Christian König
2022-09-06 16:44     ` Jason Gunthorpe
2022-09-06 17:52       ` Christian König
2022-08-31 23:12 ` [PATCH v2 2/4] vfio: Add vfio_device_get() Jason Gunthorpe
2022-08-31 23:12 ` [PATCH v2 3/4] vfio_pci: Do not open code pci_try_reset_function() Jason Gunthorpe
2022-08-31 23:12 ` [PATCH v2 4/4] vfio/pci: Allow MMIO regions to be exported through dma-buf Jason Gunthorpe
     [not found]   ` <YxcYGzPv022G2vLm@infradead.org>
2022-09-06 10:38     ` Christian König
2022-09-06 11:48       ` Jason Gunthorpe
2022-09-06 12:34         ` Oded Gabbay
2022-09-06 17:59           ` Jason Gunthorpe
2022-09-06 19:44             ` Oded Gabbay
     [not found]         ` <YxiJJYtWgh1l0wxg@infradead.org>
2022-09-07 12:33           ` Jason Gunthorpe
     [not found]             ` <Yxiq5sjf/qA7xS8A@infradead.org>
2022-09-07 14:46               ` Oded Gabbay
2022-09-07 15:23               ` Jason Gunthorpe
     [not found]                 ` <Yxi5h09JAzIo4Kh8@infradead.org>
2022-09-07 16:12                   ` Jason Gunthorpe
     [not found]                     ` <Yxs+k6psNfBLDqdv@infradead.org>
2022-09-09 14:09                       ` Jason Gunthorpe
2022-09-07 16:31                 ` Robin Murphy
2022-09-07 16:47                   ` Jason Gunthorpe
2022-09-07 17:03               ` Dan Williams
2022-09-07 15:01             ` Robin Murphy
     [not found]       ` <YxiIkh/yeWQkZ54x@infradead.org>
2022-09-07 15:08         ` Christian König [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=58d6e892-82df-7aa7-4798-9e5da7c634ad@amd.com \
    --to=christian.koenig@amd.com \
    --cc=alex.williamson@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hch@infradead.org \
    --cc=jgg@nvidia.com \
    --cc=kvm@vger.kernel.org \
    --cc=leon@kernel.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=maorg@nvidia.com \
    --cc=ogabbay@kernel.org \
    --cc=sumit.semwal@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).