On Sat, Nov 9, 2019 at 12:17 PM Tomasz Figa <tf...@chromium.org> wrote: > On Sat, Nov 9, 2019 at 7:12 PM Stefan Hajnoczi <stefa...@gmail.com> wrote: > > 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. > > Do you have any idea on how to model Wayland as a VIRTIO device? > > Stephane mentioned that we use vsock, but in fact we have our own > VIRTIO device, except that it's semantically almost the same as vsock, > with a difference being the ability to pass buffers and pipes across > the VM boundary.
I know neither Wayland nor your use case :). But we can discuss the design of your VIRTIO device. Please post a link to the code. Stefan
