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.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED,USER_AGENT_NEOMUTT 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 72494C3279B for ; Wed, 4 Jul 2018 08:00:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 34D7D21C3B for ; Wed, 4 Jul 2018 08:00:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 34D7D21C3B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.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 S934070AbeGDIAK (ORCPT ); Wed, 4 Jul 2018 04:00:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46008 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934034AbeGDIAH (ORCPT ); Wed, 4 Jul 2018 04:00:07 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EC525C07EFD4; Wed, 4 Jul 2018 08:00:06 +0000 (UTC) Received: from sirius.home.kraxel.org (ovpn-116-220.phx2.redhat.com [10.3.116.220]) by smtp.corp.redhat.com (Postfix) with ESMTP id 31BE860C4E; Wed, 4 Jul 2018 08:00:06 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 1753F17445; Wed, 4 Jul 2018 10:00:05 +0200 (CEST) Date: Wed, 4 Jul 2018 10:00:05 +0200 From: Gerd Hoffmann To: Tomeu Vizoso Cc: dri-devel@lists.freedesktop.org, David Airlie , Laurent Pinchart , Jonathan Corbet , Sumit Semwal , Shuah Khan , "open list:DOCUMENTATION" , open list , "open list:DMA BUFFER SHARING FRAMEWORK" , "moderated list:DMA BUFFER SHARING FRAMEWORK" , "open list:KERNEL SELFTEST FRAMEWORK" , Zach Reizner , Daniel Stone Subject: Re: [PATCH v6] Add udmabuf misc device Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9818b301-9c9d-c703-d4fe-7c2d4d43ed66@collabora.com> User-Agent: NeoMutt/20180622 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Wed, 04 Jul 2018 08:00:07 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 ... cheers, Gerd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx1.redhat.com ([209.132.183.28]:46008 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934034AbeGDIAH (ORCPT ); Wed, 4 Jul 2018 04:00:07 -0400 Date: Wed, 4 Jul 2018 10:00:05 +0200 From: Gerd Hoffmann To: Tomeu Vizoso Cc: dri-devel@lists.freedesktop.org, David Airlie , Laurent Pinchart , Jonathan Corbet , Sumit Semwal , Shuah Khan , "open list:DOCUMENTATION" , open list , "open list:DMA BUFFER SHARING FRAMEWORK" , "moderated list:DMA BUFFER SHARING FRAMEWORK" , "open list:KERNEL SELFTEST FRAMEWORK" , Zach Reizner , Daniel Stone Subject: Re: [PATCH v6] Add udmabuf misc device Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9818b301-9c9d-c703-d4fe-7c2d4d43ed66@collabora.com> Sender: linux-media-owner@vger.kernel.org List-ID: 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 ... cheers, Gerd 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.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI 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 7461E7DF9F for ; Wed, 4 Jul 2018 08:00:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934045AbeGDIAK (ORCPT ); Wed, 4 Jul 2018 04:00:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46008 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934034AbeGDIAH (ORCPT ); Wed, 4 Jul 2018 04:00:07 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EC525C07EFD4; Wed, 4 Jul 2018 08:00:06 +0000 (UTC) Received: from sirius.home.kraxel.org (ovpn-116-220.phx2.redhat.com [10.3.116.220]) by smtp.corp.redhat.com (Postfix) with ESMTP id 31BE860C4E; Wed, 4 Jul 2018 08:00:06 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 1753F17445; Wed, 4 Jul 2018 10:00:05 +0200 (CEST) Date: Wed, 4 Jul 2018 10:00:05 +0200 From: Gerd Hoffmann To: Tomeu Vizoso Cc: dri-devel@lists.freedesktop.org, David Airlie , Laurent Pinchart , Jonathan Corbet , Sumit Semwal , Shuah Khan , "open list:DOCUMENTATION" , open list , "open list:DMA BUFFER SHARING FRAMEWORK" , "moderated list:DMA BUFFER SHARING FRAMEWORK" , "open list:KERNEL SELFTEST FRAMEWORK" , Zach Reizner , Daniel Stone Subject: Re: [PATCH v6] Add udmabuf misc device Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9818b301-9c9d-c703-d4fe-7c2d4d43ed66@collabora.com> User-Agent: NeoMutt/20180622 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Wed, 04 Jul 2018 08:00:07 +0000 (UTC) Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org 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 ... cheers, Gerd -- 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: kraxel at redhat.com (Gerd Hoffmann) Date: Wed, 4 Jul 2018 10:00:05 +0200 Subject: [PATCH v6] Add udmabuf misc device In-Reply-To: <9818b301-9c9d-c703-d4fe-7c2d4d43ed66@collabora.com> 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> Message-ID: <20180704080005.juutrwri4kxm7yim@sirius.home.kraxel.org> 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 ... cheers, Gerd -- 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: kraxel@redhat.com (Gerd Hoffmann) Date: Wed, 4 Jul 2018 10:00:05 +0200 Subject: [PATCH v6] Add udmabuf misc device In-Reply-To: <9818b301-9c9d-c703-d4fe-7c2d4d43ed66@collabora.com> 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> Message-ID: <20180704080005.juutrwri4kxm7yim@sirius.home.kraxel.org> Content-Type: text/plain; charset="UTF-8" Message-ID: <20180704080005.7M4MdyvJkIPGioAoicteJx_wgaLTPIFTwtKIuTCwThE@z> 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 ... cheers, Gerd -- 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: Gerd Hoffmann Subject: Re: [PATCH v6] Add udmabuf misc device Date: Wed, 4 Jul 2018 10:00:05 +0200 Message-ID: <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> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by gabe.freedesktop.org (Postfix) with ESMTPS id BE4626EAEC for ; Wed, 4 Jul 2018 08:00:07 +0000 (UTC) Content-Disposition: inline In-Reply-To: <9818b301-9c9d-c703-d4fe-7c2d4d43ed66@collabora.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Tomeu Vizoso Cc: Daniel Stone , Jonathan Corbet , David Airlie , "open list:DOCUMENTATION" , open list , dri-devel@lists.freedesktop.org, "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 T24gV2VkLCBKdWwgMDQsIDIwMTggYXQgMDk6MjY6MzlBTSArMDIwMCwgVG9tZXUgVml6b3NvIHdy b3RlOgo+IE9uIDA3LzA0LzIwMTggMDc6NTMgQU0sIEdlcmQgSG9mZm1hbm4gd3JvdGU6Cj4gPiBP biBUdWUsIEp1bCAwMywgMjAxOCBhdCAxMDozNzo1N0FNICswMjAwLCBEYW5pZWwgVmV0dGVyIHdy b3RlOgo+ID4gPiBPbiBUdWUsIEp1bCAwMywgMjAxOCBhdCAwOTo1Mzo1OEFNICswMjAwLCBHZXJk IEhvZmZtYW5uIHdyb3RlOgo+ID4gPiA+IEEgZHJpdmVyIHRvIGxldCB1c2Vyc3BhY2UgdHVybiBt ZW1mZCByZWdpb25zIGludG8gZG1hLWJ1ZnMuCj4gPiA+ID4gCj4gPiA+ID4gVXNlIGNhc2U6ICBB bGxvd3MgcWVtdSBjcmVhdGUgZG1hYnVmcyBmb3IgdGhlIHZnYSBmcmFtZWJ1ZmZlciBvcgo+ID4g PiA+IHZpcnRpby1ncHUgcmVzc291cmNlcy4gIFRoZW4gdGhleSBjYW4gYmUgcGFzc2VkIGFyb3Vu ZCB0byBkaXNwbGF5Cj4gPiA+ID4gdGhvc2UgZ3Vlc3QgdGhpbmdzIG9uIHRoZSBob3N0LiAgVG8g c3BpY2UgY2xpZW50IGZvciBjbGFzc2ljIGZ1bGwKPiA+ID4gPiBmcmFtZWJ1ZmZlciBkaXNwbGF5 LCBhbmQgaG9wZWZ1bGx5IHNvbWUgZGF5IHRvIHdheWxhbmQgc2VydmVyIGZvcgo+ID4gPiA+IHNl YW1sZXNzIGd1ZXN0IHdpbmRvdyBkaXNwbGF5Lgo+ID4gPiA+IAo+ID4gPiA+IHFlbXUgdGVzdCBi cmFuY2g6Cj4gPiA+ID4gICAgaHR0cHM6Ly9naXQua3JheGVsLm9yZy9jZ2l0L3FlbXUvbG9nLz9o PXNpcml1cy91ZG1hYnVmCj4gPiA+ID4gCj4gPiA+ID4gQ2M6IERhdmlkIEFpcmxpZSA8YWlybGll ZEBsaW51eC5pZT4KPiA+ID4gPiBDYzogVG9tZXUgVml6b3NvIDx0b21ldS52aXpvc29AY29sbGFi b3JhLmNvbT4KPiA+ID4gPiBDYzogTGF1cmVudCBQaW5jaGFydCA8bGF1cmVudC5waW5jaGFydEBp ZGVhc29uYm9hcmQuY29tPgo+ID4gPiA+IENjOiBEYW5pZWwgVmV0dGVyIDxkYW5pZWxAZmZ3bGwu Y2g+Cj4gPiA+ID4gU2lnbmVkLW9mZi1ieTogR2VyZCBIb2ZmbWFubiA8a3JheGVsQHJlZGhhdC5j b20+Cj4gPiA+IAo+ID4gPiBJIHRoaW5rIHNvbWUgYWNrIGZvciBhIDJuZCB1c2UtY2FzZSwgbGlr ZSB2aXJ0aW8td2wgb3Igd2hhdGV2ZXIgd291bGQgYmUKPiA+ID4gcmVhbGx5IGNvb2wuIFRvIGdp dmUgdXMgc29tZSBhc3N1cmFuY2UgdGhhdCB0aGlzIGlzIGdlbmVyaWNhbGx5IHVzZWZ1bC4KPiA+ IAo+ID4gVG9tZXU/ICBMYXVyZW50Pwo+IAo+IFNvcnJ5LCBidXQgSSB0aGluayBJIHdpbGwgbmVl ZCBzb21lIGhlbHAgdG8gdW5kZXJzdGFuZCBob3cgdGhpcyBjb3VsZCBoZWxwCj4gaW4gdGhlIHZp cnRpby13bCBjYXNlIFthZGRpbmcgWmFjaCBSZWl6bmVyIHRvIENDXS4KPiAKPiBBbnkgZ3JhcGhp Y3MgYnVmZmVycyB0aGF0IGFyZSBhbGxvY2F0ZWQgd2l0aCBtZW1mZCB3aWxsIGJlIHNoYXJlZCB3 aXRoIHRoZQo+IGNvbXBvc2l0b3IgdmlhIHdsX3NobSwgd2l0aG91dCBuZWVkIGZvciBkbWFidWZz LgoKV2l0aGluIG9uZSBtYWNoaW5lLCB5ZXMuICBPbmNlIHZpcnR1YWxpemF0aW9uIGlzIGFkZGVk IHRvIHRoZSBtaXggdGhpbmdzCmJlY29tZSBtb3JlIGNvbXBsaWNhdGVkIC4uLgoKV2hlbiB1c2lu ZyB2aXJ0aW8tZ3B1IHRoZSBndWVzdCB3aWxsIGFsbG9jYXRlIGdyYXBoaWNzIGJ1ZmZlcnMgZnJv bQpub3JtYWwgKGd1ZXN0KSByYW0sIHRoZW4gcmVnaXN0ZXIgdGhlc2UgYnVmZmVycyAod2hpY2gg YXJlIGFsbG93ZWQgdG8gYmUKc2NhdHRlcmVkKSB3aXRoIHRoZSBob3N0IGFzIHJlc291cmNlLgoK cWVtdSBjYW4gdXNlIG1lbWZkIHRvIGFsbG9jYXRlIGd1ZXN0IHJhbS4gIE5vdywgd2l0aCB0aGUg aGVscCBvZgp1ZG1hYnVmLCBxZW11IGNhbiBjcmVhdGUgYSAqaG9zdCogZG1hLWJ1ZiBmb3IgdGhl ICpndWVzdCogZ3JhcGhpY3MKYnVmZmVyLgoKVGhhdCBkbWEtYnVmIGNhbiBiZSB1c2VkIGJ5IHFl bXUgaW50ZXJuYWxseSAobW1hcCBpdCB0byBnZXQgYSBsaW5lYXIKbWFwcGluZyBvZiB0aGUgcmVz b3VyY2UsIHRvIGF2b2lkIGNvcHlpbmcpLiAgSXQgY2FuIGJlIHBhc3NlZCBvbiB0bwpzcGljZS1j bGllbnQsIHRvIGRpc3BsYXkgdGhlIGd1ZXN0IGZyYW1lYnVmZmVyLgoKQW5kIEkgdGhpbmsgaXQg Y291bGQgYWxzbyBiZSBxdWl0ZSB1c2VmdWwgdG8gcGFzcyBndWVzdCB3YXlsYW5kIHdpbmRvd3MK dG8gdGhlIGhvc3QgY29tcG9zaXRvciwgd2l0aG91dCBtYXBwaW5nIGhvc3QtYWxsb2NhdGVkIGJ1 ZmZlcnMgaW50byB0aGUKZ3Vlc3QsIHNvIHdlIGRvbid0IGhhdmUgZG8gZGVhbCB3aXRoIHRoZSAi ZmluZCBzb21lIGFkZHJlc3Mgc3BhY2UgZm9yCnRoZSBtYXBwaW5nIiBpc3N1ZSBpbiB0aGUgZmly c3QgcGxhY2UuICBUaGVyZSBhcmUgbW9yZSB0aGluZ3MgbmVlZGVkIHRvCmNvbXBsZXRlIHRoaXMg b2YgY291cnNlLCBidXQgaXQncyBhIGJ1aWxkaW5nIGJsb2NrIC4uLgoKY2hlZXJzLAogIEdlcmQK Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRyaS1kZXZl bCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xp c3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo=