On Thu, Nov 7, 2019 at 11:35 PM Stefan Hajnoczi <stefanha@xxxxxxxxx> wrote: > > On Fri, Nov 8, 2019 at 8:22 AM Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote: > > > > Adding a list of common properties to the spec certainly makes sense, > > > > so everybody uses the same names. Adding struct-ed properties for > > > > common use cases might be useful too. > > > > > > Why not define VIRTIO devices for wayland and friends? > > > > There is an out-of-tree implementation of that, so yes, that surely is > > an option. > > > > Wayland needs (a) shared buffers, mostly for gfx data, and (b) a stream > > pipe as control channel. Pretty much the same for X11, except that > > shared buffers are optional because the X protocol can also squeeze all > > display updates through the stream pipe. > > > > So, if you want allow guests talk to the host display server you can run > > the stream pipe over vsock. But there is nothing for the shared > > buffers ... > > > > We could replicate vsock functionality elsewhere. I think that happened > > in the out-of-tree virtio-wayland implementation. There also was some > > discussion about adding streams to virtio-gpu, slightly pimped up so you > > can easily pass around virtio-gpu resource references for buffer > > sharing. But given that getting vsock right isn't exactly trivial > > (consider all the fairness issues when multiplexing multiple streams > > over a virtqueue for example) I don't think this is a good plan. > > I also think vsock isn't the right fit. > +1 we are using vsock right now and we have a few pains because of it. I think the high-level problem is that because it is a side channel, we don't see everything that happens to the buffer in one place (rendering + display) and we can't do things like reallocate the format accordingly if needed, or we can't do flushing etc. on that buffer where needed. Best, Stéphane > > Defining a virtio-wayland device makes sense to me: you get the guest > RAM access via virtqueues, plus the VIRTIO infrastructure (device IDs, > configuration space, feature bits, and existing reusable > kernel/userspace/QEMU code). > > Stefan
