On Sat, Nov 9, 2019 at 2:41 AM Stéphane Marchesin <marc...@chromium.org> wrote: > > On Thu, Nov 7, 2019 at 11:35 PM Stefan Hajnoczi <stefa...@gmail.com> wrote: > > > > On Fri, Nov 8, 2019 at 8:22 AM Gerd Hoffmann <kra...@redhat.com> 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.
Do you think a VIRTIO device designed for your use case is an appropriate solution? I have been arguing that these use cases should be addressed with dedicated VIRTIO devices, but I don't understand the use cases of everyone on the CC list so maybe I'm missing something :). If there are reasons why having a VIRTIO device for your use case does not make sense then it would be good to discuss them. Blockers like "VIRTIO is too heavyweight/complex for us because ...", "Our application can't make use of VIRTIO devices because ...", etc would be important to hear. Stefan
