linux-kernel - Re: [virtio-dev] [PATCH 2/2] drm/virtio: add iommu support.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <bb7b8676-cf39-3144-2de1-389f4b0a70b3@amd.com>
Date:   Wed, 19 Sep 2018 22:06:58 +0000
From:   Jiandi An <jiandi@....com>
To:     Gerd Hoffmann <kraxel@...hat.com>
CC:     Dave Airlie <airlied@...il.com>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        "virtio-dev@...ts.oasis-open.org" <virtio-dev@...ts.oasis-open.org>,
        Dave Airlie <airlied@...ux.ie>,
        "open list:VIRTIO CORE, NET..." 
        <virtualization@...ts.linux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "Lendacky, Thomas" <Thomas.Lendacky@....com>,
        "Singh, Brijesh" <brijesh.singh@....com>
Subject: Re: [virtio-dev] [PATCH 2/2] drm/virtio: add iommu support.

On 09/19/2018 06:38 AM, Gerd Hoffmann wrote:
>>>> 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.
>>>
>>> Hmm.  I'd suspect there is simply a code path missing.  Can you send the
>>> patch you have?
>>>
>>> cheers,
>>>   Gerd
>>>
>>
>> I sent the patch.  For now it does dma_sync_sg on the pages in 
>> TRANSFER_TO_HOST_2D/3D when use_dma_api is true.
>>
>> https://lore.kernel.org/lkml/20180919070931.91168-1-jiandi.an@amd.com/
> 
> Hmm, the way it is hooked up it should not miss any resource update.
> So not sure why it isn't working.
> Pushed the patch nevertheless as it is clearly a step into the right
> direction.
> 
> cheers,
>   Gerd
> 

I did more tracing and digging.  The ttm-pages that needs to be dma_synced
are inside virtio_gpu_object.

There are 4 VIRTIO_GPU_CMD_RESOURCE_CREATE_2D/_ATTACH_BACKING coming down
the driver creating virtio_gpu_objects with resource_id = 1, 2, 3, 4 respectively.

resource_id = 1 is created during driver load in the path of 
virtio_gpu_probe()
   virtio_gpu_fbdev_init()
      virtio_gpufb_create()

In this path virtio_gpu_framebuffer_init() is called where it ties
virtio_gpu_object -> drm_gem_object into 
virtio_gpu_framebuffer -> drm_framebuffer -> drm_gem_object obj[0]

So later with given drm_gem_object, gem_to_virtio_gpu_obj() can get to
the virtio_gpu_object that contains it.

When kicking off display manager such as lightdm
resource_id = 2, 3, and 4 are created in the drm_mode_create_dumb ioctl path
drm_mode_create_dumb()
   drm_ioctl()
      drm_mode_create_dumb_ioctl()
         virtio_gpu_mode_dumb_create()

In this path a different virtio_gpu_object is created for each resource_id.
The virtio_gpu_object or the underlying drm_gem_object is not tied to
virtio_gpu_framebuffer.  It is published to userspace through drm_file which
registers the gem_handle for the drm_gem_object.

After display manger is kicked off, the VIRTIO_GPU_CMD_TRANSFER_TO_HOST_2D
command is acting on the virtio_gpu_object resource created for resource_id = 3.

In virtio_gpu_cmd_transfer_to_host(), it only has access to struct virtio_gpu_device,
so the virtio_gpu_object it accesses through virtio_gpu_device is resource_id = 1's
virtio_gpu_object.

void virtio_gpu_cmd_transfer_to_host_2d(struct virtio_gpu_device *vgdev,
                                        uint32_t resource_id, uint64_t offset,
...
     struct virtio_gpu_fbdev *vgfbdev = vgdev->vgfbdev;
     struct virtio_gpu_framebuffer *fb = &vgfbdev->vgfb;
     struct virtio_gpu_object *obj = gem_to_virtio_gpu_obj(fb->base.obj[0]);

In struct drm_framebuffer, there is struct drm_gem_object *obj[4], only first
element is being used here.  Can the virtio_gpu_object created from user space
for resource_id 3 be saved here to tie it to virtio_gpu_framebuffer?

Is there better way to get to the virtio_gpu_object created in the
virtio_gpu_mode_dumb_create() path from virtio_gpu_device or somehow from drm_file
via gem_handle down at the layer of virtio_gpu_cmd_transfer_to_host()?

Thanks
- Jiandi