From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomeu Vizoso Subject: Re: passing FDs across domains Date: Tue, 14 Nov 2017 15:01:48 +0100 Message-ID: <33a3c022-6c53-4e9c-e999-2caefde3e8fb@collabora.com> References: <2d73a3e1-af70-83a1-0e84-98b5932ea20c@collabora.com> <20171114080257.p7fcafmfva64aeua@sirius.home.kraxel.org> <20171114093337.hxz4uvnimets2ca6@sirius.home.kraxel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Cc: kvm@vger.kernel.org, Stefan Hajnoczi , Zach Reizner , Helen Mae Koike Fornazier , David Airlie , =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= To: Gerd Hoffmann Return-path: Received: from bhuna.collabora.co.uk ([46.235.227.227]:42364 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753507AbdKNOBx (ORCPT ); Tue, 14 Nov 2017 09:01:53 -0500 In-Reply-To: <20171114093337.hxz4uvnimets2ca6@sirius.home.kraxel.org> Content-Language: en-US Sender: kvm-owner@vger.kernel.org List-ID: On 11/14/2017 10:33 AM, Gerd Hoffmann wrote: > Hi, > > [ Cc'ing David Airlie and Marc-André Lureau ] > >>> Lets step back and look at the problem you are trying to solve. >>> >>> It seems you want guest wayland applications appear seamless on the host >>> wayland server, correct? >> >> Correct. >> >>> How does the wayland rendering workflow look like? As far I know the >>> wayland protocol doesn't include any rendering. Rendering happens >>> client side, into some buffer (one per window), which is then passed to >>> the server for display compositing. Correct? So you basically want >>> pass that buffer from guest to host? >> >> Correct. >> >>> What kind of shared memory is used by wayland? >>> sysv shm? gbm buffers / dmabufs? >> >> Typically, shared memory for CPU-rendered content, and dmabufs for >> GPU-rendered content. > > Ok. I guess solving this for virtio-gpu (with virgl enabled) is easiest > then. Due to opengl rendering being offloaded to the host gpu the > guest window content already is in a host gpu buffer. Yes, besides, we already have virtio-gpu in place which can be improved as needed. I'm more worried about CPU-rendered buffers, as the client is just putting in the socket the output of shm_open or similar. There I don't see any easy solution which is why I tried to get more "creative". Thanks, Tomeu > So we "only" need to export that buffer as dmabuf and pass it to the > wayland server. That still doesn't look trivial though. qemu must > manage the dmabufs, so it must be involved somehow; a direct guest > client -> host server wayland connection (alone) will not work. > > I think we need either a wayland proxy in qemu which rewrites the buffer > references, or the host wayland server must talk to both guest client > (vsock could work for that) and qemu (for dmabuf management). Or some > mixed model, such as a separate wayland proxy server talking to qemu for > dmabuf management. > > I suspect in any case we need a wayland protocol extension for a new > buffer type as passing buffer references from guest to host can't use > filehandles. > > cheers, > Gerd >