similar to: [RFC PATCH] drm/virtio: Export resource handles via DMA-buf API

On Wed, Oct 16, 2019 at 12:19:02PM +0900, Tomasz Figa wrote: > On Wed, Oct 9, 2019 at 12:04 AM Daniel Vetter <daniel at ffwll.ch> wrote: > > > > On Tue, Oct 08, 2019 at 07:49:39PM +0900, Tomasz Figa wrote: > > > On Tue, Oct 8, 2019 at 7:03 PM Daniel Vetter <daniel at ffwll.ch> wrote: > > > > > > > > On Sat, Oct 05, 2019 at 02:41:54PM

On Sat, Oct 05, 2019 at 02:41:54PM +0900, Tomasz Figa wrote: > Hi Daniel, Gerd, > > On Tue, Sep 17, 2019 at 10:23 PM Daniel Vetter <daniel at ffwll.ch> wrote: > > > > On Thu, Sep 12, 2019 at 06:41:21PM +0900, Tomasz Figa wrote: > > > This patch is an early RFC to judge the direction we are following in > > > our virtualization efforts in Chrome OS. The

On Tue, Oct 08, 2019 at 07:49:39PM +0900, Tomasz Figa wrote: > On Tue, Oct 8, 2019 at 7:03 PM Daniel Vetter <daniel at ffwll.ch> wrote: > > > > On Sat, Oct 05, 2019 at 02:41:54PM +0900, Tomasz Figa wrote: > > > Hi Daniel, Gerd, > > > > > > On Tue, Sep 17, 2019 at 10:23 PM Daniel Vetter <daniel at ffwll.ch> wrote: > > > > > >

On Thu, Sep 12, 2019 at 06:41:21PM +0900, Tomasz Figa wrote: > This patch is an early RFC to judge the direction we are following in > our virtualization efforts in Chrome OS. The purpose is to start a > discussion on how to handle buffer sharing between multiple virtio > devices. > > On a side note, we are also working on a virtio video decoder interface > and

Hi, > To seamlessly enable buffer sharing with drivers using such frameworks, > make the virtio-gpu driver expose the resource handle as the DMA address > of the buffer returned from the DMA-buf mapping operation. Arguably, the > resource handle is a kind of DMA address already, as it is the buffer > identifier that the device needs to access the backing memory, which is >

Hi, > > > To seamlessly enable buffer sharing with drivers using such frameworks, > > > make the virtio-gpu driver expose the resource handle as the DMA address > > > of the buffer returned from the DMA-buf mapping operation. Arguably, the > > > resource handle is a kind of DMA address already, as it is the buffer > > > identifier that the device

Hi, > > No. DMA master address space in virtual machines is pretty much the > > same it is on physical machines. So, on x86 without iommu, identical > > to (guest) physical address space. You can't re-define it like that. > > That's not true. Even on x86 without iommu the DMA address space can > be different from the physical address space. On a standard pc

Just run drm_prime_pages_to_sg() on the ttm pages list to get an sg_table for export. The pages list is created at object initialization time, so there should be no need to handle an unpopulated page list. Add a sanity check nevertheless. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 1 + drivers/gpu/drm/virtio/virtgpu_drv.c | 2 ++

On 4/26/19 4:21 PM, Daniel Vetter wrote: > On Fri, Apr 26, 2019 at 7:33 AM Gerd Hoffmann <kraxel at redhat.com> wrote: >> This reverts commit f4c34b1e2a37d5676180901fa6ff188bcb6371f8. >> >> Simliar to commit a0cecc23cfcb Revert "drm/virtio: drop prime >> import/export callbacks". We have to do the same with qxl, >> for the same reasons (it breaks

On 4/26/19 4:21 PM, Daniel Vetter wrote: > On Fri, Apr 26, 2019 at 7:33 AM Gerd Hoffmann <kraxel at redhat.com> wrote: >> This reverts commit f4c34b1e2a37d5676180901fa6ff188bcb6371f8. >> >> Simliar to commit a0cecc23cfcb Revert "drm/virtio: drop prime >> import/export callbacks". We have to do the same with qxl, >> for the same reasons (it breaks

This reverts commit f4c34b1e2a37d5676180901fa6ff188bcb6371f8. Simliar to commit a0cecc23cfcb Revert "drm/virtio: drop prime import/export callbacks". We have to do the same with qxl, for the same reasons (it breaks DRI3). Drop the WARN_ON_ONCE(). Fixes: f4c34b1e2a37d5676180901fa6ff188bcb6371f8 Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> ---

This reverts commit f4c34b1e2a37d5676180901fa6ff188bcb6371f8. Simliar to commit a0cecc23cfcb Revert "drm/virtio: drop prime import/export callbacks". We have to do the same with qxl, for the same reasons (it breaks DRI3). Drop the WARN_ON_ONCE(). Fixes: f4c34b1e2a37d5676180901fa6ff188bcb6371f8 Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> ---

On Sat, 12 Jan 2019 at 07:13, Dave Airlie <airlied at gmail.com> wrote: > > On Thu, 10 Jan 2019 at 18:17, Gerd Hoffmann <kraxel at redhat.com> wrote: > > > > Also set prime_handle_to_fd and prime_fd_to_handle to NULL, > > so drm will not advertive DRM_PRIME_CAP_{IMPORT,EXPORT} to > > userspace. It's been pointed out to me that disables DRI3 for these

On Sat, 12 Jan 2019 at 07:13, Dave Airlie <airlied at gmail.com> wrote: > > On Thu, 10 Jan 2019 at 18:17, Gerd Hoffmann <kraxel at redhat.com> wrote: > > > > Also set prime_handle_to_fd and prime_fd_to_handle to NULL, > > so drm will not advertive DRM_PRIME_CAP_{IMPORT,EXPORT} to > > userspace. It's been pointed out to me that disables DRI3 for these

On Fri, Apr 26, 2019 at 05:42:23PM +0200, Thomas Hellstrom wrote: > On 4/26/19 4:21 PM, Daniel Vetter wrote: > > On Fri, Apr 26, 2019 at 7:33 AM Gerd Hoffmann <kraxel at redhat.com> wrote: > > > This reverts commit f4c34b1e2a37d5676180901fa6ff188bcb6371f8. > > > > > > Simliar to commit a0cecc23cfcb Revert "drm/virtio: drop prime > > >

On Fri, Apr 26, 2019 at 7:33 AM Gerd Hoffmann <kraxel at redhat.com> wrote: > > This reverts commit f4c34b1e2a37d5676180901fa6ff188bcb6371f8. > > Simliar to commit a0cecc23cfcb Revert "drm/virtio: drop prime > import/export callbacks". We have to do the same with qxl, > for the same reasons (it breaks DRI3). > > Drop the WARN_ON_ONCE(). > > Fixes:

On Mon, Sep 7, 2020 at 1:24 PM Gerd Hoffmann <kraxel at redhat.com> wrote: > > Add drm_device argument to drm_prime_pages_to_sg(), so we can > call dma_max_mapping_size() to figure the segment size limit > and call into __sg_alloc_table_from_pages() with the correct > limit. > > This fixes virtio-gpu with sev. Possibly it'll fix other bugs > too given that drm

Add drm_device argument to drm_prime_pages_to_sg(), so we can call dma_max_mapping_size() to figure the segment size limit and call into __sg_alloc_table_from_pages() with the correct limit. This fixes virtio-gpu with sev. Possibly it'll fix other bugs too given that drm seems to totaly ignore segment size limits so far ... v2: place max_segment in drm driver not gem object. v3: move

On Wed, May 13, 2020 at 03:32:32PM +0200, Marek Szyprowski wrote: > The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function > returns the number of the created entries in the DMA address space. > However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and > dma_unmap_sg must be called with the original number of the entries > passed to the dma_map_sg().

Add max_segment argument to drm_prime_pages_to_sg(). When set pass it through to the __sg_alloc_table_from_pages() call, otherwise use SCATTERLIST_MAX_SEGMENT. Also add max_segment field to gem objects and pass it to drm_prime_pages_to_sg() calls in drivers and helpers. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- include/drm/drm_gem.h | 8 ++++++++