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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 13 Feb 2018 09:41:22 +0200
From:   Pekka Paalanen <ppaalanen@...il.com>
To:     Gerd Hoffmann <kraxel@...hat.com>
Cc:     Tomeu Vizoso <tomeu.vizoso@...labora.com>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        David Airlie <airlied@...ux.ie>,
        Stefan Hajnoczi <stefanha@...il.com>,
        Jason Wang <jasowang@...hat.com>, linux-kernel@...r.kernel.org,
        dri-devel@...ts.freedesktop.org,
        virtualization@...ts.linux-foundation.org, kernel@...labora.com
Subject: Re: [PATCH v3 1/2] drm/virtio: Add window server support

On Mon, 12 Feb 2018 12:45:40 +0100
Gerd Hoffmann <kraxel@...hat.com> 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, ...) to the wayland server.
> > > 
> > >    (b) gpu rendering: client opens a render node, allocates a buffer,
> > >        asks the cpu to renders into it, exports the buffer as dma-buf
> > >        (DRM_IOCTL_PRIME_HANDLE_TO_FD), passes this to the wayland server
> > >        (again including meta data of course).
> > > 
> > > Is that correct?  
> > 
> > Both are correct descriptions of typical behaviors. But it isn't spec'ed
> > anywhere who has to do the buffer allocation.  
> 
> Well, according to Pekka's reply it is spec'ed that way, for the
> existing buffer types.  So for server allocated buffers you need
> (a) a wayland protocol extension and (b) support for the extension
> in the clients.

Correct. Or simply a libEGL that uses such Wayland extension behind
everyone's back. I believe such things did at least exist, but are
probably not relevant for this discussion.

(If there is a standard library, like libEGL, loaded and used by both a
server and a client, that library can advertise custom private Wayland
protocol extensions and the client side can take advantage of them,
both without needing any code changes on either the server or the
client.)

> We also need a solution for the keymap shmem block.  I guess the keymap
> doesn't change all that often, so maybe it is easiest to just copy it
> over (host proxy -> guest proxy) instead of trying to map the host shmem
> into the guest?

Yes, I believe that would be a perfectly valid solution for that
particular case.


Thanks,
pq

Content of type "application/pgp-signature" skipped