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. 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
