From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754667AbeDTLZ0 (ORCPT ); Fri, 20 Apr 2018 07:25:26 -0400 Received: from mail-lf0-f67.google.com ([209.85.215.67]:34500 "EHLO mail-lf0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754601AbeDTLZY (ORCPT ); Fri, 20 Apr 2018 07:25:24 -0400 X-Google-Smtp-Source: AIpwx4//4n4D4bdKwjhhm5TK5pOp28+jINJCkXRt+RG+wMxqgCqVbz5rjNV14fjG57Ghjodv8Afitw== Subject: Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , jgross@suse.com, Artem Mygaiev , Dongwon Kim , konrad.wilk@oracle.com, airlied@linux.ie, "Oleksandr_Andrushchenko@epam.com" , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, "Potrola, MateuszX" , xen-devel@lists.xenproject.org, daniel.vetter@intel.com, boris.ostrovsky@oracle.com References: <20180329131931.29957-1-andr2000@gmail.com> <5d8fec7f-956c-378f-be90-f45029385740@gmail.com> <20180416192905.GA18096@downor-Z87X-UD5H> <20180417075928.GT31310@phenom.ffwll.local> <20180417205744.GA15930@downor-Z87X-UD5H> <41487acb-a67a-8933-d0c3-702c19b0938e@gmail.com> <20180418073508.ptvntwedczpvl7bx@MacBook-Pro-de-Roger.local> <20180418101058.hyqk3gr3b2ibxswu@MacBook-Pro-de-Roger.local> <20180420071914.GG31310@phenom.ffwll.local> From: Oleksandr Andrushchenko Message-ID: <76cdc65a-7bb1-9377-7bc5-6164e32f7b5d@gmail.com> Date: Fri, 20 Apr 2018 14:25:20 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180420071914.GG31310@phenom.ffwll.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/20/2018 10:19 AM, Daniel Vetter wrote: > On Wed, Apr 18, 2018 at 11:10:58AM +0100, Roger Pau Monné wrote: >> On Wed, Apr 18, 2018 at 11:01:12AM +0300, Oleksandr Andrushchenko wrote: >>> On 04/18/2018 10:35 AM, Roger Pau Monné wrote: >>>> On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenko wrote: >>>>> On 04/17/2018 11:57 PM, Dongwon Kim wrote: >>>>>> On Tue, Apr 17, 2018 at 09:59:28AM +0200, Daniel Vetter wrote: >>>>>>> On Mon, Apr 16, 2018 at 12:29:05PM -0700, Dongwon Kim wrote: >>>>> 3.2 Backend exports dma-buf to xen-front >>>>> >>>>> In this case Dom0 pages are shared with DomU. As before, DomU can only write >>>>> to these pages, not any other page from Dom0, so it can be still considered >>>>> safe. >>>>> But, the following must be considered (highlighted in xen-front's Kernel >>>>> documentation): >>>>>  - If guest domain dies then pages/grants received from the backend cannot >>>>>    be claimed back - think of it as memory lost to Dom0 (won't be used for >>>>> any >>>>>    other guest) >>>>>  - Misbehaving guest may send too many requests to the backend exhausting >>>>>    its grant references and memory (consider this from security POV). As the >>>>>    backend runs in the trusted domain we also assume that it is trusted as >>>>> well, >>>>>    e.g. must take measures to prevent DDoS attacks. >>>> I cannot parse the above sentence: >>>> >>>> "As the backend runs in the trusted domain we also assume that it is >>>> trusted as well, e.g. must take measures to prevent DDoS attacks." >>>> >>>> What's the relation between being trusted and protecting from DoS >>>> attacks? >>> I mean that we trust the backend that it can prevent Dom0 >>> from crashing in case DomU's frontend misbehaves, e.g. >>> if the frontend sends too many memory requests etc. >>>> In any case, all? PV protocols are implemented with the frontend >>>> sharing pages to the backend, and I think there's a reason why this >>>> model is used, and it should continue to be used. >>> This is the first use-case above. But there are real-world >>> use-cases (embedded in my case) when physically contiguous memory >>> needs to be shared, one of the possible ways to achieve this is >>> to share contiguous memory from Dom0 to DomU (the second use-case above) >>>> Having to add logic in the backend to prevent such attacks means >>>> that: >>>> >>>> - We need more code in the backend, which increases complexity and >>>> chances of bugs. >>>> - Such code/logic could be wrong, thus allowing DoS. >>> You can live without this code at all, but this is then up to >>> backend which may make Dom0 down because of DomU's frontend doing evil >>> things >> IMO we should design protocols that do not allow such attacks instead >> of having to defend against them. >> >>>>> 4. xen-front/backend/xen-zcopy synchronization >>>>> >>>>> 4.1. As I already said in 2) all the inter VM communication happens between >>>>> xen-front and the backend, xen-zcopy is NOT involved in that. >>>>> When xen-front wants to destroy a display buffer (dumb/dma-buf) it issues a >>>>> XENDISPL_OP_DBUF_DESTROY command (opposite to XENDISPL_OP_DBUF_CREATE). >>>>> This call is synchronous, so xen-front expects that backend does free the >>>>> buffer pages on return. >>>>> >>>>> 4.2. Backend, on XENDISPL_OP_DBUF_DESTROY: >>>>>   - closes all dumb handles/fd's of the buffer according to [3] >>>>>   - issues DRM_IOCTL_XEN_ZCOPY_DUMB_WAIT_FREE IOCTL to xen-zcopy to make >>>>> sure >>>>>     the buffer is freed (think of it as it waits for dma-buf->release >>>>> callback) >>>> So this zcopy thing keeps some kind of track of the memory usage? Why >>>> can't the user-space backend keep track of the buffer usage? >>> Because there is no dma-buf UAPI which allows to track the buffer life cycle >>> (e.g. wait until dma-buf's .release callback is called) >>>>>   - replies to xen-front that the buffer can be destroyed. >>>>> This way deletion of the buffer happens synchronously on both Dom0 and DomU >>>>> sides. In case if DRM_IOCTL_XEN_ZCOPY_DUMB_WAIT_FREE returns with time-out >>>>> error >>>>> (BTW, wait time is a parameter of this IOCTL), Xen will defer grant >>>>> reference >>>>> removal and will retry later until those are free. >>>>> >>>>> Hope this helps understand how buffers are synchronously deleted in case >>>>> of xen-zcopy with a single protocol command. >>>>> >>>>> I think the above logic can also be re-used by the hyper-dmabuf driver with >>>>> some additional work: >>>>> >>>>> 1. xen-zcopy can be split into 2 parts and extend: >>>>> 1.1. Xen gntdev driver [4], [5] to allow creating dma-buf from grefs and >>>>> vise versa, >>>> I don't know much about the dma-buf implementation in Linux, but >>>> gntdev is a user-space device, and AFAICT user-space applications >>>> don't have any notion of dma buffers. How are such buffers useful for >>>> user-space? Why can't this just be called memory? >>> A dma-buf is seen by user-space as a file descriptor and you can >>> pass it to different drivers then. For example, you can share a buffer >>> used by a display driver for scanout with a GPU, to compose a picture >>> into it: >>> 1. User-space (US) allocates a display buffer from display driver >>> 2. US asks display driver to export the dma-buf which backs up that buffer, >>> US gets buffer's fd: dma_buf_fd >>> 3. US asks GPU driver to import a buffer and provides it with dma_buf_fd >>> 4. GPU renders contents into display buffer (dma_buf_fd) >> After speaking with Oleksandr on IRC, I think the main usage of the >> gntdev extension is to: >> >> 1. Create a dma-buf from a set of grant references. >> 2. Share dma-buf and get a list of grant references. >> >> I think this set of operations could be broken into: >> >> 1.1 Map grant references into user-space using the gntdev. >> 1.2 Create a dma-buf out of a set of user-space virtual addresses. >> >> 2.1 Map a dma-buf into user-space. >> 2.2 Get grefs out of the user-space addresses where the dma-buf is >> mapped. >> >> So it seems like what's actually missing is a way to: >> >> - Create a dma-buf from a list of user-space virtual addresses. >> - Allow to map a dma-buf into user-space, so it can then be used with >> the gntdev. >> >> I think this is generic enough that it could be implemented by a >> device not tied to Xen. AFAICT the hyper_dma guys also wanted >> something similar to this. > You can't just wrap random userspace memory into a dma-buf. We've just had > this discussion with kvm/qemu folks, who proposed just that, and after a > bit of discussion they'll now try to have a driver which just wraps a > memfd into a dma-buf. So, we have to decide either we introduce a new driver (say, under drivers/xen/xen-dma-buf) or extend the existing gntdev/balloon to support dma-buf use-cases. Can anybody from Xen community express their preference here? And I hope that there is no objection to have it all in the kernel, without going to user-space with VAs and back (device-X driver) > > Yes i915 and amdgpu and a few other drivers do have facilities to wrap > userspace memory into a gpu buffer object. But we don't allow those to be > exported to other drivers, because the core mm magic needed to make this > all work is way too tricky, even within the context of just 1 driver. And > dma-buf does not have the required callbacks and semantics to make it > work. > -Daniel > >>> Finally, this is indeed some memory, but a bit more [1] >>>> Also, (with my FreeBSD maintainer hat) how is this going to translate >>>> to other OSes? So far the operations performed by the gntdev device >>>> are mostly OS-agnostic because this just map/unmap memory, and in fact >>>> they are implemented by Linux and FreeBSD. >>> At the moment I can only see Linux implementation and it seems >>> to be perfectly ok as we do not change Xen's APIs etc. and only >>> use the existing ones (remember, we only extend gntdev/balloon >>> drivers, all the changes in the Linux kernel) >>> As the second note I can also think that we do not extend gntdev/balloon >>> drivers and have re-worked xen-zcopy driver be a separate entity, >>> say drivers/xen/dma-buf >>>>> implement "wait" ioctl (wait for dma-buf->release): currently these are >>>>> DRM_XEN_ZCOPY_DUMB_FROM_REFS, DRM_XEN_ZCOPY_DUMB_TO_REFS and >>>>> DRM_XEN_ZCOPY_DUMB_WAIT_FREE >>>>> 1.2. Xen balloon driver [6] to allow allocating contiguous buffers (not >>>>> needed >>>>> by current hyper-dmabuf, but is a must for xen-zcopy use-cases) >>>> I think this needs clarifying. In which memory space do you need those >>>> regions to be contiguous? >>> Use-case: Dom0 has a HW driver which only works with contig memory >>> and I want DomU to be able to directly write into that memory, thus >>> implementing zero copying >>>> Do they need to be contiguous in host physical memory, or guest >>>> physical memory? >>> Host >>>> If it's in guest memory space, isn't there any generic interface that >>>> you can use? >>>> >>>> If it's in host physical memory space, why do you need this buffer to >>>> be contiguous in host physical memory space? The IOMMU should hide all >>>> this. >>> There are drivers/HW which can only work with contig memory and >>> if it is backed by an IOMMU then still it has to be contig in IPA >>> space (real device doesn't know that it is actually IPA contig, not PA) >> What's IPA contig? >> >> Thanks, Roger. >> _______________________________________________ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oleksandr Andrushchenko Subject: Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver Date: Fri, 20 Apr 2018 14:25:20 +0300 Message-ID: <76cdc65a-7bb1-9377-7bc5-6164e32f7b5d@gmail.com> References: <20180329131931.29957-1-andr2000@gmail.com> <5d8fec7f-956c-378f-be90-f45029385740@gmail.com> <20180416192905.GA18096@downor-Z87X-UD5H> <20180417075928.GT31310@phenom.ffwll.local> <20180417205744.GA15930@downor-Z87X-UD5H> <41487acb-a67a-8933-d0c3-702c19b0938e@gmail.com> <20180418073508.ptvntwedczpvl7bx@MacBook-Pro-de-Roger.local> <20180418101058.hyqk3gr3b2ibxswu@MacBook-Pro-de-Roger.local> <20180420071914.GG31310@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: Received: from mail-lf0-x241.google.com (mail-lf0-x241.google.com [IPv6:2a00:1450:4010:c07::241]) by gabe.freedesktop.org (Postfix) with ESMTPS id 1DA1289C1B for ; Fri, 20 Apr 2018 11:25:24 +0000 (UTC) Received: by mail-lf0-x241.google.com with SMTP id d79-v6so4681591lfd.0 for ; Fri, 20 Apr 2018 04:25:24 -0700 (PDT) In-Reply-To: <20180420071914.GG31310@phenom.ffwll.local> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , jgross@suse.com, Artem Mygaiev , Dongwon Kim , konrad.wilk@oracle.com, airlied@linux.ie, "Oleksandr_Andrushchenko@epam.com" , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, "Potrola, MateuszX" , xen-devel@lists.xenproject.org, daniel.vetter@intel.com, boris.ostrovsky@oracle.com List-Id: dri-devel@lists.freedesktop.org T24gMDQvMjAvMjAxOCAxMDoxOSBBTSwgRGFuaWVsIFZldHRlciB3cm90ZToKPiBPbiBXZWQsIEFw ciAxOCwgMjAxOCBhdCAxMToxMDo1OEFNICswMTAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+ PiBPbiBXZWQsIEFwciAxOCwgMjAxOCBhdCAxMTowMToxMkFNICswMzAwLCBPbGVrc2FuZHIgQW5k cnVzaGNoZW5rbyB3cm90ZToKPj4+IE9uIDA0LzE4LzIwMTggMTA6MzUgQU0sIFJvZ2VyIFBhdSBN b25uw6kgd3JvdGU6Cj4+Pj4gT24gV2VkLCBBcHIgMTgsIDIwMTggYXQgMDk6Mzg6MzlBTSArMDMw MCwgT2xla3NhbmRyIEFuZHJ1c2hjaGVua28gd3JvdGU6Cj4+Pj4+IE9uIDA0LzE3LzIwMTggMTE6 NTcgUE0sIERvbmd3b24gS2ltIHdyb3RlOgo+Pj4+Pj4gT24gVHVlLCBBcHIgMTcsIDIwMTggYXQg MDk6NTk6MjhBTSArMDIwMCwgRGFuaWVsIFZldHRlciB3cm90ZToKPj4+Pj4+PiBPbiBNb24sIEFw ciAxNiwgMjAxOCBhdCAxMjoyOTowNVBNIC0wNzAwLCBEb25nd29uIEtpbSB3cm90ZToKPj4+Pj4g My4yIEJhY2tlbmQgZXhwb3J0cyBkbWEtYnVmIHRvIHhlbi1mcm9udAo+Pj4+Pgo+Pj4+PiBJbiB0 aGlzIGNhc2UgRG9tMCBwYWdlcyBhcmUgc2hhcmVkIHdpdGggRG9tVS4gQXMgYmVmb3JlLCBEb21V IGNhbiBvbmx5IHdyaXRlCj4+Pj4+IHRvIHRoZXNlIHBhZ2VzLCBub3QgYW55IG90aGVyIHBhZ2Ug ZnJvbSBEb20wLCBzbyBpdCBjYW4gYmUgc3RpbGwgY29uc2lkZXJlZAo+Pj4+PiBzYWZlLgo+Pj4+ PiBCdXQsIHRoZSBmb2xsb3dpbmcgbXVzdCBiZSBjb25zaWRlcmVkIChoaWdobGlnaHRlZCBpbiB4 ZW4tZnJvbnQncyBLZXJuZWwKPj4+Pj4gZG9jdW1lbnRhdGlvbik6Cj4+Pj4+ICAgwqAtIElmIGd1 ZXN0IGRvbWFpbiBkaWVzIHRoZW4gcGFnZXMvZ3JhbnRzIHJlY2VpdmVkIGZyb20gdGhlIGJhY2tl bmQgY2Fubm90Cj4+Pj4+ICAgwqDCoCBiZSBjbGFpbWVkIGJhY2sgLSB0aGluayBvZiBpdCBhcyBt ZW1vcnkgbG9zdCB0byBEb20wICh3b24ndCBiZSB1c2VkIGZvcgo+Pj4+PiBhbnkKPj4+Pj4gICDC oMKgIG90aGVyIGd1ZXN0KQo+Pj4+PiAgIMKgLSBNaXNiZWhhdmluZyBndWVzdCBtYXkgc2VuZCB0 b28gbWFueSByZXF1ZXN0cyB0byB0aGUgYmFja2VuZCBleGhhdXN0aW5nCj4+Pj4+ICAgwqDCoCBp dHMgZ3JhbnQgcmVmZXJlbmNlcyBhbmQgbWVtb3J5IChjb25zaWRlciB0aGlzIGZyb20gc2VjdXJp dHkgUE9WKS4gQXMgdGhlCj4+Pj4+ICAgwqDCoCBiYWNrZW5kIHJ1bnMgaW4gdGhlIHRydXN0ZWQg ZG9tYWluIHdlIGFsc28gYXNzdW1lIHRoYXQgaXQgaXMgdHJ1c3RlZCBhcwo+Pj4+PiB3ZWxsLAo+ Pj4+PiAgIMKgwqAgZS5nLiBtdXN0IHRha2UgbWVhc3VyZXMgdG8gcHJldmVudCBERG9TIGF0dGFj a3MuCj4+Pj4gSSBjYW5ub3QgcGFyc2UgdGhlIGFib3ZlIHNlbnRlbmNlOgo+Pj4+Cj4+Pj4gIkFz IHRoZSBiYWNrZW5kIHJ1bnMgaW4gdGhlIHRydXN0ZWQgZG9tYWluIHdlIGFsc28gYXNzdW1lIHRo YXQgaXQgaXMKPj4+PiB0cnVzdGVkIGFzIHdlbGwsIGUuZy4gbXVzdCB0YWtlIG1lYXN1cmVzIHRv IHByZXZlbnQgRERvUyBhdHRhY2tzLiIKPj4+Pgo+Pj4+IFdoYXQncyB0aGUgcmVsYXRpb24gYmV0 d2VlbiBiZWluZyB0cnVzdGVkIGFuZCBwcm90ZWN0aW5nIGZyb20gRG9TCj4+Pj4gYXR0YWNrcz8K Pj4+IEkgbWVhbiB0aGF0IHdlIHRydXN0IHRoZSBiYWNrZW5kIHRoYXQgaXQgY2FuIHByZXZlbnQg RG9tMAo+Pj4gZnJvbSBjcmFzaGluZyBpbiBjYXNlIERvbVUncyBmcm9udGVuZCBtaXNiZWhhdmVz LCBlLmcuCj4+PiBpZiB0aGUgZnJvbnRlbmQgc2VuZHMgdG9vIG1hbnkgbWVtb3J5IHJlcXVlc3Rz IGV0Yy4KPj4+PiBJbiBhbnkgY2FzZSwgYWxsPyBQViBwcm90b2NvbHMgYXJlIGltcGxlbWVudGVk IHdpdGggdGhlIGZyb250ZW5kCj4+Pj4gc2hhcmluZyBwYWdlcyB0byB0aGUgYmFja2VuZCwgYW5k IEkgdGhpbmsgdGhlcmUncyBhIHJlYXNvbiB3aHkgdGhpcwo+Pj4+IG1vZGVsIGlzIHVzZWQsIGFu ZCBpdCBzaG91bGQgY29udGludWUgdG8gYmUgdXNlZC4KPj4+IFRoaXMgaXMgdGhlIGZpcnN0IHVz ZS1jYXNlIGFib3ZlLiBCdXQgdGhlcmUgYXJlIHJlYWwtd29ybGQKPj4+IHVzZS1jYXNlcyAoZW1i ZWRkZWQgaW4gbXkgY2FzZSkgd2hlbiBwaHlzaWNhbGx5IGNvbnRpZ3VvdXMgbWVtb3J5Cj4+PiBu ZWVkcyB0byBiZSBzaGFyZWQsIG9uZSBvZiB0aGUgcG9zc2libGUgd2F5cyB0byBhY2hpZXZlIHRo aXMgaXMKPj4+IHRvIHNoYXJlIGNvbnRpZ3VvdXMgbWVtb3J5IGZyb20gRG9tMCB0byBEb21VICh0 aGUgc2Vjb25kIHVzZS1jYXNlIGFib3ZlKQo+Pj4+IEhhdmluZyB0byBhZGQgbG9naWMgaW4gdGhl IGJhY2tlbmQgdG8gcHJldmVudCBzdWNoIGF0dGFja3MgbWVhbnMKPj4+PiB0aGF0Ogo+Pj4+Cj4+ Pj4gICAgLSBXZSBuZWVkIG1vcmUgY29kZSBpbiB0aGUgYmFja2VuZCwgd2hpY2ggaW5jcmVhc2Vz IGNvbXBsZXhpdHkgYW5kCj4+Pj4gICAgICBjaGFuY2VzIG9mIGJ1Z3MuCj4+Pj4gICAgLSBTdWNo IGNvZGUvbG9naWMgY291bGQgYmUgd3JvbmcsIHRodXMgYWxsb3dpbmcgRG9TLgo+Pj4gWW91IGNh biBsaXZlIHdpdGhvdXQgdGhpcyBjb2RlIGF0IGFsbCwgYnV0IHRoaXMgaXMgdGhlbiB1cCB0bwo+ Pj4gYmFja2VuZCB3aGljaCBtYXkgbWFrZSBEb20wIGRvd24gYmVjYXVzZSBvZiBEb21VJ3MgZnJv bnRlbmQgZG9pbmcgZXZpbAo+Pj4gdGhpbmdzCj4+IElNTyB3ZSBzaG91bGQgZGVzaWduIHByb3Rv Y29scyB0aGF0IGRvIG5vdCBhbGxvdyBzdWNoIGF0dGFja3MgaW5zdGVhZAo+PiBvZiBoYXZpbmcg dG8gZGVmZW5kIGFnYWluc3QgdGhlbS4KPj4KPj4+Pj4gNC4geGVuLWZyb250L2JhY2tlbmQveGVu LXpjb3B5IHN5bmNocm9uaXphdGlvbgo+Pj4+Pgo+Pj4+PiA0LjEuIEFzIEkgYWxyZWFkeSBzYWlk IGluIDIpIGFsbCB0aGUgaW50ZXIgVk0gY29tbXVuaWNhdGlvbiBoYXBwZW5zIGJldHdlZW4KPj4+ Pj4geGVuLWZyb250IGFuZCB0aGUgYmFja2VuZCwgeGVuLXpjb3B5IGlzIE5PVCBpbnZvbHZlZCBp biB0aGF0Lgo+Pj4+PiBXaGVuIHhlbi1mcm9udCB3YW50cyB0byBkZXN0cm95IGEgZGlzcGxheSBi dWZmZXIgKGR1bWIvZG1hLWJ1ZikgaXQgaXNzdWVzIGEKPj4+Pj4gWEVORElTUExfT1BfREJVRl9E RVNUUk9ZIGNvbW1hbmQgKG9wcG9zaXRlIHRvIFhFTkRJU1BMX09QX0RCVUZfQ1JFQVRFKS4KPj4+ Pj4gVGhpcyBjYWxsIGlzIHN5bmNocm9ub3VzLCBzbyB4ZW4tZnJvbnQgZXhwZWN0cyB0aGF0IGJh Y2tlbmQgZG9lcyBmcmVlIHRoZQo+Pj4+PiBidWZmZXIgcGFnZXMgb24gcmV0dXJuLgo+Pj4+Pgo+ Pj4+PiA0LjIuIEJhY2tlbmQsIG9uIFhFTkRJU1BMX09QX0RCVUZfREVTVFJPWToKPj4+Pj4gICDC oCAtIGNsb3NlcyBhbGwgZHVtYiBoYW5kbGVzL2ZkJ3Mgb2YgdGhlIGJ1ZmZlciBhY2NvcmRpbmcg dG8gWzNdCj4+Pj4+ICAgwqAgLSBpc3N1ZXMgRFJNX0lPQ1RMX1hFTl9aQ09QWV9EVU1CX1dBSVRf RlJFRSBJT0NUTCB0byB4ZW4temNvcHkgdG8gbWFrZQo+Pj4+PiBzdXJlCj4+Pj4+ICAgwqDCoMKg IHRoZSBidWZmZXIgaXMgZnJlZWQgKHRoaW5rIG9mIGl0IGFzIGl0IHdhaXRzIGZvciBkbWEtYnVm LT5yZWxlYXNlCj4+Pj4+IGNhbGxiYWNrKQo+Pj4+IFNvIHRoaXMgemNvcHkgdGhpbmcga2VlcHMg c29tZSBraW5kIG9mIHRyYWNrIG9mIHRoZSBtZW1vcnkgdXNhZ2U/IFdoeQo+Pj4+IGNhbid0IHRo ZSB1c2VyLXNwYWNlIGJhY2tlbmQga2VlcCB0cmFjayBvZiB0aGUgYnVmZmVyIHVzYWdlPwo+Pj4g QmVjYXVzZSB0aGVyZSBpcyBubyBkbWEtYnVmIFVBUEkgd2hpY2ggYWxsb3dzIHRvIHRyYWNrIHRo ZSBidWZmZXIgbGlmZSBjeWNsZQo+Pj4gKGUuZy4gd2FpdCB1bnRpbCBkbWEtYnVmJ3MgLnJlbGVh c2UgY2FsbGJhY2sgaXMgY2FsbGVkKQo+Pj4+PiAgIMKgIC0gcmVwbGllcyB0byB4ZW4tZnJvbnQg dGhhdCB0aGUgYnVmZmVyIGNhbiBiZSBkZXN0cm95ZWQuCj4+Pj4+IFRoaXMgd2F5IGRlbGV0aW9u IG9mIHRoZSBidWZmZXIgaGFwcGVucyBzeW5jaHJvbm91c2x5IG9uIGJvdGggRG9tMCBhbmQgRG9t VQo+Pj4+PiBzaWRlcy4gSW4gY2FzZSBpZiBEUk1fSU9DVExfWEVOX1pDT1BZX0RVTUJfV0FJVF9G UkVFIHJldHVybnMgd2l0aCB0aW1lLW91dAo+Pj4+PiBlcnJvcgo+Pj4+PiAoQlRXLCB3YWl0IHRp bWUgaXMgYSBwYXJhbWV0ZXIgb2YgdGhpcyBJT0NUTCksIFhlbiB3aWxsIGRlZmVyIGdyYW50Cj4+ Pj4+IHJlZmVyZW5jZQo+Pj4+PiByZW1vdmFsIGFuZCB3aWxsIHJldHJ5IGxhdGVyIHVudGlsIHRo b3NlIGFyZSBmcmVlLgo+Pj4+Pgo+Pj4+PiBIb3BlIHRoaXMgaGVscHMgdW5kZXJzdGFuZCBob3cg YnVmZmVycyBhcmUgc3luY2hyb25vdXNseSBkZWxldGVkIGluIGNhc2UKPj4+Pj4gb2YgeGVuLXpj b3B5IHdpdGggYSBzaW5nbGUgcHJvdG9jb2wgY29tbWFuZC4KPj4+Pj4KPj4+Pj4gSSB0aGluayB0 aGUgYWJvdmUgbG9naWMgY2FuIGFsc28gYmUgcmUtdXNlZCBieSB0aGUgaHlwZXItZG1hYnVmIGRy aXZlciB3aXRoCj4+Pj4+IHNvbWUgYWRkaXRpb25hbCB3b3JrOgo+Pj4+Pgo+Pj4+PiAxLiB4ZW4t emNvcHkgY2FuIGJlIHNwbGl0IGludG8gMiBwYXJ0cyBhbmQgZXh0ZW5kOgo+Pj4+PiAxLjEuIFhl biBnbnRkZXYgZHJpdmVyIFs0XSwgWzVdIHRvIGFsbG93IGNyZWF0aW5nIGRtYS1idWYgZnJvbSBn cmVmcyBhbmQKPj4+Pj4gdmlzZSB2ZXJzYSwKPj4+PiBJIGRvbid0IGtub3cgbXVjaCBhYm91dCB0 aGUgZG1hLWJ1ZiBpbXBsZW1lbnRhdGlvbiBpbiBMaW51eCwgYnV0Cj4+Pj4gZ250ZGV2IGlzIGEg dXNlci1zcGFjZSBkZXZpY2UsIGFuZCBBRkFJQ1QgdXNlci1zcGFjZSBhcHBsaWNhdGlvbnMKPj4+ PiBkb24ndCBoYXZlIGFueSBub3Rpb24gb2YgZG1hIGJ1ZmZlcnMuIEhvdyBhcmUgc3VjaCBidWZm ZXJzIHVzZWZ1bCBmb3IKPj4+PiB1c2VyLXNwYWNlPyBXaHkgY2FuJ3QgdGhpcyBqdXN0IGJlIGNh bGxlZCBtZW1vcnk/Cj4+PiBBIGRtYS1idWYgaXMgc2VlbiBieSB1c2VyLXNwYWNlIGFzIGEgZmls ZSBkZXNjcmlwdG9yIGFuZCB5b3UgY2FuCj4+PiBwYXNzIGl0IHRvIGRpZmZlcmVudCBkcml2ZXJz IHRoZW4uIEZvciBleGFtcGxlLCB5b3UgY2FuIHNoYXJlIGEgYnVmZmVyCj4+PiB1c2VkIGJ5IGEg ZGlzcGxheSBkcml2ZXIgZm9yIHNjYW5vdXQgd2l0aCBhIEdQVSwgdG8gY29tcG9zZSBhIHBpY3R1 cmUKPj4+IGludG8gaXQ6Cj4+PiAxLiBVc2VyLXNwYWNlIChVUykgYWxsb2NhdGVzIGEgZGlzcGxh eSBidWZmZXIgZnJvbSBkaXNwbGF5IGRyaXZlcgo+Pj4gMi4gVVMgYXNrcyBkaXNwbGF5IGRyaXZl ciB0byBleHBvcnQgdGhlIGRtYS1idWYgd2hpY2ggYmFja3MgdXAgdGhhdCBidWZmZXIsCj4+PiBV UyBnZXRzIGJ1ZmZlcidzIGZkOiBkbWFfYnVmX2ZkCj4+PiAzLiBVUyBhc2tzIEdQVSBkcml2ZXIg dG8gaW1wb3J0IGEgYnVmZmVyIGFuZCBwcm92aWRlcyBpdCB3aXRoIGRtYV9idWZfZmQKPj4+IDQu IEdQVSByZW5kZXJzIGNvbnRlbnRzIGludG8gZGlzcGxheSBidWZmZXIgKGRtYV9idWZfZmQpCj4+ IEFmdGVyIHNwZWFraW5nIHdpdGggT2xla3NhbmRyIG9uIElSQywgSSB0aGluayB0aGUgbWFpbiB1 c2FnZSBvZiB0aGUKPj4gZ250ZGV2IGV4dGVuc2lvbiBpcyB0bzoKPj4KPj4gMS4gQ3JlYXRlIGEg ZG1hLWJ1ZiBmcm9tIGEgc2V0IG9mIGdyYW50IHJlZmVyZW5jZXMuCj4+IDIuIFNoYXJlIGRtYS1i dWYgYW5kIGdldCBhIGxpc3Qgb2YgZ3JhbnQgcmVmZXJlbmNlcy4KPj4KPj4gSSB0aGluayB0aGlz IHNldCBvZiBvcGVyYXRpb25zIGNvdWxkIGJlIGJyb2tlbiBpbnRvOgo+Pgo+PiAxLjEgTWFwIGdy YW50IHJlZmVyZW5jZXMgaW50byB1c2VyLXNwYWNlIHVzaW5nIHRoZSBnbnRkZXYuCj4+IDEuMiBD cmVhdGUgYSBkbWEtYnVmIG91dCBvZiBhIHNldCBvZiB1c2VyLXNwYWNlIHZpcnR1YWwgYWRkcmVz c2VzLgo+Pgo+PiAyLjEgTWFwIGEgZG1hLWJ1ZiBpbnRvIHVzZXItc3BhY2UuCj4+IDIuMiBHZXQg Z3JlZnMgb3V0IG9mIHRoZSB1c2VyLXNwYWNlIGFkZHJlc3NlcyB3aGVyZSB0aGUgZG1hLWJ1ZiBp cwo+PiAgICAgIG1hcHBlZC4KPj4KPj4gU28gaXQgc2VlbXMgbGlrZSB3aGF0J3MgYWN0dWFsbHkg bWlzc2luZyBpcyBhIHdheSB0bzoKPj4KPj4gICAtIENyZWF0ZSBhIGRtYS1idWYgZnJvbSBhIGxp c3Qgb2YgdXNlci1zcGFjZSB2aXJ0dWFsIGFkZHJlc3Nlcy4KPj4gICAtIEFsbG93IHRvIG1hcCBh IGRtYS1idWYgaW50byB1c2VyLXNwYWNlLCBzbyBpdCBjYW4gdGhlbiBiZSB1c2VkIHdpdGgKPj4g ICAgIHRoZSBnbnRkZXYuCj4+Cj4+IEkgdGhpbmsgdGhpcyBpcyBnZW5lcmljIGVub3VnaCB0aGF0 IGl0IGNvdWxkIGJlIGltcGxlbWVudGVkIGJ5IGEKPj4gZGV2aWNlIG5vdCB0aWVkIHRvIFhlbi4g QUZBSUNUIHRoZSBoeXBlcl9kbWEgZ3V5cyBhbHNvIHdhbnRlZAo+PiBzb21ldGhpbmcgc2ltaWxh ciB0byB0aGlzLgo+IFlvdSBjYW4ndCBqdXN0IHdyYXAgcmFuZG9tIHVzZXJzcGFjZSBtZW1vcnkg aW50byBhIGRtYS1idWYuIFdlJ3ZlIGp1c3QgaGFkCj4gdGhpcyBkaXNjdXNzaW9uIHdpdGgga3Zt L3FlbXUgZm9sa3MsIHdobyBwcm9wb3NlZCBqdXN0IHRoYXQsIGFuZCBhZnRlciBhCj4gYml0IG9m IGRpc2N1c3Npb24gdGhleSdsbCBub3cgdHJ5IHRvIGhhdmUgYSBkcml2ZXIgd2hpY2gganVzdCB3 cmFwcyBhCj4gbWVtZmQgaW50byBhIGRtYS1idWYuClNvLCB3ZSBoYXZlIHRvIGRlY2lkZSBlaXRo ZXIgd2UgaW50cm9kdWNlIGEgbmV3IGRyaXZlcgooc2F5LCB1bmRlciBkcml2ZXJzL3hlbi94ZW4t ZG1hLWJ1Zikgb3IgZXh0ZW5kIHRoZSBleGlzdGluZwpnbnRkZXYvYmFsbG9vbiB0byBzdXBwb3J0 IGRtYS1idWYgdXNlLWNhc2VzLgoKQ2FuIGFueWJvZHkgZnJvbSBYZW4gY29tbXVuaXR5IGV4cHJl c3MgdGhlaXIgcHJlZmVyZW5jZSBoZXJlPwoKQW5kIEkgaG9wZSB0aGF0IHRoZXJlIGlzIG5vIG9i amVjdGlvbiB0byBoYXZlIGl0IGFsbCBpbiB0aGUga2VybmVsLAp3aXRob3V0IGdvaW5nIHRvIHVz ZXItc3BhY2Ugd2l0aCBWQXMgYW5kIGJhY2sgKGRldmljZS1YIGRyaXZlcikKPgo+IFllcyBpOTE1 IGFuZCBhbWRncHUgYW5kIGEgZmV3IG90aGVyIGRyaXZlcnMgZG8gaGF2ZSBmYWNpbGl0aWVzIHRv IHdyYXAKPiB1c2Vyc3BhY2UgbWVtb3J5IGludG8gYSBncHUgYnVmZmVyIG9iamVjdC4gQnV0IHdl IGRvbid0IGFsbG93IHRob3NlIHRvIGJlCj4gZXhwb3J0ZWQgdG8gb3RoZXIgZHJpdmVycywgYmVj YXVzZSB0aGUgY29yZSBtbSBtYWdpYyBuZWVkZWQgdG8gbWFrZSB0aGlzCj4gYWxsIHdvcmsgaXMg d2F5IHRvbyB0cmlja3ksIGV2ZW4gd2l0aGluIHRoZSBjb250ZXh0IG9mIGp1c3QgMSBkcml2ZXIu IEFuZAo+IGRtYS1idWYgZG9lcyBub3QgaGF2ZSB0aGUgcmVxdWlyZWQgY2FsbGJhY2tzIGFuZCBz ZW1hbnRpY3MgdG8gbWFrZSBpdAo+IHdvcmsuCj4gLURhbmllbAo+Cj4+PiBGaW5hbGx5LCB0aGlz IGlzIGluZGVlZCBzb21lIG1lbW9yeSwgYnV0IGEgYml0IG1vcmUgWzFdCj4+Pj4gQWxzbywgKHdp dGggbXkgRnJlZUJTRCBtYWludGFpbmVyIGhhdCkgaG93IGlzIHRoaXMgZ29pbmcgdG8gdHJhbnNs YXRlCj4+Pj4gdG8gb3RoZXIgT1Nlcz8gU28gZmFyIHRoZSBvcGVyYXRpb25zIHBlcmZvcm1lZCBi eSB0aGUgZ250ZGV2IGRldmljZQo+Pj4+IGFyZSBtb3N0bHkgT1MtYWdub3N0aWMgYmVjYXVzZSB0 aGlzIGp1c3QgbWFwL3VubWFwIG1lbW9yeSwgYW5kIGluIGZhY3QKPj4+PiB0aGV5IGFyZSBpbXBs ZW1lbnRlZCBieSBMaW51eCBhbmQgRnJlZUJTRC4KPj4+IEF0IHRoZSBtb21lbnQgSSBjYW4gb25s eSBzZWUgTGludXggaW1wbGVtZW50YXRpb24gYW5kIGl0IHNlZW1zCj4+PiB0byBiZSBwZXJmZWN0 bHkgb2sgYXMgd2UgZG8gbm90IGNoYW5nZSBYZW4ncyBBUElzIGV0Yy4gYW5kIG9ubHkKPj4+IHVz ZSB0aGUgZXhpc3Rpbmcgb25lcyAocmVtZW1iZXIsIHdlIG9ubHkgZXh0ZW5kIGdudGRldi9iYWxs b29uCj4+PiBkcml2ZXJzLCBhbGwgdGhlIGNoYW5nZXMgaW4gdGhlIExpbnV4IGtlcm5lbCkKPj4+ IEFzIHRoZSBzZWNvbmQgbm90ZSBJIGNhbiBhbHNvIHRoaW5rIHRoYXQgd2UgZG8gbm90IGV4dGVu ZCBnbnRkZXYvYmFsbG9vbgo+Pj4gZHJpdmVycyBhbmQgaGF2ZSByZS13b3JrZWQgeGVuLXpjb3B5 IGRyaXZlciBiZSBhIHNlcGFyYXRlIGVudGl0eSwKPj4+IHNheSBkcml2ZXJzL3hlbi9kbWEtYnVm Cj4+Pj4+IGltcGxlbWVudCAid2FpdCIgaW9jdGwgKHdhaXQgZm9yIGRtYS1idWYtPnJlbGVhc2Up OiBjdXJyZW50bHkgdGhlc2UgYXJlCj4+Pj4+IERSTV9YRU5fWkNPUFlfRFVNQl9GUk9NX1JFRlMs IERSTV9YRU5fWkNPUFlfRFVNQl9UT19SRUZTIGFuZAo+Pj4+PiBEUk1fWEVOX1pDT1BZX0RVTUJf V0FJVF9GUkVFCj4+Pj4+IDEuMi4gWGVuIGJhbGxvb24gZHJpdmVyIFs2XSB0byBhbGxvdyBhbGxv Y2F0aW5nIGNvbnRpZ3VvdXMgYnVmZmVycyAobm90Cj4+Pj4+IG5lZWRlZAo+Pj4+PiBieSBjdXJy ZW50IGh5cGVyLWRtYWJ1ZiwgYnV0IGlzIGEgbXVzdCBmb3IgeGVuLXpjb3B5IHVzZS1jYXNlcykK Pj4+PiBJIHRoaW5rIHRoaXMgbmVlZHMgY2xhcmlmeWluZy4gSW4gd2hpY2ggbWVtb3J5IHNwYWNl IGRvIHlvdSBuZWVkIHRob3NlCj4+Pj4gcmVnaW9ucyB0byBiZSBjb250aWd1b3VzPwo+Pj4gVXNl LWNhc2U6IERvbTAgaGFzIGEgSFcgZHJpdmVyIHdoaWNoIG9ubHkgd29ya3Mgd2l0aCBjb250aWcg bWVtb3J5Cj4+PiBhbmQgSSB3YW50IERvbVUgdG8gYmUgYWJsZSB0byBkaXJlY3RseSB3cml0ZSBp bnRvIHRoYXQgbWVtb3J5LCB0aHVzCj4+PiBpbXBsZW1lbnRpbmcgemVybyBjb3B5aW5nCj4+Pj4g RG8gdGhleSBuZWVkIHRvIGJlIGNvbnRpZ3VvdXMgaW4gaG9zdCBwaHlzaWNhbCBtZW1vcnksIG9y IGd1ZXN0Cj4+Pj4gcGh5c2ljYWwgbWVtb3J5Pwo+Pj4gSG9zdAo+Pj4+IElmIGl0J3MgaW4gZ3Vl c3QgbWVtb3J5IHNwYWNlLCBpc24ndCB0aGVyZSBhbnkgZ2VuZXJpYyBpbnRlcmZhY2UgdGhhdAo+ Pj4+IHlvdSBjYW4gdXNlPwo+Pj4+Cj4+Pj4gSWYgaXQncyBpbiBob3N0IHBoeXNpY2FsIG1lbW9y eSBzcGFjZSwgd2h5IGRvIHlvdSBuZWVkIHRoaXMgYnVmZmVyIHRvCj4+Pj4gYmUgY29udGlndW91 cyBpbiBob3N0IHBoeXNpY2FsIG1lbW9yeSBzcGFjZT8gVGhlIElPTU1VIHNob3VsZCBoaWRlIGFs bAo+Pj4+IHRoaXMuCj4+PiBUaGVyZSBhcmUgZHJpdmVycy9IVyB3aGljaCBjYW4gb25seSB3b3Jr IHdpdGggY29udGlnIG1lbW9yeSBhbmQKPj4+IGlmIGl0IGlzIGJhY2tlZCBieSBhbiBJT01NVSB0 aGVuIHN0aWxsIGl0IGhhcyB0byBiZSBjb250aWcgaW4gSVBBCj4+PiBzcGFjZSAocmVhbCBkZXZp Y2UgZG9lc24ndCBrbm93IHRoYXQgaXQgaXMgYWN0dWFsbHkgSVBBIGNvbnRpZywgbm90IFBBKQo+ PiBXaGF0J3MgSVBBIGNvbnRpZz8KPj4KPj4gVGhhbmtzLCBSb2dlci4KPj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4gZHJpLWRldmVsIG1haWxpbmcg bGlzdAo+PiBkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCj4+IGh0dHBzOi8vbGlzdHMu ZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCgpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0 CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5mcmVlZGVza3Rv cC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK