lkml.org 
[lkml]   [2018]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v3 1/2] drm/virtio: Add window server support
From
Date
Hi Gerd and Stefan,

can we reach agreement on whether vsock should be involved in this?

Thanks,

Tomeu

On 02/07/2018 10:49 AM, Tomeu Vizoso wrote:
> On 02/06/2018 03:23 PM, Gerd Hoffmann wrote:
>>    Hi,
>>
>>>> Hmm?  I'm assuming the wayland client (in the guest) talks to the
>>>> wayland proxy, using the wayland protocol, like it would talk to a
>>>> wayland display server.  Buffers must be passed from client to
>>>> server/proxy somehow, probably using fd passing, so where is the
>>>> problem?
>>>>
>>>> Or did I misunderstand the role of the proxy?
>>>
>>> Hi Gerd,
>>>
>>> it's starting to look to me that we're talking a bit past the other, so I
>>> have pasted below a few words describing my current plan regarding the
>>> 3 key
>>> scenarios that I'm addressing.
>>
>> You are describing the details, but I'm missing the big picture ...
>>
>> So, virtualization aside, how do buffers work in wayland?  As far I know
>> it goes like this:
>>
>>    (a) software rendering: client allocates shared memory buffer, renders
>>        into it, then passes a file handle for that shmem block together
>>        with some meta data (size, format, ...) to the wayland server.
>>
>>    (b) gpu rendering: client opens a render node, allocates a buffer,
>>        asks the cpu to renders into it, exports the buffer as dma-buf
>>        (DRM_IOCTL_PRIME_HANDLE_TO_FD), passes this to the wayland server
>>        (again including meta data of course).
>>
>> Is that correct?
>
> Both are correct descriptions of typical behaviors. But it isn't spec'ed
> anywhere who has to do the buffer allocation.
>
> In practical terms, the buffer allocation happens in either the 2D GUI
> toolkit (gtk+, for example), or the EGL implementation. Someone using
> this in a real product would most probably be interested in avoiding any
> extra copies and make sure that both allocate buffers via virtio-gpu, for
> example.
>
> Depending on the use case, they could be also interested in supporting
> unmodified clients with an extra copy per buffer presentation.
>
> That's to say that if we cannot come up with a zero-copy solution for
> unmodified clients, we should at least support zero-copy for cooperative
> clients.
>
>> Now, with virtualization added to the mix it becomes a bit more
>> complicated.  Client and server are unmodified.  The client talks to the
>> guest proxy (wayland protocol).  The guest proxy talks to the host proxy
>> (protocol to be defined). The host proxy talks to the server (wayland
>> protocol).
>>
>> Buffers must be managed along the way, and we want avoid copying around
>> the buffers.  The host proxy could be implemented directly in qemu, or
>> as separate process which cooperates with qemu for buffer management.
>>
>> Fine so far?
>
> Yep.
>
>>> I really think that whatever we come up with needs to support 3D
>>> clients as
>>> well.
>>
>> Lets start with 3d clients, I think these are easier.  They simply use
>> virtio-gpu for 3d rendering as usual.  When they are done the rendered
>> buffer already lives in a host drm buffer (because virgl runs the actual
>> rendering on the host gpu).  So the client passes the dma-buf to the
>> guest proxy, the guest proxy imports it to look up the resource-id,
>> passes the resource-id to the host proxy, the host proxy looks up the
>> drm buffer and exports it as dma-buf, then passes it to the server.
>> Done, without any extra data copies.
>
> Yep.
>
>>> Creation of shareable buffer by guest
>>> -------------------------------------------------
>>>
>>> 1. Client requests virtio driver to create a buffer suitable for sharing
>>> with host (DRM_VIRTGPU_RESOURCE_CREATE)
>>
>> client or guest proxy?
>
> As per the above, the GUI toolkit could have been modified so the client
> directly creates a shareable buffer, and renders directly to it without
> any extra copies.
>
> If clients cannot be modified, then it's the guest proxy what has to
> create the shareable buffer and keep it in sync with the client's
> non-shareable buffer at the right times, by intercepting
> wl_surface.commit messages and copying buffer contents.
>
>>> 4. QEMU maps that buffer to the guest's address space
>>> (KVM_SET_USER_MEMORY_REGION), passes the guest PFN to the virtio driver
>>
>> That part is problematic.  The host can't simply allocate something in
>> the physical address space, because most physical address space
>> management is done by the guest.  All pci bars are mapped by the guest
>> firmware for example (or by the guest OS in case of hotplug).
>
> How can KVM_SET_USER_MEMORY_REGION ever be safely used then? I would have
> expected that callers of that ioctl have enough knowledge to be able to
> choose a physical address that won't conflict with the guest's kernel.
>
> I see that the ivshmem device in QEMU registers the memory region in BAR
> 2 of a PCI device instead. Would that be better in your opinion?
>
>>> 4. QEMU pops data+buffers from the virtqueue, looks up shmem FD for each
>>> resource, sends data + FDs to the compositor with SCM_RIGHTS
>>
>> BTW: Is there a 1:1 relationship between buffers and shmem blocks?  Or
>> does the wayland protocol allow for offsets in buffer meta data, so you
>> can place multiple buffers in a single shmem block?
>
> The latter:
> https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_shm_pool
>
> Regards,
>
> Tomeu

\
 
 \ /
  Last update: 2018-02-09 12:15    [W:0.090 / U:0.028 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site