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_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 54178C3279B for ; Fri, 6 Jul 2018 04:01:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0AB17240B0 for ; Fri, 6 Jul 2018 04:01:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="U5rRXiAX" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0AB17240B0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752941AbeGFEBA (ORCPT ); Fri, 6 Jul 2018 00:01:00 -0400 Received: from mail-qk0-f195.google.com ([209.85.220.195]:43043 "EHLO mail-qk0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750711AbeGFEA5 (ORCPT ); Fri, 6 Jul 2018 00:00:57 -0400 Received: by mail-qk0-f195.google.com with SMTP id z74-v6so5655590qkb.10; Thu, 05 Jul 2018 21:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ug85XCSBHqlXAm2gwMboy1aVaUcB35k42N7CpvogDsA=; b=U5rRXiAXODpauiR4fzP09lI3sWGlXHryEEY73G/axAtXQ4hYvbsBbC0zwbd5zQnNAv uK/qbYPLvLtg3JRuU171n/vxSg2KdDKoQ+7O4kALzypF8qmF557bpK/I/rL3KEy6v4Rq U/dzd9JATBtiuQLjTQYSP1ilnWluv1Jh3dr2MkRrxRhUnD7csjk5ZzOe4uslF0XPbjJh lxQZ4o/SeMBkEeK92IyZDowDW/5m/B+rw1CM40/KQOl5XOrQlnPyQ6ltOIAij4qzD/53 vbajKbg55oD4MsIiVZxtGPDUmEIqV6ZIORr6R7TeuLrbh5LibMiETMhDvAARACN/soiI oA4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ug85XCSBHqlXAm2gwMboy1aVaUcB35k42N7CpvogDsA=; b=cf+2KuVGfi/FI4YuZ1yeq4drlQK3Ry+fmoln4fkXNS3FjR65cHeyuS9PIz+V9+3DZV twXEsjOAT/ypMPSjb5R8UK/iIe/YvkRC/N5243i8iz8GfpNSZbClTIT7FEIcrgM9IGhL 32XOWMt7Hr1PTCC0p3qRpjEO6Wu1ROg+jqbnXkN4xgmykC156jrtbQrDhXAfv76KBDu8 7bjCGteJmpMfPU3dbApRH8BRa4Fbdrmki+093TW8W0vY7j/GIZZr7NlZNBwc4tpHz++a BbNgNPrqyUcK9NVZ6oI7M/ifJhL8JTlJyUeOJhR6bFNKNcxaYyCrRtPF+8v3oiQVVzKZ S99w== X-Gm-Message-State: APt69E0TcGsk1/ltDaULvwKczNOgCTT506P0ry9mZFY0Ah+ADZ2xcqgc 1Pcs7PP3TLwYlhMOSQnEXQWDiF4b9uGYidE+dVo= X-Google-Smtp-Source: AAOMgpf8DsnCwSO9OdQVOBWFITw5h2T98NJy74ZNoCW6nDoI+YqEJT2Yzc5xDK0Msktcg9mHk4xl7yM6pgHnuARcqgc= X-Received: by 2002:a37:56c7:: with SMTP id k190-v6mr7065484qkb.29.1530849656161; Thu, 05 Jul 2018 21:00:56 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:1e87:0:0:0:0:0 with HTTP; Thu, 5 Jul 2018 21:00:55 -0700 (PDT) In-Reply-To: <20180704080005.juutrwri4kxm7yim@sirius.home.kraxel.org> References: <20180703075359.30349-1-kraxel@redhat.com> <20180703083757.GG7880@phenom.ffwll.local> <20180704055338.n3b7oexltaejqmcd@sirius.home.kraxel.org> <9818b301-9c9d-c703-d4fe-7c2d4d43ed66@collabora.com> <20180704080005.juutrwri4kxm7yim@sirius.home.kraxel.org> From: Dave Airlie Date: Fri, 6 Jul 2018 14:00:55 +1000 Message-ID: Subject: Re: [PATCH v6] Add udmabuf misc device To: Gerd Hoffmann Cc: Tomeu Vizoso , Daniel Stone , Jonathan Corbet , David Airlie , "open list:DOCUMENTATION" , open list , dri-devel , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Laurent Pinchart , "open list:KERNEL SELFTEST FRAMEWORK" , Shuah Khan , "open list:DMA BUFFER SHARING FRAMEWORK" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4 July 2018 at 18:00, Gerd Hoffmann wrote: > On Wed, Jul 04, 2018 at 09:26:39AM +0200, Tomeu Vizoso wrote: >> On 07/04/2018 07:53 AM, Gerd Hoffmann wrote: >> > On Tue, Jul 03, 2018 at 10:37:57AM +0200, Daniel Vetter wrote: >> > > On Tue, Jul 03, 2018 at 09:53:58AM +0200, Gerd Hoffmann wrote: >> > > > A driver to let userspace turn memfd regions into dma-bufs. >> > > > >> > > > Use case: Allows qemu create dmabufs for the vga framebuffer or >> > > > virtio-gpu ressources. Then they can be passed around to display >> > > > those guest things on the host. To spice client for classic full >> > > > framebuffer display, and hopefully some day to wayland server for >> > > > seamless guest window display. >> > > > >> > > > qemu test branch: >> > > > https://git.kraxel.org/cgit/qemu/log/?h=sirius/udmabuf >> > > > >> > > > Cc: David Airlie >> > > > Cc: Tomeu Vizoso >> > > > Cc: Laurent Pinchart >> > > > Cc: Daniel Vetter >> > > > Signed-off-by: Gerd Hoffmann >> > > >> > > I think some ack for a 2nd use-case, like virtio-wl or whatever would be >> > > really cool. To give us some assurance that this is generically useful. >> > >> > Tomeu? Laurent? >> >> Sorry, but I think I will need some help to understand how this could help >> in the virtio-wl case [adding Zach Reizner to CC]. >> >> Any graphics buffers that are allocated with memfd will be shared with the >> compositor via wl_shm, without need for dmabufs. > > Within one machine, yes. Once virtualization is added to the mix things > become more complicated ... > > When using virtio-gpu the guest will allocate graphics buffers from > normal (guest) ram, then register these buffers (which are allowed to be > scattered) with the host as resource. > > qemu can use memfd to allocate guest ram. Now, with the help of > udmabuf, qemu can create a *host* dma-buf for the *guest* graphics > buffer. > > That dma-buf can be used by qemu internally (mmap it to get a linear > mapping of the resource, to avoid copying). It can be passed on to > spice-client, to display the guest framebuffer. > > And I think it could also be quite useful to pass guest wayland windows > to the host compositor, without mapping host-allocated buffers into the > guest, so we don't have do deal with the "find some address space for > the mapping" issue in the first place. There are more things needed to > complete this of course, but it's a building block ... There is a use case where I think we have to deal with the "find some address space" problem. For GL4.4 ARB_buffer_storage and Vulkan memory mangement there is the concept of coherent buffers between GPU and CPU. From the virgl point of view, we'd create a host buffer in GL, and then create a mapping from it on the host that we'd need to present in the guest userspace as a linear buffer. Just in case we think this can solve all our problems :-) Dave. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-qk0-f195.google.com ([209.85.220.195]:43043 "EHLO mail-qk0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750711AbeGFEA5 (ORCPT ); Fri, 6 Jul 2018 00:00:57 -0400 MIME-Version: 1.0 In-Reply-To: <20180704080005.juutrwri4kxm7yim@sirius.home.kraxel.org> References: <20180703075359.30349-1-kraxel@redhat.com> <20180703083757.GG7880@phenom.ffwll.local> <20180704055338.n3b7oexltaejqmcd@sirius.home.kraxel.org> <9818b301-9c9d-c703-d4fe-7c2d4d43ed66@collabora.com> <20180704080005.juutrwri4kxm7yim@sirius.home.kraxel.org> From: Dave Airlie Date: Fri, 6 Jul 2018 14:00:55 +1000 Message-ID: Subject: Re: [PATCH v6] Add udmabuf misc device To: Gerd Hoffmann Cc: Tomeu Vizoso , Daniel Stone , Jonathan Corbet , David Airlie , "open list:DOCUMENTATION" , open list , dri-devel , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Laurent Pinchart , "open list:KERNEL SELFTEST FRAMEWORK" , Shuah Khan , "open list:DMA BUFFER SHARING FRAMEWORK" Content-Type: text/plain; charset="UTF-8" Sender: linux-media-owner@vger.kernel.org List-ID: On 4 July 2018 at 18:00, Gerd Hoffmann wrote: > On Wed, Jul 04, 2018 at 09:26:39AM +0200, Tomeu Vizoso wrote: >> On 07/04/2018 07:53 AM, Gerd Hoffmann wrote: >> > On Tue, Jul 03, 2018 at 10:37:57AM +0200, Daniel Vetter wrote: >> > > On Tue, Jul 03, 2018 at 09:53:58AM +0200, Gerd Hoffmann wrote: >> > > > A driver to let userspace turn memfd regions into dma-bufs. >> > > > >> > > > Use case: Allows qemu create dmabufs for the vga framebuffer or >> > > > virtio-gpu ressources. Then they can be passed around to display >> > > > those guest things on the host. To spice client for classic full >> > > > framebuffer display, and hopefully some day to wayland server for >> > > > seamless guest window display. >> > > > >> > > > qemu test branch: >> > > > https://git.kraxel.org/cgit/qemu/log/?h=sirius/udmabuf >> > > > >> > > > Cc: David Airlie >> > > > Cc: Tomeu Vizoso >> > > > Cc: Laurent Pinchart >> > > > Cc: Daniel Vetter >> > > > Signed-off-by: Gerd Hoffmann >> > > >> > > I think some ack for a 2nd use-case, like virtio-wl or whatever would be >> > > really cool. To give us some assurance that this is generically useful. >> > >> > Tomeu? Laurent? >> >> Sorry, but I think I will need some help to understand how this could help >> in the virtio-wl case [adding Zach Reizner to CC]. >> >> Any graphics buffers that are allocated with memfd will be shared with the >> compositor via wl_shm, without need for dmabufs. > > Within one machine, yes. Once virtualization is added to the mix things > become more complicated ... > > When using virtio-gpu the guest will allocate graphics buffers from > normal (guest) ram, then register these buffers (which are allowed to be > scattered) with the host as resource. > > qemu can use memfd to allocate guest ram. Now, with the help of > udmabuf, qemu can create a *host* dma-buf for the *guest* graphics > buffer. > > That dma-buf can be used by qemu internally (mmap it to get a linear > mapping of the resource, to avoid copying). It can be passed on to > spice-client, to display the guest framebuffer. > > And I think it could also be quite useful to pass guest wayland windows > to the host compositor, without mapping host-allocated buffers into the > guest, so we don't have do deal with the "find some address space for > the mapping" issue in the first place. There are more things needed to > complete this of course, but it's a building block ... There is a use case where I think we have to deal with the "find some address space" problem. For GL4.4 ARB_buffer_storage and Vulkan memory mangement there is the concept of coherent buffers between GPU and CPU. From the virgl point of view, we'd create a host buffer in GL, and then create a mapping from it on the host that we'd need to present in the guest userspace as a linear buffer. Just in case we think this can solve all our problems :-) Dave. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on archive.lwn.net X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by archive.lwn.net (Postfix) with ESMTP id AD50D7D048 for ; Fri, 6 Jul 2018 04:00:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750860AbeGFEA7 (ORCPT ); Fri, 6 Jul 2018 00:00:59 -0400 Received: from mail-qk0-f195.google.com ([209.85.220.195]:43043 "EHLO mail-qk0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750711AbeGFEA5 (ORCPT ); Fri, 6 Jul 2018 00:00:57 -0400 Received: by mail-qk0-f195.google.com with SMTP id z74-v6so5655590qkb.10; Thu, 05 Jul 2018 21:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ug85XCSBHqlXAm2gwMboy1aVaUcB35k42N7CpvogDsA=; b=U5rRXiAXODpauiR4fzP09lI3sWGlXHryEEY73G/axAtXQ4hYvbsBbC0zwbd5zQnNAv uK/qbYPLvLtg3JRuU171n/vxSg2KdDKoQ+7O4kALzypF8qmF557bpK/I/rL3KEy6v4Rq U/dzd9JATBtiuQLjTQYSP1ilnWluv1Jh3dr2MkRrxRhUnD7csjk5ZzOe4uslF0XPbjJh lxQZ4o/SeMBkEeK92IyZDowDW/5m/B+rw1CM40/KQOl5XOrQlnPyQ6ltOIAij4qzD/53 vbajKbg55oD4MsIiVZxtGPDUmEIqV6ZIORr6R7TeuLrbh5LibMiETMhDvAARACN/soiI oA4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ug85XCSBHqlXAm2gwMboy1aVaUcB35k42N7CpvogDsA=; b=cf+2KuVGfi/FI4YuZ1yeq4drlQK3Ry+fmoln4fkXNS3FjR65cHeyuS9PIz+V9+3DZV twXEsjOAT/ypMPSjb5R8UK/iIe/YvkRC/N5243i8iz8GfpNSZbClTIT7FEIcrgM9IGhL 32XOWMt7Hr1PTCC0p3qRpjEO6Wu1ROg+jqbnXkN4xgmykC156jrtbQrDhXAfv76KBDu8 7bjCGteJmpMfPU3dbApRH8BRa4Fbdrmki+093TW8W0vY7j/GIZZr7NlZNBwc4tpHz++a BbNgNPrqyUcK9NVZ6oI7M/ifJhL8JTlJyUeOJhR6bFNKNcxaYyCrRtPF+8v3oiQVVzKZ S99w== X-Gm-Message-State: APt69E0TcGsk1/ltDaULvwKczNOgCTT506P0ry9mZFY0Ah+ADZ2xcqgc 1Pcs7PP3TLwYlhMOSQnEXQWDiF4b9uGYidE+dVo= X-Google-Smtp-Source: AAOMgpf8DsnCwSO9OdQVOBWFITw5h2T98NJy74ZNoCW6nDoI+YqEJT2Yzc5xDK0Msktcg9mHk4xl7yM6pgHnuARcqgc= X-Received: by 2002:a37:56c7:: with SMTP id k190-v6mr7065484qkb.29.1530849656161; Thu, 05 Jul 2018 21:00:56 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:1e87:0:0:0:0:0 with HTTP; Thu, 5 Jul 2018 21:00:55 -0700 (PDT) In-Reply-To: <20180704080005.juutrwri4kxm7yim@sirius.home.kraxel.org> References: <20180703075359.30349-1-kraxel@redhat.com> <20180703083757.GG7880@phenom.ffwll.local> <20180704055338.n3b7oexltaejqmcd@sirius.home.kraxel.org> <9818b301-9c9d-c703-d4fe-7c2d4d43ed66@collabora.com> <20180704080005.juutrwri4kxm7yim@sirius.home.kraxel.org> From: Dave Airlie Date: Fri, 6 Jul 2018 14:00:55 +1000 Message-ID: Subject: Re: [PATCH v6] Add udmabuf misc device To: Gerd Hoffmann Cc: Tomeu Vizoso , Daniel Stone , Jonathan Corbet , David Airlie , "open list:DOCUMENTATION" , open list , dri-devel , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Laurent Pinchart , "open list:KERNEL SELFTEST FRAMEWORK" , Shuah Khan , "open list:DMA BUFFER SHARING FRAMEWORK" Content-Type: text/plain; charset="UTF-8" Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On 4 July 2018 at 18:00, Gerd Hoffmann wrote: > On Wed, Jul 04, 2018 at 09:26:39AM +0200, Tomeu Vizoso wrote: >> On 07/04/2018 07:53 AM, Gerd Hoffmann wrote: >> > On Tue, Jul 03, 2018 at 10:37:57AM +0200, Daniel Vetter wrote: >> > > On Tue, Jul 03, 2018 at 09:53:58AM +0200, Gerd Hoffmann wrote: >> > > > A driver to let userspace turn memfd regions into dma-bufs. >> > > > >> > > > Use case: Allows qemu create dmabufs for the vga framebuffer or >> > > > virtio-gpu ressources. Then they can be passed around to display >> > > > those guest things on the host. To spice client for classic full >> > > > framebuffer display, and hopefully some day to wayland server for >> > > > seamless guest window display. >> > > > >> > > > qemu test branch: >> > > > https://git.kraxel.org/cgit/qemu/log/?h=sirius/udmabuf >> > > > >> > > > Cc: David Airlie >> > > > Cc: Tomeu Vizoso >> > > > Cc: Laurent Pinchart >> > > > Cc: Daniel Vetter >> > > > Signed-off-by: Gerd Hoffmann >> > > >> > > I think some ack for a 2nd use-case, like virtio-wl or whatever would be >> > > really cool. To give us some assurance that this is generically useful. >> > >> > Tomeu? Laurent? >> >> Sorry, but I think I will need some help to understand how this could help >> in the virtio-wl case [adding Zach Reizner to CC]. >> >> Any graphics buffers that are allocated with memfd will be shared with the >> compositor via wl_shm, without need for dmabufs. > > Within one machine, yes. Once virtualization is added to the mix things > become more complicated ... > > When using virtio-gpu the guest will allocate graphics buffers from > normal (guest) ram, then register these buffers (which are allowed to be > scattered) with the host as resource. > > qemu can use memfd to allocate guest ram. Now, with the help of > udmabuf, qemu can create a *host* dma-buf for the *guest* graphics > buffer. > > That dma-buf can be used by qemu internally (mmap it to get a linear > mapping of the resource, to avoid copying). It can be passed on to > spice-client, to display the guest framebuffer. > > And I think it could also be quite useful to pass guest wayland windows > to the host compositor, without mapping host-allocated buffers into the > guest, so we don't have do deal with the "find some address space for > the mapping" issue in the first place. There are more things needed to > complete this of course, but it's a building block ... There is a use case where I think we have to deal with the "find some address space" problem. For GL4.4 ARB_buffer_storage and Vulkan memory mangement there is the concept of coherent buffers between GPU and CPU. From the virgl point of view, we'd create a host buffer in GL, and then create a mapping from it on the host that we'd need to present in the guest userspace as a linear buffer. Just in case we think this can solve all our problems :-) Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: airlied at gmail.com (Dave Airlie) Date: Fri, 6 Jul 2018 14:00:55 +1000 Subject: [PATCH v6] Add udmabuf misc device In-Reply-To: <20180704080005.juutrwri4kxm7yim@sirius.home.kraxel.org> References: <20180703075359.30349-1-kraxel@redhat.com> <20180703083757.GG7880@phenom.ffwll.local> <20180704055338.n3b7oexltaejqmcd@sirius.home.kraxel.org> <9818b301-9c9d-c703-d4fe-7c2d4d43ed66@collabora.com> <20180704080005.juutrwri4kxm7yim@sirius.home.kraxel.org> Message-ID: On 4 July 2018 at 18:00, Gerd Hoffmann wrote: > On Wed, Jul 04, 2018 at 09:26:39AM +0200, Tomeu Vizoso wrote: >> On 07/04/2018 07:53 AM, Gerd Hoffmann wrote: >> > On Tue, Jul 03, 2018 at 10:37:57AM +0200, Daniel Vetter wrote: >> > > On Tue, Jul 03, 2018 at 09:53:58AM +0200, Gerd Hoffmann wrote: >> > > > A driver to let userspace turn memfd regions into dma-bufs. >> > > > >> > > > Use case: Allows qemu create dmabufs for the vga framebuffer or >> > > > virtio-gpu ressources. Then they can be passed around to display >> > > > those guest things on the host. To spice client for classic full >> > > > framebuffer display, and hopefully some day to wayland server for >> > > > seamless guest window display. >> > > > >> > > > qemu test branch: >> > > > https://git.kraxel.org/cgit/qemu/log/?h=sirius/udmabuf >> > > > >> > > > Cc: David Airlie >> > > > Cc: Tomeu Vizoso >> > > > Cc: Laurent Pinchart >> > > > Cc: Daniel Vetter >> > > > Signed-off-by: Gerd Hoffmann >> > > >> > > I think some ack for a 2nd use-case, like virtio-wl or whatever would be >> > > really cool. To give us some assurance that this is generically useful. >> > >> > Tomeu? Laurent? >> >> Sorry, but I think I will need some help to understand how this could help >> in the virtio-wl case [adding Zach Reizner to CC]. >> >> Any graphics buffers that are allocated with memfd will be shared with the >> compositor via wl_shm, without need for dmabufs. > > Within one machine, yes. Once virtualization is added to the mix things > become more complicated ... > > When using virtio-gpu the guest will allocate graphics buffers from > normal (guest) ram, then register these buffers (which are allowed to be > scattered) with the host as resource. > > qemu can use memfd to allocate guest ram. Now, with the help of > udmabuf, qemu can create a *host* dma-buf for the *guest* graphics > buffer. > > That dma-buf can be used by qemu internally (mmap it to get a linear > mapping of the resource, to avoid copying). It can be passed on to > spice-client, to display the guest framebuffer. > > And I think it could also be quite useful to pass guest wayland windows > to the host compositor, without mapping host-allocated buffers into the > guest, so we don't have do deal with the "find some address space for > the mapping" issue in the first place. There are more things needed to > complete this of course, but it's a building block ... There is a use case where I think we have to deal with the "find some address space" problem. For GL4.4 ARB_buffer_storage and Vulkan memory mangement there is the concept of coherent buffers between GPU and CPU. From the virgl point of view, we'd create a host buffer in GL, and then create a mapping from it on the host that we'd need to present in the guest userspace as a linear buffer. Just in case we think this can solve all our problems :-) Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: airlied@gmail.com (Dave Airlie) Date: Fri, 6 Jul 2018 14:00:55 +1000 Subject: [PATCH v6] Add udmabuf misc device In-Reply-To: <20180704080005.juutrwri4kxm7yim@sirius.home.kraxel.org> References: <20180703075359.30349-1-kraxel@redhat.com> <20180703083757.GG7880@phenom.ffwll.local> <20180704055338.n3b7oexltaejqmcd@sirius.home.kraxel.org> <9818b301-9c9d-c703-d4fe-7c2d4d43ed66@collabora.com> <20180704080005.juutrwri4kxm7yim@sirius.home.kraxel.org> Message-ID: Content-Type: text/plain; charset="UTF-8" Message-ID: <20180706040055.Xc2aQwbC9s-W5z5YzucixAIg5MhD0R-ipthDKjIT7co@z> On 4 July 2018@18:00, Gerd Hoffmann wrote: > On Wed, Jul 04, 2018@09:26:39AM +0200, Tomeu Vizoso wrote: >> On 07/04/2018 07:53 AM, Gerd Hoffmann wrote: >> > On Tue, Jul 03, 2018@10:37:57AM +0200, Daniel Vetter wrote: >> > > On Tue, Jul 03, 2018@09:53:58AM +0200, Gerd Hoffmann wrote: >> > > > A driver to let userspace turn memfd regions into dma-bufs. >> > > > >> > > > Use case: Allows qemu create dmabufs for the vga framebuffer or >> > > > virtio-gpu ressources. Then they can be passed around to display >> > > > those guest things on the host. To spice client for classic full >> > > > framebuffer display, and hopefully some day to wayland server for >> > > > seamless guest window display. >> > > > >> > > > qemu test branch: >> > > > https://git.kraxel.org/cgit/qemu/log/?h=sirius/udmabuf >> > > > >> > > > Cc: David Airlie >> > > > Cc: Tomeu Vizoso >> > > > Cc: Laurent Pinchart >> > > > Cc: Daniel Vetter >> > > > Signed-off-by: Gerd Hoffmann >> > > >> > > I think some ack for a 2nd use-case, like virtio-wl or whatever would be >> > > really cool. To give us some assurance that this is generically useful. >> > >> > Tomeu? Laurent? >> >> Sorry, but I think I will need some help to understand how this could help >> in the virtio-wl case [adding Zach Reizner to CC]. >> >> Any graphics buffers that are allocated with memfd will be shared with the >> compositor via wl_shm, without need for dmabufs. > > Within one machine, yes. Once virtualization is added to the mix things > become more complicated ... > > When using virtio-gpu the guest will allocate graphics buffers from > normal (guest) ram, then register these buffers (which are allowed to be > scattered) with the host as resource. > > qemu can use memfd to allocate guest ram. Now, with the help of > udmabuf, qemu can create a *host* dma-buf for the *guest* graphics > buffer. > > That dma-buf can be used by qemu internally (mmap it to get a linear > mapping of the resource, to avoid copying). It can be passed on to > spice-client, to display the guest framebuffer. > > And I think it could also be quite useful to pass guest wayland windows > to the host compositor, without mapping host-allocated buffers into the > guest, so we don't have do deal with the "find some address space for > the mapping" issue in the first place. There are more things needed to > complete this of course, but it's a building block ... There is a use case where I think we have to deal with the "find some address space" problem. For GL4.4 ARB_buffer_storage and Vulkan memory mangement there is the concept of coherent buffers between GPU and CPU. From the virgl point of view, we'd create a host buffer in GL, and then create a mapping from it on the host that we'd need to present in the guest userspace as a linear buffer. Just in case we think this can solve all our problems :-) Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Airlie Subject: Re: [PATCH v6] Add udmabuf misc device Date: Fri, 6 Jul 2018 14:00:55 +1000 Message-ID: References: <20180703075359.30349-1-kraxel@redhat.com> <20180703083757.GG7880@phenom.ffwll.local> <20180704055338.n3b7oexltaejqmcd@sirius.home.kraxel.org> <9818b301-9c9d-c703-d4fe-7c2d4d43ed66@collabora.com> <20180704080005.juutrwri4kxm7yim@sirius.home.kraxel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mail-qk0-x242.google.com (mail-qk0-x242.google.com [IPv6:2607:f8b0:400d:c09::242]) by gabe.freedesktop.org (Postfix) with ESMTPS id 0D3AF6E04C for ; Fri, 6 Jul 2018 04:00:57 +0000 (UTC) Received: by mail-qk0-x242.google.com with SMTP id u21-v6so5668305qku.2 for ; Thu, 05 Jul 2018 21:00:57 -0700 (PDT) In-Reply-To: <20180704080005.juutrwri4kxm7yim@sirius.home.kraxel.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Gerd Hoffmann Cc: Daniel Stone , Tomeu Vizoso , "open list:DOCUMENTATION" , David Airlie , Jonathan Corbet , open list , dri-devel , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Laurent Pinchart , "open list:KERNEL SELFTEST FRAMEWORK" , Shuah Khan , "open list:DMA BUFFER SHARING FRAMEWORK" List-Id: dri-devel@lists.freedesktop.org T24gNCBKdWx5IDIwMTggYXQgMTg6MDAsIEdlcmQgSG9mZm1hbm4gPGtyYXhlbEByZWRoYXQuY29t PiB3cm90ZToKPiBPbiBXZWQsIEp1bCAwNCwgMjAxOCBhdCAwOToyNjozOUFNICswMjAwLCBUb21l dSBWaXpvc28gd3JvdGU6Cj4+IE9uIDA3LzA0LzIwMTggMDc6NTMgQU0sIEdlcmQgSG9mZm1hbm4g d3JvdGU6Cj4+ID4gT24gVHVlLCBKdWwgMDMsIDIwMTggYXQgMTA6Mzc6NTdBTSArMDIwMCwgRGFu aWVsIFZldHRlciB3cm90ZToKPj4gPiA+IE9uIFR1ZSwgSnVsIDAzLCAyMDE4IGF0IDA5OjUzOjU4 QU0gKzAyMDAsIEdlcmQgSG9mZm1hbm4gd3JvdGU6Cj4+ID4gPiA+IEEgZHJpdmVyIHRvIGxldCB1 c2Vyc3BhY2UgdHVybiBtZW1mZCByZWdpb25zIGludG8gZG1hLWJ1ZnMuCj4+ID4gPiA+Cj4+ID4g PiA+IFVzZSBjYXNlOiAgQWxsb3dzIHFlbXUgY3JlYXRlIGRtYWJ1ZnMgZm9yIHRoZSB2Z2EgZnJh bWVidWZmZXIgb3IKPj4gPiA+ID4gdmlydGlvLWdwdSByZXNzb3VyY2VzLiAgVGhlbiB0aGV5IGNh biBiZSBwYXNzZWQgYXJvdW5kIHRvIGRpc3BsYXkKPj4gPiA+ID4gdGhvc2UgZ3Vlc3QgdGhpbmdz IG9uIHRoZSBob3N0LiAgVG8gc3BpY2UgY2xpZW50IGZvciBjbGFzc2ljIGZ1bGwKPj4gPiA+ID4g ZnJhbWVidWZmZXIgZGlzcGxheSwgYW5kIGhvcGVmdWxseSBzb21lIGRheSB0byB3YXlsYW5kIHNl cnZlciBmb3IKPj4gPiA+ID4gc2VhbWxlc3MgZ3Vlc3Qgd2luZG93IGRpc3BsYXkuCj4+ID4gPiA+ Cj4+ID4gPiA+IHFlbXUgdGVzdCBicmFuY2g6Cj4+ID4gPiA+ICAgIGh0dHBzOi8vZ2l0LmtyYXhl bC5vcmcvY2dpdC9xZW11L2xvZy8/aD1zaXJpdXMvdWRtYWJ1Zgo+PiA+ID4gPgo+PiA+ID4gPiBD YzogRGF2aWQgQWlybGllIDxhaXJsaWVkQGxpbnV4LmllPgo+PiA+ID4gPiBDYzogVG9tZXUgVml6 b3NvIDx0b21ldS52aXpvc29AY29sbGFib3JhLmNvbT4KPj4gPiA+ID4gQ2M6IExhdXJlbnQgUGlu Y2hhcnQgPGxhdXJlbnQucGluY2hhcnRAaWRlYXNvbmJvYXJkLmNvbT4KPj4gPiA+ID4gQ2M6IERh bmllbCBWZXR0ZXIgPGRhbmllbEBmZndsbC5jaD4KPj4gPiA+ID4gU2lnbmVkLW9mZi1ieTogR2Vy ZCBIb2ZmbWFubiA8a3JheGVsQHJlZGhhdC5jb20+Cj4+ID4gPgo+PiA+ID4gSSB0aGluayBzb21l IGFjayBmb3IgYSAybmQgdXNlLWNhc2UsIGxpa2UgdmlydGlvLXdsIG9yIHdoYXRldmVyIHdvdWxk IGJlCj4+ID4gPiByZWFsbHkgY29vbC4gVG8gZ2l2ZSB1cyBzb21lIGFzc3VyYW5jZSB0aGF0IHRo aXMgaXMgZ2VuZXJpY2FsbHkgdXNlZnVsLgo+PiA+Cj4+ID4gVG9tZXU/ICBMYXVyZW50Pwo+Pgo+ PiBTb3JyeSwgYnV0IEkgdGhpbmsgSSB3aWxsIG5lZWQgc29tZSBoZWxwIHRvIHVuZGVyc3RhbmQg aG93IHRoaXMgY291bGQgaGVscAo+PiBpbiB0aGUgdmlydGlvLXdsIGNhc2UgW2FkZGluZyBaYWNo IFJlaXpuZXIgdG8gQ0NdLgo+Pgo+PiBBbnkgZ3JhcGhpY3MgYnVmZmVycyB0aGF0IGFyZSBhbGxv Y2F0ZWQgd2l0aCBtZW1mZCB3aWxsIGJlIHNoYXJlZCB3aXRoIHRoZQo+PiBjb21wb3NpdG9yIHZp YSB3bF9zaG0sIHdpdGhvdXQgbmVlZCBmb3IgZG1hYnVmcy4KPgo+IFdpdGhpbiBvbmUgbWFjaGlu ZSwgeWVzLiAgT25jZSB2aXJ0dWFsaXphdGlvbiBpcyBhZGRlZCB0byB0aGUgbWl4IHRoaW5ncwo+ IGJlY29tZSBtb3JlIGNvbXBsaWNhdGVkIC4uLgo+Cj4gV2hlbiB1c2luZyB2aXJ0aW8tZ3B1IHRo ZSBndWVzdCB3aWxsIGFsbG9jYXRlIGdyYXBoaWNzIGJ1ZmZlcnMgZnJvbQo+IG5vcm1hbCAoZ3Vl c3QpIHJhbSwgdGhlbiByZWdpc3RlciB0aGVzZSBidWZmZXJzICh3aGljaCBhcmUgYWxsb3dlZCB0 byBiZQo+IHNjYXR0ZXJlZCkgd2l0aCB0aGUgaG9zdCBhcyByZXNvdXJjZS4KPgo+IHFlbXUgY2Fu IHVzZSBtZW1mZCB0byBhbGxvY2F0ZSBndWVzdCByYW0uICBOb3csIHdpdGggdGhlIGhlbHAgb2YK PiB1ZG1hYnVmLCBxZW11IGNhbiBjcmVhdGUgYSAqaG9zdCogZG1hLWJ1ZiBmb3IgdGhlICpndWVz dCogZ3JhcGhpY3MKPiBidWZmZXIuCj4KPiBUaGF0IGRtYS1idWYgY2FuIGJlIHVzZWQgYnkgcWVt dSBpbnRlcm5hbGx5IChtbWFwIGl0IHRvIGdldCBhIGxpbmVhcgo+IG1hcHBpbmcgb2YgdGhlIHJl c291cmNlLCB0byBhdm9pZCBjb3B5aW5nKS4gIEl0IGNhbiBiZSBwYXNzZWQgb24gdG8KPiBzcGlj ZS1jbGllbnQsIHRvIGRpc3BsYXkgdGhlIGd1ZXN0IGZyYW1lYnVmZmVyLgo+Cj4gQW5kIEkgdGhp bmsgaXQgY291bGQgYWxzbyBiZSBxdWl0ZSB1c2VmdWwgdG8gcGFzcyBndWVzdCB3YXlsYW5kIHdp bmRvd3MKPiB0byB0aGUgaG9zdCBjb21wb3NpdG9yLCB3aXRob3V0IG1hcHBpbmcgaG9zdC1hbGxv Y2F0ZWQgYnVmZmVycyBpbnRvIHRoZQo+IGd1ZXN0LCBzbyB3ZSBkb24ndCBoYXZlIGRvIGRlYWwg d2l0aCB0aGUgImZpbmQgc29tZSBhZGRyZXNzIHNwYWNlIGZvcgo+IHRoZSBtYXBwaW5nIiBpc3N1 ZSBpbiB0aGUgZmlyc3QgcGxhY2UuICBUaGVyZSBhcmUgbW9yZSB0aGluZ3MgbmVlZGVkIHRvCj4g Y29tcGxldGUgdGhpcyBvZiBjb3Vyc2UsIGJ1dCBpdCdzIGEgYnVpbGRpbmcgYmxvY2sgLi4uCgpU aGVyZSBpcyBhIHVzZSBjYXNlIHdoZXJlIEkgdGhpbmsgd2UgaGF2ZSB0byBkZWFsIHdpdGggdGhl ICJmaW5kIHNvbWUgYWRkcmVzcwpzcGFjZSIgcHJvYmxlbS4gRm9yIEdMNC40IEFSQl9idWZmZXJf c3RvcmFnZSBhbmQgVnVsa2FuIG1lbW9yeSBtYW5nZW1lbnQKdGhlcmUgaXMgdGhlIGNvbmNlcHQg b2YgY29oZXJlbnQgYnVmZmVycyBiZXR3ZWVuIEdQVSBhbmQgQ1BVLiBGcm9tIHRoZQp2aXJnbCBw b2ludCBvZiB2aWV3LCB3ZSdkIGNyZWF0ZSBhIGhvc3QgYnVmZmVyIGluIEdMLCBhbmQgdGhlbiBj cmVhdGUKYSBtYXBwaW5nIGZyb20KaXQgb24gdGhlIGhvc3QgdGhhdCB3ZSdkIG5lZWQgdG8gcHJl c2VudCBpbiB0aGUgZ3Vlc3QgdXNlcnNwYWNlIGFzIGEKbGluZWFyIGJ1ZmZlci4KCkp1c3QgaW4g Y2FzZSB3ZSB0aGluayB0aGlzIGNhbiBzb2x2ZSBhbGwgb3VyIHByb2JsZW1zIDotKQoKRGF2ZS4K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg==