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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
