From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 82FECC17440 for ; Sat, 9 Nov 2019 01:41:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 42A29214DA for ; Sat, 9 Nov 2019 01:41:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="S7Ja/TiG" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725990AbfKIBlR (ORCPT ); Fri, 8 Nov 2019 20:41:17 -0500 Received: from mail-il1-f174.google.com ([209.85.166.174]:44608 "EHLO mail-il1-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725817AbfKIBlR (ORCPT ); Fri, 8 Nov 2019 20:41:17 -0500 Received: by mail-il1-f174.google.com with SMTP id i6so6775376ilr.11 for ; Fri, 08 Nov 2019 17:41:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wVtEFg/Qou+aYXahULIg4Ddk9uw4TDjxaxbD5XH4JVs=; b=S7Ja/TiGlPkwGljdD/iajvmhHtBPABLFf+GeQU9NhSJftJ5DYnEhmRClF/OVp7pyj2 I+vI3Z150NjX/t6quJ9JBX7l6ZSxi410Oq4lJPoW0T28FDVLf6oAiBcMvmB+TRuUupAl PoYg/UknnwucQ1CO3eC98JAtBBqzEiT+FMkrw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wVtEFg/Qou+aYXahULIg4Ddk9uw4TDjxaxbD5XH4JVs=; b=Hfgs/1RAwm4gosZ0MZmvWWcInyoZG3irSO2gFxoQSnTcgGusYhSzS0n5xjUZ66jm/E bxviYHtHrfjotQGCBSHe6mz8TcsG1EtxDOUsi0B5zhFmfCn9xEx5cVFZ9TQXHSKdSuGx qBLdJGdA3czj3QBGVeM99T8G8ywpMq8phQ9rzVme02rIjmoaFLC0EOLsQ0rh8oD+fA14 qXZsWfQ5k/AcqFTYh2z0eiXPtq8J5a63to3NZPqY1ZH8pNPlP/3VYl81EESd8rcC3blO Ey3kSp7e2d9smVn10cNyUwLuduJ939g3Z3nEihy9ke/y015Icg/g97yGwrRqb704ES/9 meBw== X-Gm-Message-State: APjAAAVFoNgZtNidfsTE1HI7NEliekMvCvDDFqsjjTOJhImzc/Ymk0Ih QzxABeSi2dykAcc+QdE2B8SWjjtf5jO0R/C/rEDoxw== X-Google-Smtp-Source: APXvYqyH9hhaGKo/8SsZPmZFQrsL0XDoeeBeKZspgW0B81ZfhsLOgDMjyjHCpc90IJaEKILodBC9tZm0Wuo1ZEWPa3Q= X-Received: by 2002:a92:5d88:: with SMTP id e8mr16072462ilg.95.1573263676306; Fri, 08 Nov 2019 17:41:16 -0800 (PST) MIME-Version: 1.0 References: <20191105105456.7xbhtistnbp272lj@sirius.home.kraxel.org> <20191106084344.GB189998@stefanha-x1.localdomain> <20191106095122.jju7eo57scfoat6a@sirius.home.kraxel.org> <20191106125023.uhdhtqisybilxasr@sirius.home.kraxel.org> <20191108072210.ywyneaoc2y4slth6@sirius.home.kraxel.org> In-Reply-To: From: =?UTF-8?Q?St=C3=A9phane_Marchesin?= Date: Fri, 8 Nov 2019 17:41:04 -0800 Message-ID: Subject: Re: guest / host buffer sharing ... To: Stefan Hajnoczi Cc: Gerd Hoffmann , geoff@hostfission.com, virtio-dev@lists.oasis-open.org, Alex Lau , Daniel Vetter , Alexandre Courbot , qemu-devel , Tomasz Figa , Keiichi Watanabe , David Stevens , Hans Verkuil , Dylan Reid , Gurchetan Singh , Dmitry Morozov , Pawel Osciak , Linux Media Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org On Thu, Nov 7, 2019 at 11:35 PM Stefan Hajnoczi wrote: > > On Fri, Nov 8, 2019 at 8:22 AM Gerd Hoffmann wrote: > > > > Adding a list of common properties to the spec certainly makes sens= e, > > > > 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 ru= n > > the stream pipe over vsock. But there is nothing for the shared > > buffers ... > > > > We could replicate vsock functionality elsewhere. I think that happene= d > > in the out-of-tree virtio-wayland implementation. There also was some > > discussion about adding streams to virtio-gpu, slightly pimped up so yo= u > > 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. Best, St=C3=A9phane > > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 47F08C17441 for ; Sat, 9 Nov 2019 02:18:35 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1403D214DA for ; Sat, 9 Nov 2019 02:18:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="S7Ja/TiG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1403D214DA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:34540 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iTGKg-00070v-7i for qemu-devel@archiver.kernel.org; Fri, 08 Nov 2019 21:18:34 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:60444) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iTFkg-0000HP-8e for qemu-devel@nongnu.org; Fri, 08 Nov 2019 20:41:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iTFkf-00044n-08 for qemu-devel@nongnu.org; Fri, 08 Nov 2019 20:41:22 -0500 Received: from mail-il1-x133.google.com ([2607:f8b0:4864:20::133]:38263) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iTFke-00041A-Nn for qemu-devel@nongnu.org; Fri, 08 Nov 2019 20:41:20 -0500 Received: by mail-il1-x133.google.com with SMTP id u17so1905830ilq.5 for ; Fri, 08 Nov 2019 17:41:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wVtEFg/Qou+aYXahULIg4Ddk9uw4TDjxaxbD5XH4JVs=; b=S7Ja/TiGlPkwGljdD/iajvmhHtBPABLFf+GeQU9NhSJftJ5DYnEhmRClF/OVp7pyj2 I+vI3Z150NjX/t6quJ9JBX7l6ZSxi410Oq4lJPoW0T28FDVLf6oAiBcMvmB+TRuUupAl PoYg/UknnwucQ1CO3eC98JAtBBqzEiT+FMkrw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wVtEFg/Qou+aYXahULIg4Ddk9uw4TDjxaxbD5XH4JVs=; b=jmuRei4QMsOxYHKqLX7OrQg0yKgn1cwHdYgnO0+CdpSz8VmCNML8QVCL3itpDhZKar MFnvjpkE+4EljZMLTbSwMeU95Um3ZswprEGF8JBmCyy/ZWjkRl5LlAEqbht8rcS7bt+m DirsbbLsmylUrsPAExautApURRXAemMY+J4tNkeXYzgIZtOrkBMbW/pkxIFUbjCiFdKi RuZe91y0Ru9pPeR3R1yIMWi1D0CRVM6GYqecHrajELzIMKwobgovZTUbo3A6WN8XFCoM OgIVHBA8ZTdlKmkatemhPfehcINZh3GnDGin5XefFxhYc8LwCQTEWpjBkKT73PKOs8yu LNZA== X-Gm-Message-State: APjAAAWom9fmCE7pxiqTDX4l8s4RziECcB7DsOJsHDbqQV+zZ4mew9EF jkYC77urnVh7D+zviBoRZvw/B6TAjt33QvT9lSoDYw== X-Google-Smtp-Source: APXvYqyH9hhaGKo/8SsZPmZFQrsL0XDoeeBeKZspgW0B81ZfhsLOgDMjyjHCpc90IJaEKILodBC9tZm0Wuo1ZEWPa3Q= X-Received: by 2002:a92:5d88:: with SMTP id e8mr16072462ilg.95.1573263676306; Fri, 08 Nov 2019 17:41:16 -0800 (PST) MIME-Version: 1.0 References: <20191105105456.7xbhtistnbp272lj@sirius.home.kraxel.org> <20191106084344.GB189998@stefanha-x1.localdomain> <20191106095122.jju7eo57scfoat6a@sirius.home.kraxel.org> <20191106125023.uhdhtqisybilxasr@sirius.home.kraxel.org> <20191108072210.ywyneaoc2y4slth6@sirius.home.kraxel.org> In-Reply-To: From: =?UTF-8?Q?St=C3=A9phane_Marchesin?= Date: Fri, 8 Nov 2019 17:41:04 -0800 Message-ID: Subject: Re: guest / host buffer sharing ... To: Stefan Hajnoczi Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::133 X-Mailman-Approved-At: Fri, 08 Nov 2019 21:15:51 -0500 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: geoff@hostfission.com, virtio-dev@lists.oasis-open.org, Alex Lau , Linux Media Mailing List , Alexandre Courbot , qemu-devel , Tomasz Figa , Keiichi Watanabe , Gerd Hoffmann , Daniel Vetter , Dylan Reid , Gurchetan Singh , Hans Verkuil , Dmitry Morozov , Pawel Osciak , David Stevens Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Thu, Nov 7, 2019 at 11:35 PM Stefan Hajnoczi wrote: > > On Fri, Nov 8, 2019 at 8:22 AM Gerd Hoffmann wrote: > > > > Adding a list of common properties to the spec certainly makes sens= e, > > > > 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 ru= n > > the stream pipe over vsock. But there is nothing for the shared > > buffers ... > > > > We could replicate vsock functionality elsewhere. I think that happene= d > > in the out-of-tree virtio-wayland implementation. There also was some > > discussion about adding streams to virtio-gpu, slightly pimped up so yo= u > > 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. Best, St=C3=A9phane > > 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