From: Tomeu Vizoso <tomeu.vizoso@collabora.com> To: Gerd Hoffmann <kraxel@redhat.com> Cc: linux-kernel@vger.kernel.org, Zach Reizner <zachr@google.com>, kernel@collabora.com, dri-devel@lists.freedesktop.org, virtualization@lists.linux-foundation.org, "Michael S. Tsirkin" <mst@redhat.com>, David Airlie <airlied@linux.ie>, Jason Wang <jasowang@redhat.com> Subject: Re: [PATCH v3 1/2] drm/virtio: Add window server support Date: Mon, 5 Feb 2018 09:19:20 +0100 [thread overview] Message-ID: <49785e0d-936a-c3b4-62dd-aafc7083a942@collabora.com> (raw) In-Reply-To: <20180201163623.5cs2ysykg5wgulf4@sirius.home.kraxel.org> 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
WARNING: multiple messages have this Message-ID (diff)
From: Tomeu Vizoso <tomeu.vizoso@collabora.com> To: Gerd Hoffmann <kraxel@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com>, David Airlie <airlied@linux.ie>, Jason Wang <jasowang@redhat.com>, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, virtualization@lists.linux-foundation.org, kernel@collabora.com Subject: Re: [PATCH v3 1/2] drm/virtio: Add window server support Date: Mon, 5 Feb 2018 09:19:20 +0100 [thread overview] Message-ID: <49785e0d-936a-c3b4-62dd-aafc7083a942@collabora.com> (raw) In-Reply-To: <20180201163623.5cs2ysykg5wgulf4@sirius.home.kraxel.org> 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2018-02-05 8:19 UTC|newest] Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-01-26 13:58 [PATCH v3 0/2] drm/virtio: Add window server support Tomeu Vizoso 2018-01-26 13:58 ` Tomeu Vizoso 2018-01-26 13:58 ` [PATCH v3 1/2] " Tomeu Vizoso 2018-01-26 13:58 ` Tomeu Vizoso 2018-02-01 16:36 ` Gerd Hoffmann 2018-02-01 16:36 ` Gerd Hoffmann 2018-02-05 8:19 ` Tomeu Vizoso 2018-02-05 8:19 ` Tomeu Vizoso [this message] 2018-02-05 8:19 ` Tomeu Vizoso 2018-02-05 12:20 ` Gerd Hoffmann 2018-02-05 14:46 ` Tomeu Vizoso 2018-02-05 14:46 ` Tomeu Vizoso 2018-02-05 16:03 ` Gerd Hoffmann 2018-02-05 16:03 ` Gerd Hoffmann 2018-02-06 12:41 ` Tomeu Vizoso 2018-02-06 12:41 ` Tomeu Vizoso 2018-02-06 14:23 ` Gerd Hoffmann 2018-02-06 14:23 ` Gerd Hoffmann 2018-02-07 1:09 ` Michael S. Tsirkin 2018-02-07 7:41 ` Tomeu Vizoso 2018-02-07 7:41 ` Tomeu Vizoso 2018-02-07 1:09 ` Michael S. Tsirkin 2018-02-07 9:49 ` Tomeu Vizoso 2018-02-07 9:49 ` Tomeu Vizoso 2018-02-09 11:14 ` Tomeu Vizoso 2018-02-09 11:14 ` Tomeu Vizoso 2018-02-12 11:52 ` Gerd Hoffmann 2018-02-12 11:52 ` Gerd Hoffmann 2018-02-12 14:00 ` Tomeu Vizoso 2018-02-12 14:00 ` Tomeu Vizoso 2018-02-12 14:00 ` Tomeu Vizoso 2018-02-12 14:27 ` Gerd Hoffmann 2018-02-12 14:27 ` Gerd Hoffmann 2018-02-12 14:42 ` Tomeu Vizoso 2018-02-12 14:42 ` Tomeu Vizoso 2018-02-12 15:29 ` Gerd Hoffmann 2018-02-12 15:29 ` Gerd Hoffmann 2018-02-12 15:29 ` Gerd Hoffmann 2018-02-12 14:42 ` Tomeu Vizoso 2018-02-12 11:45 ` Gerd Hoffmann 2018-02-12 11:45 ` Gerd Hoffmann 2018-02-12 11:45 ` Gerd Hoffmann 2018-02-13 7:41 ` Pekka Paalanen 2018-02-13 7:41 ` Pekka Paalanen 2018-02-13 7:41 ` Pekka Paalanen 2018-02-13 14:27 ` Tomeu Vizoso 2018-02-13 14:27 ` Tomeu Vizoso 2018-02-16 10:48 ` Gerd Hoffmann 2018-02-16 10:48 ` Gerd Hoffmann 2018-02-16 10:48 ` Gerd Hoffmann 2018-02-13 14:27 ` Tomeu Vizoso 2018-02-15 15:28 ` Tomeu Vizoso 2018-02-15 15:28 ` Tomeu Vizoso 2018-02-15 15:28 ` Tomeu Vizoso 2018-02-06 14:23 ` Gerd Hoffmann 2018-02-06 12:41 ` Tomeu Vizoso 2018-02-06 15:00 ` Pekka Paalanen 2018-02-06 15:00 ` Pekka Paalanen 2018-02-06 15:00 ` Pekka Paalanen 2018-02-05 16:03 ` Gerd Hoffmann 2018-02-05 14:46 ` Tomeu Vizoso 2018-02-05 12:20 ` Gerd Hoffmann 2019-03-18 12:47 ` Tomeu Vizoso 2019-03-18 12:47 ` Tomeu Vizoso 2019-03-18 12:47 ` Tomeu Vizoso 2018-01-26 13:58 ` [PATCH v3 2/2] drm/virtio: Handle buffers from the compositor Tomeu Vizoso 2018-01-26 13:58 ` Tomeu Vizoso
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=49785e0d-936a-c3b4-62dd-aafc7083a942@collabora.com \ --to=tomeu.vizoso@collabora.com \ --cc=airlied@linux.ie \ --cc=dri-devel@lists.freedesktop.org \ --cc=jasowang@redhat.com \ --cc=kernel@collabora.com \ --cc=kraxel@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=mst@redhat.com \ --cc=virtualization@lists.linux-foundation.org \ --cc=zachr@google.com \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.