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.7 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 D3763C5DF60 for ; Thu, 7 Nov 2019 12:11:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 992602166E for ; Thu, 7 Nov 2019 12:11:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="EKVQuk55" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733201AbfKGMLF (ORCPT ); Thu, 7 Nov 2019 07:11:05 -0500 Received: from mail-qv1-f65.google.com ([209.85.219.65]:44425 "EHLO mail-qv1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726873AbfKGMLE (ORCPT ); Thu, 7 Nov 2019 07:11:04 -0500 Received: by mail-qv1-f65.google.com with SMTP id h3so657839qvu.11 for ; Thu, 07 Nov 2019 04:11:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BKA8s1JfODN4WpwTCWOwtgTT+YzZkjzLVM4z9feXflo=; b=EKVQuk55NqGEBZhbV8BVxDQYjsoT81dzTmsRxPY6wkvHgR2201EEbrXM/f+4dt4b8x MPP/nzcAMrp6SuDo7mbSGX+LcQXh9/pd9oETm1jFw8TBDLojxjDHClV4PYzZjrVoAfzl csCkA+bh69AXVz2hqudiqDmMhOKR2EP2/zDBezyvS6xwXVvU6VeH4m5JKswsrvrFK8bR HmHUt1XUt7m8iCpGV+8+6/RH8ExPqoITwjlgKh04ScfyEKG2NEHwTyUI4FssxUMUdT+M pM9jt1TEN20IHzkT063k8iwpbZp2J6R173q2JvMGx6Bb28lCQmAMELV9z9q/3QBIxOjF EIdg== 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; bh=BKA8s1JfODN4WpwTCWOwtgTT+YzZkjzLVM4z9feXflo=; b=nWzWnLtoJND42oT08Q7ULttbm1vI81S8tyH6ialZA+cp4af+b+hmOViVa6XyT5vy3/ hgOKihV4zfAWMeZHI+34hVwrYdjhY5aEKiD7F32UdAmIYV42XQ0oQFhJGWZBCtEZ0IQU BDh/YZ63qlVOmouIAdz7BbrHpcGjE8M4THSJZzB32i15HBnq7SlSZMfPwFaTJ4E2sIqM 623zzeh2AzdFV20zElEN9SasEeTDUsD3vvdVGiz9zlf2i4XPcHqrvxlbVHR4oCSw5Wpt wGZlKWPWi37fsMo6mLqamJGMuseMB9lSbIVUzv87Qtm85Vikj+KfDoR9NLtGxr9zUgGv t/XA== X-Gm-Message-State: APjAAAWLs8HWjZyP8FaVNfzAiai4numnqvPtlO3ph1mgbfqhLxT/KIaJ 7I9lZVuq8KzkhJokqQo2BItLnr9l9c0+3nTmm28= X-Google-Smtp-Source: APXvYqzsPlvpOUDn7EkcGf9rJWzzK0UmVSKgbkHC5ep6B4ucYn8RQygbhppA26x9x2LAw1qeWeDvK70JS85dMoOF3WQ= X-Received: by 2002:a0c:87b5:: with SMTP id 50mr3064636qvj.143.1573128663596; Thu, 07 Nov 2019 04:11:03 -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> In-Reply-To: <20191106125023.uhdhtqisybilxasr@sirius.home.kraxel.org> From: Stefan Hajnoczi Date: Thu, 7 Nov 2019 13:10:52 +0100 Message-ID: Subject: Re: guest / host buffer sharing ... To: Gerd Hoffmann 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?Q?St=C3=A9phane_Marchesin?= , Dylan Reid , Gurchetan Singh , Dmitry Morozov , Pawel Osciak , Linux Media Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org On Wed, Nov 6, 2019 at 1:50 PM Gerd Hoffmann wrote: > > In the graphics buffer sharing use case, how does the other side > > determine how to interpret this data? > > The idea is to have free form properties (name=value, with value being > a string) for that kind of metadata. > > > Shouldn't there be a VIRTIO > > device spec for the messaging so compatible implementations can be > > written by others? > > 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. Why not define VIRTIO devices for wayland and friends? This new device exposes buffer sharing plus properties - effectively a new device model nested inside VIRTIO. The VIRTIO device model has the necessary primitives to solve the buffer sharing problem so I'm struggling to see the purpose of this new device. Custom/niche applications that do not wish to standardize their device type can maintain out-of-tree VIRTIO devices. Both kernel and userspace drivers can be written for the device and there is already VIRTIO driver code that can be reused. They have access to the full VIRTIO device model, including feature negotiation and configuration space. Stefan