[lkml]   [2018]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [virtio-dev] [PATCH 2/2] drm/virtio: add iommu support.

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
>> 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?

- Jiandi
 \ /
  Last update: 2018-09-18 19:52    [W:0.086 / U:17.296 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site