similar to: [virtio-dev] [PATCH 2/2] drm/virtio: add iommu support.

On Wed, Sep 19, 2018 at 07:09:53AM +0000, An, Jiandi wrote: > With virtio gpu ttm-pages being dma mapped, dma sync is needed when > swiotlb is used as bounce buffers, before TRANSFER_TO_HOST_2D/3D > commands are sent. Pushed to drm-misc-next. thanks, Gerd

Hi, > buffer. I tried to put a dma_sync_sg_for_device() on virtio_gpu_object obj->pages-sgl > before VIRTIO_GPU_CMD_TRANSFER_TO_HOST_2D is sent. This fixes the kernel console path. That should be the right place. > Once display manger is kicked off for example (sudo systemctl start lightdm.service) and > resource id 3 gets created from user space down, it still gives a blank

For the series, Reviewed-by: Dave Airlie <airlied at redhat.com> On Wed, 29 Aug 2018 at 22:20, Gerd Hoffmann <kraxel at redhat.com> wrote: > > Use the dma mapping api and properly add iommu mappings for > objects, unless virtio is in iommu quirk mode. > > Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> > --- > drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +

On Tue, Sep 08, 2020 at 08:47:41AM +0200, Gerd Hoffmann wrote: > These days dma ops can be overridden per device, and the virtio core "can be overridden" or "are"? The comment above vring_use_dma_api() suggests that's not yet done. If that's wrong then I think updating the comment would be really good. -Daniel > uses that to handle the dma quirks transparently

On Wed, Feb 5, 2020 at 3:00 AM Gerd Hoffmann <kraxel at redhat.com> wrote: > > Introduce new virtio_gpu_object_shmem_init() helper function which will > create the virtio_gpu_mem_entry array, containing the backing storage > information for the host. For the most path this just moves code from > virtio_gpu_object_attach(). > > Signed-off-by: Gerd Hoffmann <kraxel at

These days dma ops can be overridden per device, and the virtio core uses that to handle the dma quirks transparently for the rest of the kernel. So we can drop the virtio_has_dma_quirk() checks, just use the dma api unconditionally and depend on the virtio core having setup dma_ops as needed. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_object.c

These days dma ops can be overridden per device, and the virtio core uses that to handle the dma quirks transparently for the rest of the kernel. So we can drop the virtio_has_dma_quirk() checks, just use the dma api unconditionally and depend on the virtio core having setup dma_ops as needed. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_object.c

Introduce new virtio_gpu_object_shmem_init() helper function which will create the virtio_gpu_mem_entry array, containing the backing storage information for the host. For the most path this just moves code from virtio_gpu_object_attach(). Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 4 ++ drivers/gpu/drm/virtio/virtgpu_object.c | 49

Introduce new virtio_gpu_object_shmem_init() helper function which will create the virtio_gpu_mem_entry array, containing the backing storage information for the host. For the most path this just moves code from virtio_gpu_object_attach(). Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 4 ++ drivers/gpu/drm/virtio/virtgpu_object.c | 49

Introduce new virtio_gpu_object_shmem_init() helper function which will create the virtio_gpu_mem_entry array, containing the backing storage information for the host. For the most path this just moves code from virtio_gpu_object_attach(). Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 4 +- drivers/gpu/drm/virtio/virtgpu_object.c | 55

Pass virtio_gpu_object down to virtio_gpu_cmd_transfer_to_host_2d and virtio_gpu_cmd_transfer_to_host_3d functions, instead of passing just the virtio resource handle. This is needed to lookup the scatter list of the object, for dma sync. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 6 ++++-- drivers/gpu/drm/virtio/virtgpu_fb.c | 2

Hi, > I attempted to fix it in the ttm layer and here is the discussion > https://lore.kernel.org/lkml/b44280d7-eb13-0996-71f5-3fbdeb466801 at amd.com/ > > The ttm maintainer Christian is suggesting to map and set ttm->pages as decrypted > right after ttm->pages are allocated. > > Just checking with you guys maybe there is a better way to handle this in > the

On Fri, Aug 21, 2020 at 03:15:34PM +0200, Jean-Philippe Brucker wrote: > Add a topology description to the virtio-iommu driver and enable x86 > platforms. > > Since [v2] we have made some progress on adding ACPI support for > virtio-iommu, which is the preferred boot method on x86. It will be a > new vendor-agnostic table describing para-virtual topologies in a > minimal

Hi, On 8/21/20 3:15 PM, Jean-Philippe Brucker wrote: > Add a topology description to the virtio-iommu driver and enable x86 > platforms. > > Since [v2] we have made some progress on adding ACPI support for > virtio-iommu, which is the preferred boot method on x86. It will be a > new vendor-agnostic table describing para-virtual topologies in a > minimal format. However some

Now that the corresponding feature bit has been renamed, rename the quirk too - it's about special ways to do DMA, not necessarily about the IOMMU. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_object.c | 2 +- drivers/gpu/drm/virtio/virtgpu_vq.c | 4 ++-- drivers/virtio/virtio_ring.c | 2 +- include/linux/virtio_config.h

On Sun, Feb 16, 2020 at 04:50:33AM -0500, Michael S. Tsirkin wrote: > On Fri, Feb 14, 2020 at 04:57:11PM +0000, Robin Murphy wrote: > > On 14/02/2020 4:04 pm, Jean-Philippe Brucker wrote: > > > With the built-in topology description in place, x86 platforms can now > > > use the virtio-iommu. > > > > > > Signed-off-by: Jean-Philippe Brucker

Stop sending DETACH_BACKING commands, that will happening anyway when releasing resources via UNREF. Handle guest-side cleanup in virtio_gpu_cleanup_object(), called when the host finished processing the UNREF command. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 2 -- drivers/gpu/drm/virtio/virtgpu_object.c | 14 ++++++--

On Sun, Feb 16, 2020 at 04:50:33AM -0500, Michael S. Tsirkin wrote: > On Fri, Feb 14, 2020 at 04:57:11PM +0000, Robin Murphy wrote: > > On 14/02/2020 4:04 pm, Jean-Philippe Brucker wrote: > > > With the built-in topology description in place, x86 platforms can now > > > use the virtio-iommu. > > > > > > Signed-off-by: Jean-Philippe Brucker

Stop sending DETACH_BACKING commands, that will happening anyway when releasing resources via UNREF. Handle guest-side cleanup in virtio_gpu_cleanup_object(), called when the host finished processing the UNREF command. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 2 -- drivers/gpu/drm/virtio/virtgpu_object.c | 14 ++++++--

On Mon, Feb 17, 2020 at 10:01:07AM +0100, Jean-Philippe Brucker wrote: > On Sun, Feb 16, 2020 at 04:50:33AM -0500, Michael S. Tsirkin wrote: > > On Fri, Feb 14, 2020 at 04:57:11PM +0000, Robin Murphy wrote: > > > On 14/02/2020 4:04 pm, Jean-Philippe Brucker wrote: > > > > With the built-in topology description in place, x86 platforms can now > > > > use