Re: [PATCH v3 1/2] drm/virtio: Add window server support

2018-02-12 Thread Gerd Hoffmann
Hi, > can we reach agreement on whether vsock should be involved in this? I think the best approach would be to have guest proxy and host proxy use vsock for the wayland protocol. Use a wayland protocol extension to reference the buffers in stdvga / ivshmem / virtio-gpu. Only the two proxies

Re: [PATCH v3 1/2] drm/virtio: Add window server support

2018-02-12 Thread Gerd Hoffmann
Hi, > >(a) software rendering: client allocates shared memory buffer, renders > >into it, then passes a file handle for that shmem block together > >with some meta data (size, format, ...) to the wayland server. > > > >(b) gpu rendering: client opens a render node,

Re: [PATCH] headers: untangle kmemleak.h from mm.h

2018-02-12 Thread Michael Ellerman
Randy Dunlap writes: > From: Randy Dunlap > > Currently #includes for no obvious > reason. It looks like it's only a convenience, so remove kmemleak.h > from slab.h and add to any users of kmemleak_* > that don't already #include it. > Also

Re: [PATCH v3 1/2] drm/virtio: Add window server support

2018-02-12 Thread Tomeu Vizoso
On 02/12/2018 12:52 PM, Gerd Hoffmann wrote: Hi, can we reach agreement on whether vsock should be involved in this? I think the best approach would be to have guest proxy and host proxy use vsock for the wayland protocol. Use a wayland protocol extension to reference the buffers in

Re: [PATCH v3 1/2] drm/virtio: Add window server support

2018-02-12 Thread Tomeu Vizoso
On 02/12/2018 03:27 PM, Gerd Hoffmann wrote: On Mon, Feb 12, 2018 at 03:00:24PM +0100, Tomeu Vizoso wrote: On 02/12/2018 12:52 PM, Gerd Hoffmann wrote: Hi, can we reach agreement on whether vsock should be involved in this? I think the best approach would be to have guest proxy and

Re: [PATCH v3 1/2] drm/virtio: Add window server support

2018-02-12 Thread Gerd Hoffmann
> > I was more thinking about a struct containing enough info to allow the > > proxy on the host side find the buffer, something like: > > > > struct { > >enum type { stdvga, virtio-cpu, ... } > >pcislot device; > >union { > > int stdvga_pcibar_offset; > >

Re: [PATCH v3 1/2] drm/virtio: Add window server support

2018-02-12 Thread Gerd Hoffmann
On Mon, Feb 12, 2018 at 03:00:24PM +0100, Tomeu Vizoso wrote: > On 02/12/2018 12:52 PM, Gerd Hoffmann wrote: > >Hi, > > > > > can we reach agreement on whether vsock should be involved in this? > > > > I think the best approach would be to have guest proxy and host proxy > > use vsock for

Re: [PATCH] headers: untangle kmemleak.h from mm.h

2018-02-12 Thread Randy Dunlap
On 02/12/2018 04:28 AM, Michael Ellerman wrote: > Randy Dunlap writes: > >> From: Randy Dunlap >> >> Currently #includes for no obvious >> reason. It looks like it's only a convenience, so remove kmemleak.h >> from slab.h and add to any users of

Re: [PULL v2 1/1] virtio/s390: implement PM operations for virtio_ccw

2018-02-12 Thread Christian Borntraeger
Michael, Conny, it seems that this patch did not make it into 4.16-rc1. On 12/18/2017 05:21 PM, Cornelia Huck wrote: > From: Christian Borntraeger > > Suspend/Resume to/from disk currently fails. Let us wire > up the necessary callbacks. This is mostly just forwarding

Re: [PATCH v3 1/2] drm/virtio: Add window server support

2018-02-12 Thread Pekka Paalanen
On Mon, 12 Feb 2018 12:45:40 +0100 Gerd Hoffmann wrote: > Hi, > > > >(a) software rendering: client allocates shared memory buffer, renders > > >into it, then passes a file handle for that shmem block together > > >with some meta data (size, format, ...)