From: Jiandi An <jiandi@amd.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Dave Airlie <airlied@gmail.com>,
dri-devel <dri-devel@lists.freedesktop.org>,
"virtio-dev@lists.oasis-open.org"
<virtio-dev@lists.oasis-open.org>, Dave Airlie <airlied@linux.ie>,
"open list:VIRTIO CORE,
NET..." <virtualization@lists.linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
"Lendacky, Thomas" <Thomas.Lendacky@amd.com>,
"Singh, Brijesh" <brijesh.singh@amd.com>
Subject: Re: [virtio-dev] [PATCH 2/2] drm/virtio: add iommu support.
Date: Wed, 19 Sep 2018 22:06:58 +0000 [thread overview]
Message-ID: <bb7b8676-cf39-3144-2de1-389f4b0a70b3@amd.com> (raw)
In-Reply-To: <20180919113807.6mwqxkdg6f55h6fg@sirius.home.kraxel.org>
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
next prev parent reply other threads:[~2018-09-19 22:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20180829122026.27012-1-kraxel@redhat.com>
2018-08-29 12:20 ` [PATCH 1/2] drm/virtio: add virtio_gpu_object_detach() function Gerd Hoffmann
2018-08-29 12:20 ` [PATCH 2/2] drm/virtio: add iommu support Gerd Hoffmann
2018-09-03 23:50 ` [virtio-dev] " Dave Airlie
2018-09-12 6:52 ` Jiandi An
2018-09-12 7:25 ` Gerd Hoffmann
2018-09-18 17:51 ` Jiandi An
2018-09-19 4:46 ` Gerd Hoffmann
2018-09-19 7:15 ` Jiandi An
2018-09-19 11:38 ` Gerd Hoffmann
2018-09-19 22:06 ` Jiandi An [this message]
2018-09-20 6:32 ` Gerd Hoffmann
2018-09-21 4:58 ` Jiandi An
2018-09-21 5:47 ` Gerd Hoffmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bb7b8676-cf39-3144-2de1-389f4b0a70b3@amd.com \
--to=jiandi@amd.com \
--cc=Thomas.Lendacky@amd.com \
--cc=airlied@gmail.com \
--cc=airlied@linux.ie \
--cc=brijesh.singh@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=kraxel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=virtio-dev@lists.oasis-open.org \
--cc=virtualization@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).