Messages in this thread | | | From | Jiandi An <> | Subject | Re: [virtio-dev] [PATCH 2/2] drm/virtio: add iommu support. | Date | Tue, 18 Sep 2018 17:51:28 +0000 |
| |
On 09/12/2018 02:25 AM, Gerd Hoffmann wrote: > 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@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 virtio gpu layer instead of the common ttm layer. Could you guys shine some >> light on this? Thanks. > > I think the tty layer is the right place to fix this. virtio just calls > down to ttm for mappings. I think virtio should just hint to ttm using > a flag in some struct, probably ttm_buffer_object or > ttm_mem_type_manager, that the objects need decrypted mappings. > > cheers, > Gerd >
I tested this patch with non SEV guest. It gives a blank black screen if booting with swiotlb=force. dma_sync is missing if dma op uses swiotlb as bounce 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. 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 black screen.
In addition, I added dma_sync_sg_for_device() before sending VIRTIO_GPU_CMD_RESOURCE_FLUSH and VIRTIO_GPU_CMD_SET_SCANOUT, still blank black screen after display manger is kicked off.
Do you know which path I'm still missing as far as VIRTIO_GPU_CMD goes?
Thanks - Jiandi
| |