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=-2.4 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 E438DFA372C for ; Fri, 8 Nov 2019 07:22:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B2E0620865 for ; Fri, 8 Nov 2019 07:22:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="exA5FOwZ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726072AbfKHHWb (ORCPT ); Fri, 8 Nov 2019 02:22:31 -0500 Received: from us-smtp-1.mimecast.com ([205.139.110.61]:24262 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725802AbfKHHWb (ORCPT ); Fri, 8 Nov 2019 02:22:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573197749; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Y/lLM9Z4Ow+LNPl/oIsVg/AjYSCnHzEPsAKYIkSK9z8=; b=exA5FOwZ+6dFj6HE16uS3RpccNWx2EE/oxoDxh97TEtHYwFal+bhvoo1C8oq7lOpzo9VVg 13wxpaNm9+CGD1EisnV6YCrSkiP9etMpvY6jmZhGWhj5oHQ8S/JLEtBajrGIJHVwCETffQ j/uHA83BQ1OEEin85BU4KTp4z7w88X4= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-416-v1yQem93PpuTYIy_o1Hp-w-1; Fri, 08 Nov 2019 02:22:14 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AF3791005500; Fri, 8 Nov 2019 07:22:11 +0000 (UTC) Received: from sirius.home.kraxel.org (ovpn-116-69.ams2.redhat.com [10.36.116.69]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3DBFC60850; Fri, 8 Nov 2019 07:22:11 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 7414111AAA; Fri, 8 Nov 2019 08:22:10 +0100 (CET) Date: Fri, 8 Nov 2019 08:22:10 +0100 From: Gerd Hoffmann To: Stefan Hajnoczi Cc: 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 , =?utf-8?B?U3TDqXBoYW5l?= Marchesin , Dylan Reid , Gurchetan Singh , Dmitry Morozov , Pawel Osciak , Linux Media Mailing List Subject: Re: guest / host buffer sharing ... Message-ID: <20191108072210.ywyneaoc2y4slth6@sirius.home.kraxel.org> References: <20191105105456.7xbhtistnbp272lj@sirius.home.kraxel.org> <20191106084344.GB189998@stefanha-x1.localdomain> <20191106095122.jju7eo57scfoat6a@sirius.home.kraxel.org> <20191106125023.uhdhtqisybilxasr@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: User-Agent: NeoMutt/20180716 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-MC-Unique: v1yQem93PpuTYIy_o1Hp-w-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org Hi, > > 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. >=20 > 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. cheers, Gerd 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=-2.1 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 5E88FFA372C for ; Fri, 8 Nov 2019 07:23:19 +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 2809420865 for ; Fri, 8 Nov 2019 07:23:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="exA5FOwZ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2809420865 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:50386 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iSyc2-0003T8-5o for qemu-devel@archiver.kernel.org; Fri, 08 Nov 2019 02:23:18 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:39971) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iSybJ-00031n-BE for qemu-devel@nongnu.org; Fri, 08 Nov 2019 02:22:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iSybG-0000xS-Oo for qemu-devel@nongnu.org; Fri, 08 Nov 2019 02:22:31 -0500 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:49033 helo=us-smtp-1.mimecast.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iSybG-0000x8-Gy for qemu-devel@nongnu.org; Fri, 08 Nov 2019 02:22:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573197749; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Y/lLM9Z4Ow+LNPl/oIsVg/AjYSCnHzEPsAKYIkSK9z8=; b=exA5FOwZ+6dFj6HE16uS3RpccNWx2EE/oxoDxh97TEtHYwFal+bhvoo1C8oq7lOpzo9VVg 13wxpaNm9+CGD1EisnV6YCrSkiP9etMpvY6jmZhGWhj5oHQ8S/JLEtBajrGIJHVwCETffQ j/uHA83BQ1OEEin85BU4KTp4z7w88X4= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-416-v1yQem93PpuTYIy_o1Hp-w-1; Fri, 08 Nov 2019 02:22:14 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AF3791005500; Fri, 8 Nov 2019 07:22:11 +0000 (UTC) Received: from sirius.home.kraxel.org (ovpn-116-69.ams2.redhat.com [10.36.116.69]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3DBFC60850; Fri, 8 Nov 2019 07:22:11 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 7414111AAA; Fri, 8 Nov 2019 08:22:10 +0100 (CET) Date: Fri, 8 Nov 2019 08:22:10 +0100 From: Gerd Hoffmann To: Stefan Hajnoczi Subject: Re: guest / host buffer sharing ... Message-ID: <20191108072210.ywyneaoc2y4slth6@sirius.home.kraxel.org> References: <20191105105456.7xbhtistnbp272lj@sirius.home.kraxel.org> <20191106084344.GB189998@stefanha-x1.localdomain> <20191106095122.jju7eo57scfoat6a@sirius.home.kraxel.org> <20191106125023.uhdhtqisybilxasr@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: User-Agent: NeoMutt/20180716 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-MC-Unique: v1yQem93PpuTYIy_o1Hp-w-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 205.139.110.120 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 , Alexandre Courbot , qemu-devel , Tomasz Figa , Keiichi Watanabe , David Stevens , Daniel Vetter , =?utf-8?B?U3TDqXBoYW5l?= Marchesin , Dylan Reid , Gurchetan Singh , Hans Verkuil , Dmitry Morozov , Pawel Osciak , Linux Media Mailing List Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Hi, > > 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. >=20 > 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. cheers, Gerd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-6301-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 3FEBD985F34 for ; Fri, 8 Nov 2019 07:22:30 +0000 (UTC) Date: Fri, 8 Nov 2019 08:22:10 +0100 From: Gerd Hoffmann Message-ID: <20191108072210.ywyneaoc2y4slth6@sirius.home.kraxel.org> References: <20191105105456.7xbhtistnbp272lj@sirius.home.kraxel.org> <20191106084344.GB189998@stefanha-x1.localdomain> <20191106095122.jju7eo57scfoat6a@sirius.home.kraxel.org> <20191106125023.uhdhtqisybilxasr@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: [virtio-dev] Re: guest / host buffer sharing ... To: Stefan Hajnoczi Cc: 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 , =?utf-8?B?U3TDqXBoYW5l?= Marchesin , Dylan Reid , Gurchetan Singh , Dmitry Morozov , Pawel Osciak , Linux Media Mailing List List-ID: Hi, > > 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. >=20 > 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. cheers, Gerd --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org