Messages in this thread | | | Subject | Re: [PATCH v3 1/2] drm/virtio: Add window server support | From | Tomeu Vizoso <> | Date | Mon, 18 Mar 2019 13:47:31 +0100 |
| |
[Tomasz wants to comment, adding him to CC]
On 2/5/18 9:19 AM, Tomeu Vizoso wrote: > On 1 February 2018 at 17:36, Gerd Hoffmann <kraxel@redhat.com> wrote: >> Hi, >> >> Sorry for joining the party late. Had a broken finger and was >> offline for a bunch of weeks (and a buif backlog afterwards ...). > > Hi, no problem, hope it's fine now. > >>> This is to allow clients running within VMs to be able to >>> communicate with a compositor in the host. Clients will use the >>> communication protocol that the compositor supports, and virtio-gpu >>> will assist with making buffers available in both sides, and >>> copying content as needed. >> >> Why not use virtio-vsock to run the wayland protocol? I don't like >> the idea to duplicate something with very simliar functionality in >> virtio-gpu. > > The reason for abandoning that approach was the type of objects that > could be shared via virtio-vsock would be extremely limited. Besides > that being potentially confusing to users, it would mean from the > implementation side that either virtio-vsock would gain a dependency on > the drm subsystem, or an appropriate abstraction for shareable buffers > would need to be added for little gain. > > Another factor that was taken into account was that the complexity > required for implementing passing protocol data around was very small > when compared with the buffer sharing mechanism. > >>> It is expected that a service in the guest will act as a proxy, >>> interacting with virtio-gpu to support unmodified clients. >> >> If you have a guest proxy anyway using virtio-sock for the protocol >> stream and virtio-gpu for buffer sharing (and some day 3d rendering >> too) should work fine I think. > > If I understand correctly your proposal, virtio-gpu would be used for > creating buffers that could be shared across domains, but something > equivalent to SCM_RIGHTS would still be needed in virtio-vsock? > > If so, that's what was planned initially, with the concern being that we > would be adding a bunch of complexity to virtio-vsock that would be only > used in this specific use case. Then we would also need to figure out > how virtio-vsock would be able to work with buffers from virtio-gpu > (either direct dependency or a new abstraction). > > If the mechanics of passing presentation data were very complex, I think > this approach would have more merit. But as you can see from the code, > it isn't that bad. > >>> When the client notifies the compositor that it can read from that > buffer, >>> the proxy should copy the contents from the SHM region to the >>> virtio-gpu resource and call DRM_VIRTGPU_TRANSFER_TO_HOST. >> >> What is the plan for the host side? I see basically two options. Either >> implement the host wayland proxy directly in qemu. Or >> implement it as separate process, which then needs some help from >> qemu to get access to the buffers. The later would allow qemu running >> independant from the desktop session. > > Regarding synchronizing buffers, this will stop becoming needed in > subsequent commits as all shared memory is allocated in the host and > mapped to the guest via KVM_SET_USER_MEMORY_REGION. > > This is already the case for buffers passed from the compositor to the > clients (see patch 2/2), and I'm working on the equivalent for buffers > from the guest to the host (clients still have to create buffers with > DRM_VIRTGPU_RESOURCE_CREATE but they will be only backend by host memory > so no calls to DRM_VIRTGPU_TRANSFER_TO_HOST are needed). > > But in the case that we still need a proxy for some reason on the host > side, I think it would be better to have it in the same process where > virtio-gpu is implemented. In crosvm's case it would be in a process > separate from the main VMM, as device processes are isolated from each > other with minijail (see > https://chromium.googlesource.com/chromiumos/platform/crosvm/ ). > > Regards, > > Tomeu >
| |