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 75EC7C432C3 for ; Wed, 20 Nov 2019 10:12:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3C7BB2243F for ; Wed, 20 Nov 2019 10:12:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="lDa6MWbx" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728369AbfKTKMP (ORCPT ); Wed, 20 Nov 2019 05:12:15 -0500 Received: from mail-ed1-f49.google.com ([209.85.208.49]:42494 "EHLO mail-ed1-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726229AbfKTKMP (ORCPT ); Wed, 20 Nov 2019 05:12:15 -0500 Received: by mail-ed1-f49.google.com with SMTP id m13so19801764edv.9 for ; Wed, 20 Nov 2019 02:12:12 -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=k0eJ6rySdlpAX4BY9OLA/pzu+RYxPKTylT0yhkAx2x8=; b=lDa6MWbxkoAcBE1WDpHJD32hmuqJ8H2y9qhPgl095mw5QjXZtpdBgnIBayjwwX3eU2 akCqWDNmQEcJ3Wc5h6NHCWAidyQZZBigVxAe3LTLCxA2UAgmD5sY6LFRuM0Ijcm7Ltyj 8iyTi1H9C9VCNkFwrUYfC2YMmAqL0BNIm+Em8= 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=k0eJ6rySdlpAX4BY9OLA/pzu+RYxPKTylT0yhkAx2x8=; b=P+5JmCLmbSkUN8jAPCXt1KssdUeIebibZfo89dY33hi4OdS/vJRvJtFlYx+ZonyrM6 2bTFSxpt8cHzDVYJi/8WBmAEU/VB29RojCv/3EGwKrWXCaEZ0YmxH8SB3Wi1gxImczza +TXKr47DkTrZYakeerQoNu+/Bt98uznZaqHE7r6nGYiETKF8eAMPD5FA6WjEauE+7xMl gdnML17YirRl5oQNM4uXbg1a7zDq3GYQziagLr2ZwvJ8ib9SWp2EidbTf7L59ebENS8v PcfJdtmHh8DbiRyxU1UOInNk6djxd2cfO0cZmzYZob7qad9Vscujt3GAx8w+q4xEg2uE oifQ== X-Gm-Message-State: APjAAAWSnafIyFySfyRedAPnF97Nm0gAJbQMHlBlAEg7YIb9asUY1xkU mqkkCk+qiuNY1E3zk684fO4bicTBR4hRxw== X-Google-Smtp-Source: APXvYqyNnygLzZIkiOB/q7miEGO7V8+l9L+mIGSpS1o+hLwzxR+49oS+32vCqvTY4iOmiDOpm97heA== X-Received: by 2002:a17:906:7a47:: with SMTP id i7mr4348348ejo.22.1574244730897; Wed, 20 Nov 2019 02:12:10 -0800 (PST) Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com. [209.85.128.54]) by smtp.gmail.com with ESMTPSA id t27sm1369691edt.75.2019.11.20.02.12.10 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 Nov 2019 02:12:10 -0800 (PST) Received: by mail-wm1-f54.google.com with SMTP id y5so947918wmi.5 for ; Wed, 20 Nov 2019 02:12:10 -0800 (PST) X-Received: by 2002:a7b:cbd9:: with SMTP id n25mr2297809wmi.64.1574244729507; Wed, 20 Nov 2019 02:12:09 -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: Tomasz Figa Date: Wed, 20 Nov 2019 19:11:56 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: guest / host buffer sharing ... To: Stefan Hajnoczi Cc: =?UTF-8?Q?St=C3=A9phane_Marchesin?= , Gerd Hoffmann , geoff@hostfission.com, virtio-dev@lists.oasis-open.org, Alex Lau , Daniel Vetter , Alexandre Courbot , qemu-devel , 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 Hi Stefan, On Mon, Nov 18, 2019 at 7:21 PM Stefan Hajnoczi wrote: > > On Sat, Nov 9, 2019 at 3:12 PM Tomasz Figa wrote: > > > > On Sat, Nov 9, 2019 at 9:08 PM Stefan Hajnoczi wro= te: > > > > > > On Sat, Nov 9, 2019 at 12:17 PM Tomasz Figa wrot= e: > > > > On Sat, Nov 9, 2019 at 7:12 PM Stefan Hajnoczi = wrote: > > > > > On Sat, Nov 9, 2019 at 2:41 AM St=C3=A9phane Marchesin wrote: > > > > > > 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 certainl= y makes sense, > > > > > > > > > > so everybody uses the same names. Adding struct-ed pro= perties 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, tha= t 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, exc= ept 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 serve= r you can run > > > > > > > > the stream pipe over vsock. But there is nothing for the s= hared > > > > > > > > buffers ... > > > > > > > > > > > > > > > > We could replicate vsock functionality elsewhere. I think = that happened > > > > > > > > in the out-of-tree virtio-wayland implementation. There al= so was some > > > > > > > > discussion about adding streams to virtio-gpu, slightly pim= ped up so you > > > > > > > > can easily pass around virtio-gpu resource references for b= uffer > > > > > > > > sharing. But given that getting vsock right isn't exactly = trivial > > > > > > > > (consider all the fairness issues when multiplexing multipl= e 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 cha= nnel, > > > > > > we don't see everything that happens to the buffer in one place > > > > > > (rendering + display) and we can't do things like reallocate th= e > > > > > > format accordingly if needed, or we can't do flushing etc. on t= hat > > > > > > buffer where needed. > > > > > > > > > > Do you think a VIRTIO device designed for your use case is an > > > > > appropriate solution? > > > > > > > > > > I have been arguing that these use cases should be addressed with > > > > > dedicated VIRTIO devices, but I don't understand the use cases of > > > > > everyone on the CC list so maybe I'm missing something :). If th= ere > > > > > are reasons why having a VIRTIO device for your use case does not= make > > > > > sense then it would be good to discuss them. Blockers like "VIRT= IO is > > > > > too heavyweight/complex for us because ...", "Our application can= 't > > > > > make use of VIRTIO devices because ...", etc would be important t= o > > > > > hear. > > > > > > > > Do you have any idea on how to model Wayland as a VIRTIO device? > > > > > > > > Stephane mentioned that we use vsock, but in fact we have our own > > > > VIRTIO device, except that it's semantically almost the same as vso= ck, > > > > with a difference being the ability to pass buffers and pipes acros= s > > > > the VM boundary. > > > > > > I know neither Wayland nor your use case :). > > > > > > But we can discuss the design of your VIRTIO device. Please post a > > > link to the code. > > > > The guest-side driver: > > https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chrom= eos-4.19/drivers/virtio/virtio_wl.c > > > > Protocol definitions: > > https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chrom= eos-4.19/include/uapi/linux/virtio_wl.h > > > > crosvm device implementation: > > https://chromium.googlesource.com/chromiumos/platform/crosvm/+/refs/hea= ds/master/devices/src/virtio/wl.rs > > Thanks, Tomasz! > > Unfortunately I haven't had a chance to look or catch up on this email > thread due to other work that will keep me away for at least another > week :(. Thanks for the note. Waiting patiently. :) Best regards, Tomasz 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 09E46C432C0 for ; Wed, 20 Nov 2019 10:13:32 +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 C5D9B22311 for ; Wed, 20 Nov 2019 10:13:31 +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="lDa6MWbx" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C5D9B22311 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]:55694 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iXMzK-0003g5-Qy for qemu-devel@archiver.kernel.org; Wed, 20 Nov 2019 05:13:30 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:52931) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iXMy6-0002lY-Rl for qemu-devel@nongnu.org; Wed, 20 Nov 2019 05:12:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iXMy5-000575-9H for qemu-devel@nongnu.org; Wed, 20 Nov 2019 05:12:14 -0500 Received: from mail-ed1-x535.google.com ([2a00:1450:4864:20::535]:46428) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iXMy5-00055E-0W for qemu-devel@nongnu.org; Wed, 20 Nov 2019 05:12:13 -0500 Received: by mail-ed1-x535.google.com with SMTP id t11so13800684eds.13 for ; Wed, 20 Nov 2019 02:12:12 -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=k0eJ6rySdlpAX4BY9OLA/pzu+RYxPKTylT0yhkAx2x8=; b=lDa6MWbxkoAcBE1WDpHJD32hmuqJ8H2y9qhPgl095mw5QjXZtpdBgnIBayjwwX3eU2 akCqWDNmQEcJ3Wc5h6NHCWAidyQZZBigVxAe3LTLCxA2UAgmD5sY6LFRuM0Ijcm7Ltyj 8iyTi1H9C9VCNkFwrUYfC2YMmAqL0BNIm+Em8= 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=k0eJ6rySdlpAX4BY9OLA/pzu+RYxPKTylT0yhkAx2x8=; b=i6b4yDbSpEpyfTYQOMlK9GRpz9E7rXeJXYUpQ0NXsqU1XhM4MA5I5lMj6AQ4YGpA/k wGSbFg9wZI1KfgDmu2xipEyEuTRJpCJVxOByj8Ryi0LpLqZbrBduJ4b3rTvaH/84PVvO N+KFBs6EiG9kRsQWteELkOQXzMSJmfpo+FoLeUIhG9VY4naYfanFt8QAVLKVvBhrBv9F 4V24YhFYIV3WW8cZ6Vg7XBaptRqMFqHF7VZcVENQaiaudItkwh4kUuzZD+YmEj/X5lHQ DqBg3g5QBMmEPO8KL69nwh5BAJS2Hd1fJQQysNTi1+weoKfwBMCebd9B+pSpk/7pXfjr chvA== X-Gm-Message-State: APjAAAVEptaPtf7CgxV7uaxZ5iIQnE7MShGPPtFQX3qN5JdSPXZutpJa NxeCnfvhFViU7SqSqWvkkdvdBNo42Q7Z9A== X-Google-Smtp-Source: APXvYqwLjlG6TFT/ub9yaUq9dU3qAgSdttEOToR8+kVgm2EDCwLzE3R+LXL8lZd8zNbFIPkXwwy6Fw== X-Received: by 2002:a17:906:d210:: with SMTP id w16mr4372730ejz.86.1574244730807; Wed, 20 Nov 2019 02:12:10 -0800 (PST) Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com. [209.85.128.47]) by smtp.gmail.com with ESMTPSA id b20sm1608256edu.15.2019.11.20.02.12.10 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 Nov 2019 02:12:10 -0800 (PST) Received: by mail-wm1-f47.google.com with SMTP id j18so4694110wmk.1 for ; Wed, 20 Nov 2019 02:12:10 -0800 (PST) X-Received: by 2002:a7b:cbd9:: with SMTP id n25mr2297809wmi.64.1574244729507; Wed, 20 Nov 2019 02:12:09 -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: Tomasz Figa Date: Wed, 20 Nov 2019 19:11:56 +0900 X-Gmail-Original-Message-ID: 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: 2a00:1450:4864:20::535 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 , Gurchetan Singh , Keiichi Watanabe , Gerd Hoffmann , Daniel Vetter , =?UTF-8?Q?St=C3=A9phane_Marchesin?= , Dylan Reid , Linux Media Mailing List , Hans Verkuil , Dmitry Morozov , Pawel Osciak , David Stevens Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Hi Stefan, On Mon, Nov 18, 2019 at 7:21 PM Stefan Hajnoczi wrote: > > On Sat, Nov 9, 2019 at 3:12 PM Tomasz Figa wrote: > > > > On Sat, Nov 9, 2019 at 9:08 PM Stefan Hajnoczi wro= te: > > > > > > On Sat, Nov 9, 2019 at 12:17 PM Tomasz Figa wrot= e: > > > > On Sat, Nov 9, 2019 at 7:12 PM Stefan Hajnoczi = wrote: > > > > > On Sat, Nov 9, 2019 at 2:41 AM St=C3=A9phane Marchesin wrote: > > > > > > 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 certainl= y makes sense, > > > > > > > > > > so everybody uses the same names. Adding struct-ed pro= perties 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, tha= t 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, exc= ept 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 serve= r you can run > > > > > > > > the stream pipe over vsock. But there is nothing for the s= hared > > > > > > > > buffers ... > > > > > > > > > > > > > > > > We could replicate vsock functionality elsewhere. I think = that happened > > > > > > > > in the out-of-tree virtio-wayland implementation. There al= so was some > > > > > > > > discussion about adding streams to virtio-gpu, slightly pim= ped up so you > > > > > > > > can easily pass around virtio-gpu resource references for b= uffer > > > > > > > > sharing. But given that getting vsock right isn't exactly = trivial > > > > > > > > (consider all the fairness issues when multiplexing multipl= e 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 cha= nnel, > > > > > > we don't see everything that happens to the buffer in one place > > > > > > (rendering + display) and we can't do things like reallocate th= e > > > > > > format accordingly if needed, or we can't do flushing etc. on t= hat > > > > > > buffer where needed. > > > > > > > > > > Do you think a VIRTIO device designed for your use case is an > > > > > appropriate solution? > > > > > > > > > > I have been arguing that these use cases should be addressed with > > > > > dedicated VIRTIO devices, but I don't understand the use cases of > > > > > everyone on the CC list so maybe I'm missing something :). If th= ere > > > > > are reasons why having a VIRTIO device for your use case does not= make > > > > > sense then it would be good to discuss them. Blockers like "VIRT= IO is > > > > > too heavyweight/complex for us because ...", "Our application can= 't > > > > > make use of VIRTIO devices because ...", etc would be important t= o > > > > > hear. > > > > > > > > Do you have any idea on how to model Wayland as a VIRTIO device? > > > > > > > > Stephane mentioned that we use vsock, but in fact we have our own > > > > VIRTIO device, except that it's semantically almost the same as vso= ck, > > > > with a difference being the ability to pass buffers and pipes acros= s > > > > the VM boundary. > > > > > > I know neither Wayland nor your use case :). > > > > > > But we can discuss the design of your VIRTIO device. Please post a > > > link to the code. > > > > The guest-side driver: > > https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chrom= eos-4.19/drivers/virtio/virtio_wl.c > > > > Protocol definitions: > > https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chrom= eos-4.19/include/uapi/linux/virtio_wl.h > > > > crosvm device implementation: > > https://chromium.googlesource.com/chromiumos/platform/crosvm/+/refs/hea= ds/master/devices/src/virtio/wl.rs > > Thanks, Tomasz! > > Unfortunately I haven't had a chance to look or catch up on this email > thread due to other work that will keep me away for at least another > week :(. Thanks for the note. Waiting patiently. :) Best regards, Tomasz From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-6348-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 176EA985E6F for ; Wed, 20 Nov 2019 10:12:13 +0000 (UTC) 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: Tomasz Figa Date: Wed, 20 Nov 2019 19:11:56 +0900 Message-ID: Subject: [virtio-dev] Re: guest / host buffer sharing ... Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To: Stefan Hajnoczi Cc: =?UTF-8?Q?St=C3=A9phane_Marchesin?= , Gerd Hoffmann , geoff@hostfission.com, virtio-dev@lists.oasis-open.org, Alex Lau , Daniel Vetter , Alexandre Courbot , qemu-devel , Keiichi Watanabe , David Stevens , Hans Verkuil , Dylan Reid , Gurchetan Singh , Dmitry Morozov , Pawel Osciak , Linux Media Mailing List List-ID: Hi Stefan, On Mon, Nov 18, 2019 at 7:21 PM Stefan Hajnoczi wrote: > > On Sat, Nov 9, 2019 at 3:12 PM Tomasz Figa wrote: > > > > On Sat, Nov 9, 2019 at 9:08 PM Stefan Hajnoczi wro= te: > > > > > > On Sat, Nov 9, 2019 at 12:17 PM Tomasz Figa wrot= e: > > > > On Sat, Nov 9, 2019 at 7:12 PM Stefan Hajnoczi = wrote: > > > > > On Sat, Nov 9, 2019 at 2:41 AM St=C3=A9phane Marchesin wrote: > > > > > > 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 certainl= y makes sense, > > > > > > > > > > so everybody uses the same names. Adding struct-ed pro= perties 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, tha= t 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, exc= ept 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 serve= r you can run > > > > > > > > the stream pipe over vsock. But there is nothing for the s= hared > > > > > > > > buffers ... > > > > > > > > > > > > > > > > We could replicate vsock functionality elsewhere. I think = that happened > > > > > > > > in the out-of-tree virtio-wayland implementation. There al= so was some > > > > > > > > discussion about adding streams to virtio-gpu, slightly pim= ped up so you > > > > > > > > can easily pass around virtio-gpu resource references for b= uffer > > > > > > > > sharing. But given that getting vsock right isn't exactly = trivial > > > > > > > > (consider all the fairness issues when multiplexing multipl= e 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 cha= nnel, > > > > > > we don't see everything that happens to the buffer in one place > > > > > > (rendering + display) and we can't do things like reallocate th= e > > > > > > format accordingly if needed, or we can't do flushing etc. on t= hat > > > > > > buffer where needed. > > > > > > > > > > Do you think a VIRTIO device designed for your use case is an > > > > > appropriate solution? > > > > > > > > > > I have been arguing that these use cases should be addressed with > > > > > dedicated VIRTIO devices, but I don't understand the use cases of > > > > > everyone on the CC list so maybe I'm missing something :). If th= ere > > > > > are reasons why having a VIRTIO device for your use case does not= make > > > > > sense then it would be good to discuss them. Blockers like "VIRT= IO is > > > > > too heavyweight/complex for us because ...", "Our application can= 't > > > > > make use of VIRTIO devices because ...", etc would be important t= o > > > > > hear. > > > > > > > > Do you have any idea on how to model Wayland as a VIRTIO device? > > > > > > > > Stephane mentioned that we use vsock, but in fact we have our own > > > > VIRTIO device, except that it's semantically almost the same as vso= ck, > > > > with a difference being the ability to pass buffers and pipes acros= s > > > > the VM boundary. > > > > > > I know neither Wayland nor your use case :). > > > > > > But we can discuss the design of your VIRTIO device. Please post a > > > link to the code. > > > > The guest-side driver: > > https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chrom= eos-4.19/drivers/virtio/virtio_wl.c > > > > Protocol definitions: > > https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chrom= eos-4.19/include/uapi/linux/virtio_wl.h > > > > crosvm device implementation: > > https://chromium.googlesource.com/chromiumos/platform/crosvm/+/refs/hea= ds/master/devices/src/virtio/wl.rs > > Thanks, Tomasz! > > Unfortunately I haven't had a chance to look or catch up on this email > thread due to other work that will keep me away for at least another > week :(. Thanks for the note. Waiting patiently. :) Best regards, Tomasz --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org