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=-8.3 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 8BFAFC43603 for ; Wed, 11 Dec 2019 16:05:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5F4872077B for ; Wed, 11 Dec 2019 16:05:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="vTsmwQUG" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388102AbfLKQF4 (ORCPT ); Wed, 11 Dec 2019 11:05:56 -0500 Received: from mail-qk1-f193.google.com ([209.85.222.193]:39725 "EHLO mail-qk1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732793AbfLKQFy (ORCPT ); Wed, 11 Dec 2019 11:05:54 -0500 Received: by mail-qk1-f193.google.com with SMTP id c16so11660381qko.6 for ; Wed, 11 Dec 2019 08:05:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rehiyiPENjIb3TkGzxdImMUheY4m13it4HkAOv4ifvA=; b=vTsmwQUGn0PUh4gMKS4wWcvmJG9Rls92dzR7yu3qn9LK1XT3kD28mO+CU67Z6t3Kjg Hdg1fiVHJmBBtpaFSWqVTc8/bEFywDYGJH/GPAe+PvySrIKunzLxecQ5DxeXrtNn04T7 MZbJXaN6QLLDpvIJFkZoeoYorXVI56DjLDfGXfmV9VXgzcEvimD1OsJ/ObTAkyFpTK9j Bh4zi2aWz1IAadMIXSNWBe7WEjdVJM963QzpsU8/fprO8FZ2t6aMpI+3qrBcCClsTg7s fIaIr27QMj1Um5In/gi8No9JpBYd1pH9esdh8Wg/nVdRbFKofD6BOkla/vA26Wpq3lR9 trzQ== 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=rehiyiPENjIb3TkGzxdImMUheY4m13it4HkAOv4ifvA=; b=MSpAAbXjNZ/KUauztmatZB4eG8Wu+78L0uhSRoZXxHDKpZKDLpsORrgqEUfBu88UjQ OfXs7OLJ6sIU+jCeoFkTa5MKJA8JXQ/4f6qor/ddTInn8uQf7alD6rgPBnYuavhekOme zjyvZur/n8AhShnQwt5NTm2GqjCQqOQvkfNS1SjtebraUjqFfC3w8YKoIyf2dxGGCZvZ VO4W7FbI5CuZmW4puJKmTSPMQIryR9zEGxZ9A6iY1XamSbdtTxNxKcBrUXmK46gFMLCY hIext33qksKvZjflRYobInA0VrHgP6rZYf9uDGfPjMlCGxwQQ4DKh01N0ajTJtCXK5R+ jPsg== X-Gm-Message-State: APjAAAUQklro4tHurWq2D3yPU03ai3yz5egc03kX3kTHkrBGuqEz+XIs QT7kYTR8cqI1xJERwISdY6Kkt+Jr/cYuP1YseefTKw== X-Google-Smtp-Source: APXvYqwfhmkuQ3K22hYcRkCOlEFPEw9qgU3YRMBjW3CG9Yuk+ek1oqXWKsbNqkZQBQzVDCnoEwkSWILGRpBU8BTNRKM= X-Received: by 2002:a37:48f:: with SMTP id 137mr3663089qke.25.1576080352362; Wed, 11 Dec 2019 08:05:52 -0800 (PST) MIME-Version: 1.0 References: <20191105105456.7xbhtistnbp272lj@sirius.home.kraxel.org> <20191106124101.fsfxibdkypo4rswv@sirius.home.kraxel.org> <72712fe048af1489368f7416faa92c45@hostfission.com> <20191211092625.jzqx2ukphhggwavo@sirius.home.kraxel.org> In-Reply-To: <20191211092625.jzqx2ukphhggwavo@sirius.home.kraxel.org> From: Enrico Granata Date: Wed, 11 Dec 2019 08:05:40 -0800 Message-ID: Subject: Re: [virtio-dev] Re: guest / host buffer sharing ... To: Gerd Hoffmann Cc: David Stevens , Dylan Reid , Tomasz Figa , Zach Reizner , Geoffrey McRae , Keiichi Watanabe , Dmitry Morozov , Alexandre Courbot , Alex Lau , =?UTF-8?Q?St=C3=A9phane_Marchesin?= , Pawel Osciak , Hans Verkuil , Daniel Vetter , Gurchetan Singh , Linux Media Mailing List , virtio-dev@lists.oasis-open.org, qemu-devel 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, Dec 11, 2019 at 1:26 AM Gerd Hoffmann wrote: > > Hi, > > > None of the proposals directly address the use case of sharing host > > allocated buffers between devices, but I think they can be extended to > > support it. Host buffers can be identified by the following tuple: > > (transport type enum, transport specific device address, shmid, > > offset). I think this is sufficient even for host-allocated buffers > > that aren't visible to the guest (e.g. protected memory, vram), since > > they can still be given address space in some shared memory region, > > even if those addresses are actually inaccessible to the guest. At > > this point, the host buffer identifier can simply be passed in place > > of the guest ram scatterlist with either proposed buffer sharing > > mechanism. > > > I think the main question here is whether or not the complexity of > > generic buffers and a buffer sharing device is worth it compared to > > the more implicit definition of buffers. > > Here are two issues mixed up. First is, whenever we'll go define a > buffer sharing device or not. Second is how we are going to address > buffers. > > I think defining (and addressing) buffers implicitly is a bad idea. > First the addressing is non-trivial, especially with the "transport > specific device address" in the tuple. Second I think it is a bad idea > from the security point of view. When explicitly exporting buffers it > is easy to restrict access to the actual exports. > Strong +1 to the above. There are definitely use cases of interest where it makes sense to be able to attach security attributes to buffers. Having an explicit interface that can handle all of this, instead of duplicating logic in several subsystems, seems a worthy endeavor to me. > Instead of using a dedicated buffer sharing device we can also use > virtio-gpu (or any other driver which supports dma-buf exports) to > manage buffers. virtio-gpu would create an identifier when exporting a > buffer (dma-buf exports inside the guest), attach the identifier to the > dma-buf so other drivers importing the buffer can see and use it. Maybe > add an ioctl to query, so guest userspace can query the identifier too. > Also send the identifier to the host so it can also be used on the host > side to lookup and access the buffer. > > With no central instance (buffer sharing device) being there managing > the buffer identifiers I think using uuids as identifiers would be a > good idea, to avoid clashes. Also good for security because it's pretty > much impossible to guess buffer identifiers then. > > 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 > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-6490-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 02F35985E09 for ; Wed, 11 Dec 2019 16:05:54 +0000 (UTC) MIME-Version: 1.0 References: <20191105105456.7xbhtistnbp272lj@sirius.home.kraxel.org> <20191106124101.fsfxibdkypo4rswv@sirius.home.kraxel.org> <72712fe048af1489368f7416faa92c45@hostfission.com> <20191211092625.jzqx2ukphhggwavo@sirius.home.kraxel.org> In-Reply-To: <20191211092625.jzqx2ukphhggwavo@sirius.home.kraxel.org> From: Enrico Granata Date: Wed, 11 Dec 2019 08:05:40 -0800 Message-ID: Subject: Re: [virtio-dev] Re: guest / host buffer sharing ... Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To: Gerd Hoffmann Cc: David Stevens , Dylan Reid , Tomasz Figa , Zach Reizner , Geoffrey McRae , Keiichi Watanabe , Dmitry Morozov , Alexandre Courbot , Alex Lau , =?UTF-8?Q?St=C3=A9phane_Marchesin?= , Pawel Osciak , Hans Verkuil , Daniel Vetter , Gurchetan Singh , Linux Media Mailing List , virtio-dev@lists.oasis-open.org, qemu-devel List-ID: On Wed, Dec 11, 2019 at 1:26 AM Gerd Hoffmann wrote: > > Hi, > > > None of the proposals directly address the use case of sharing host > > allocated buffers between devices, but I think they can be extended to > > support it. Host buffers can be identified by the following tuple: > > (transport type enum, transport specific device address, shmid, > > offset). I think this is sufficient even for host-allocated buffers > > that aren't visible to the guest (e.g. protected memory, vram), since > > they can still be given address space in some shared memory region, > > even if those addresses are actually inaccessible to the guest. At > > this point, the host buffer identifier can simply be passed in place > > of the guest ram scatterlist with either proposed buffer sharing > > mechanism. > > > I think the main question here is whether or not the complexity of > > generic buffers and a buffer sharing device is worth it compared to > > the more implicit definition of buffers. > > Here are two issues mixed up. First is, whenever we'll go define a > buffer sharing device or not. Second is how we are going to address > buffers. > > I think defining (and addressing) buffers implicitly is a bad idea. > First the addressing is non-trivial, especially with the "transport > specific device address" in the tuple. Second I think it is a bad idea > from the security point of view. When explicitly exporting buffers it > is easy to restrict access to the actual exports. > Strong +1 to the above. There are definitely use cases of interest where it makes sense to be able to attach security attributes to buffers. Having an explicit interface that can handle all of this, instead of duplicating logic in several subsystems, seems a worthy endeavor to me. > Instead of using a dedicated buffer sharing device we can also use > virtio-gpu (or any other driver which supports dma-buf exports) to > manage buffers. virtio-gpu would create an identifier when exporting a > buffer (dma-buf exports inside the guest), attach the identifier to the > dma-buf so other drivers importing the buffer can see and use it. Maybe > add an ioctl to query, so guest userspace can query the identifier too. > Also send the identifier to the host so it can also be used on the host > side to lookup and access the buffer. > > With no central instance (buffer sharing device) being there managing > the buffer identifiers I think using uuids as identifiers would be a > good idea, to avoid clashes. Also good for security because it's pretty > much impossible to guess buffer identifiers then. > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org