From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752810AbeDRKV2 (ORCPT ); Wed, 18 Apr 2018 06:21:28 -0400 Received: from mail-lf0-f41.google.com ([209.85.215.41]:42674 "EHLO mail-lf0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750861AbeDRKV1 (ORCPT ); Wed, 18 Apr 2018 06:21:27 -0400 X-Google-Smtp-Source: AIpwx49gKI0WZfdyhmMX39x7EeHFCE1s8OHKsBAP4RF2QfnVZ2NRb3Yg6DhbYtAWmbaOC5u9+LQ0Yg== Subject: Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver To: Paul Durrant , Roger Pau Monne Cc: "jgross@suse.com" , Artem Mygaiev , Dongwon Kim , "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" , Matt Roper 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> <7d6710a76b9a42299139d7914358ed52@AMSPEX02CL03.citrite.net> From: Oleksandr Andrushchenko Message-ID: <3c56505c-8f03-e49b-a995-a2118d255164@gmail.com> Date: Wed, 18 Apr 2018 13:21:23 +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: <7d6710a76b9a42299139d7914358ed52@AMSPEX02CL03.citrite.net> 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/18/2018 01:18 PM, Paul Durrant wrote: >> -----Original Message----- >> From: Xen-devel [mailto:xen-devel-bounces@lists.xenproject.org] On Behalf >> Of Roger Pau Monné >> Sent: 18 April 2018 11:11 >> To: Oleksandr Andrushchenko >> Cc: jgross@suse.com; Artem Mygaiev ; >> Dongwon Kim ; 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; Matt Roper >> >> Subject: Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy >> helper DRM driver >> >> 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. >> >>> 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? > I assume 'IPA' means 'IOMMU Physical Address'. I wonder whether this means what I've termed 'Bus Address' elsewhere? sorry for not being clear here: I mean that the device sees contiguous range of Intermediate Phys Addresses > Paul > >> Thanks, Roger. >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xenproject.org >> https://lists.xenproject.org/mailman/listinfo/xen-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: Wed, 18 Apr 2018 13:21:23 +0300 Message-ID: <3c56505c-8f03-e49b-a995-a2118d255164@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> <7d6710a76b9a42299139d7914358ed52@AMSPEX02CL03.citrite.net> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) by gabe.freedesktop.org (Postfix) with ESMTPS id 68D9B8921C for ; Wed, 18 Apr 2018 10:21:27 +0000 (UTC) Received: by mail-lf0-x22e.google.com with SMTP id r7-v6so1841746lfr.1 for ; Wed, 18 Apr 2018 03:21:27 -0700 (PDT) In-Reply-To: <7d6710a76b9a42299139d7914358ed52@AMSPEX02CL03.citrite.net> 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: Paul Durrant , Roger Pau Monne Cc: "jgross@suse.com" , Artem Mygaiev , Dongwon Kim , "Oleksandr_Andrushchenko@epam.com" , "airlied@linux.ie" , "linux-kernel@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , "Potrola, MateuszX" , "daniel.vetter@intel.com" , "xen-devel@lists.xenproject.org" , "boris.ostrovsky@oracle.com" List-Id: dri-devel@lists.freedesktop.org T24gMDQvMTgvMjAxOCAwMToxOCBQTSwgUGF1bCBEdXJyYW50IHdyb3RlOgo+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQo+PiBGcm9tOiBYZW4tZGV2ZWwgW21haWx0bzp4ZW4tZGV2ZWwtYm91 bmNlc0BsaXN0cy54ZW5wcm9qZWN0Lm9yZ10gT24gQmVoYWxmCj4+IE9mIFJvZ2VyIFBhdSBNb25u w6kKPj4gU2VudDogMTggQXByaWwgMjAxOCAxMToxMQo+PiBUbzogT2xla3NhbmRyIEFuZHJ1c2hj aGVua28gPGFuZHIyMDAwQGdtYWlsLmNvbT4KPj4gQ2M6IGpncm9zc0BzdXNlLmNvbTsgQXJ0ZW0g TXlnYWlldiA8QXJ0ZW1fTXlnYWlldkBlcGFtLmNvbT47Cj4+IERvbmd3b24gS2ltIDxkb25nd29u LmtpbUBpbnRlbC5jb20+OyBhaXJsaWVkQGxpbnV4LmllOwo+PiBPbGVrc2FuZHJfQW5kcnVzaGNo ZW5rb0BlcGFtLmNvbTsgbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZzsgZHJpLQo+PiBkZXZl bEBsaXN0cy5mcmVlZGVza3RvcC5vcmc7IFBvdHJvbGEsIE1hdGV1c3pYCj4+IDxtYXRldXN6eC5w b3Ryb2xhQGludGVsLmNvbT47IHhlbi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZzsKPj4gZGFu aWVsLnZldHRlckBpbnRlbC5jb207IGJvcmlzLm9zdHJvdnNreUBvcmFjbGUuY29tOyBNYXR0IFJv cGVyCj4+IDxtYXR0aGV3LmQucm9wZXJAaW50ZWwuY29tPgo+PiBTdWJqZWN0OiBSZTogW1hlbi1k ZXZlbF0gW1BBVENIIDAvMV0gZHJtL3hlbi16Y29weTogQWRkIFhlbiB6ZXJvLWNvcHkKPj4gaGVs cGVyIERSTSBkcml2ZXIKPj4KPj4gT24gV2VkLCBBcHIgMTgsIDIwMTggYXQgMTE6MDE6MTJBTSAr MDMwMCwgT2xla3NhbmRyIEFuZHJ1c2hjaGVua28KPj4gd3JvdGU6Cj4+PiBPbiAwNC8xOC8yMDE4 IDEwOjM1IEFNLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+Pj4+IE9uIFdlZCwgQXByIDE4LCAy MDE4IGF0IDA5OjM4OjM5QU0gKzAzMDAsIE9sZWtzYW5kciBBbmRydXNoY2hlbmtvCj4+IHdyb3Rl Ogo+Pj4+PiBPbiAwNC8xNy8yMDE4IDExOjU3IFBNLCBEb25nd29uIEtpbSB3cm90ZToKPj4+Pj4+ IE9uIFR1ZSwgQXByIDE3LCAyMDE4IGF0IDA5OjU5OjI4QU0gKzAyMDAsIERhbmllbCBWZXR0ZXIg d3JvdGU6Cj4+Pj4+Pj4gT24gTW9uLCBBcHIgMTYsIDIwMTggYXQgMTI6Mjk6MDVQTSAtMDcwMCwg RG9uZ3dvbiBLaW0gd3JvdGU6Cj4+Pj4+IDMuMiBCYWNrZW5kIGV4cG9ydHMgZG1hLWJ1ZiB0byB4 ZW4tZnJvbnQKPj4+Pj4KPj4+Pj4gSW4gdGhpcyBjYXNlIERvbTAgcGFnZXMgYXJlIHNoYXJlZCB3 aXRoIERvbVUuIEFzIGJlZm9yZSwgRG9tVSBjYW4KPj4gb25seSB3cml0ZQo+Pj4+PiB0byB0aGVz ZSBwYWdlcywgbm90IGFueSBvdGhlciBwYWdlIGZyb20gRG9tMCwgc28gaXQgY2FuIGJlIHN0aWxs Cj4+IGNvbnNpZGVyZWQKPj4+Pj4gc2FmZS4KPj4+Pj4gQnV0LCB0aGUgZm9sbG93aW5nIG11c3Qg YmUgY29uc2lkZXJlZCAoaGlnaGxpZ2h0ZWQgaW4geGVuLWZyb250J3MgS2VybmVsCj4+Pj4+IGRv Y3VtZW50YXRpb24pOgo+Pj4+PiAgIMKgLSBJZiBndWVzdCBkb21haW4gZGllcyB0aGVuIHBhZ2Vz L2dyYW50cyByZWNlaXZlZCBmcm9tIHRoZSBiYWNrZW5kCj4+IGNhbm5vdAo+Pj4+PiAgIMKgwqAg YmUgY2xhaW1lZCBiYWNrIC0gdGhpbmsgb2YgaXQgYXMgbWVtb3J5IGxvc3QgdG8gRG9tMCAod29u J3QgYmUgdXNlZAo+PiBmb3IKPj4+Pj4gYW55Cj4+Pj4+ICAgwqDCoCBvdGhlciBndWVzdCkKPj4+ Pj4gICDCoC0gTWlzYmVoYXZpbmcgZ3Vlc3QgbWF5IHNlbmQgdG9vIG1hbnkgcmVxdWVzdHMgdG8g dGhlIGJhY2tlbmQKPj4gZXhoYXVzdGluZwo+Pj4+PiAgIMKgwqAgaXRzIGdyYW50IHJlZmVyZW5j ZXMgYW5kIG1lbW9yeSAoY29uc2lkZXIgdGhpcyBmcm9tIHNlY3VyaXR5IFBPVikuCj4+IEFzIHRo ZQo+Pj4+PiAgIMKgwqAgYmFja2VuZCBydW5zIGluIHRoZSB0cnVzdGVkIGRvbWFpbiB3ZSBhbHNv IGFzc3VtZSB0aGF0IGl0IGlzIHRydXN0ZWQKPj4gYXMKPj4+Pj4gd2VsbCwKPj4+Pj4gICDCoMKg IGUuZy4gbXVzdCB0YWtlIG1lYXN1cmVzIHRvIHByZXZlbnQgRERvUyBhdHRhY2tzLgo+Pj4+IEkg Y2Fubm90IHBhcnNlIHRoZSBhYm92ZSBzZW50ZW5jZToKPj4+Pgo+Pj4+ICJBcyB0aGUgYmFja2Vu ZCBydW5zIGluIHRoZSB0cnVzdGVkIGRvbWFpbiB3ZSBhbHNvIGFzc3VtZSB0aGF0IGl0IGlzCj4+ Pj4gdHJ1c3RlZCBhcyB3ZWxsLCBlLmcuIG11c3QgdGFrZSBtZWFzdXJlcyB0byBwcmV2ZW50IERE b1MgYXR0YWNrcy4iCj4+Pj4KPj4+PiBXaGF0J3MgdGhlIHJlbGF0aW9uIGJldHdlZW4gYmVpbmcg dHJ1c3RlZCBhbmQgcHJvdGVjdGluZyBmcm9tIERvUwo+Pj4+IGF0dGFja3M/Cj4+PiBJIG1lYW4g dGhhdCB3ZSB0cnVzdCB0aGUgYmFja2VuZCB0aGF0IGl0IGNhbiBwcmV2ZW50IERvbTAKPj4+IGZy b20gY3Jhc2hpbmcgaW4gY2FzZSBEb21VJ3MgZnJvbnRlbmQgbWlzYmVoYXZlcywgZS5nLgo+Pj4g aWYgdGhlIGZyb250ZW5kIHNlbmRzIHRvbyBtYW55IG1lbW9yeSByZXF1ZXN0cyBldGMuCj4+Pj4g SW4gYW55IGNhc2UsIGFsbD8gUFYgcHJvdG9jb2xzIGFyZSBpbXBsZW1lbnRlZCB3aXRoIHRoZSBm cm9udGVuZAo+Pj4+IHNoYXJpbmcgcGFnZXMgdG8gdGhlIGJhY2tlbmQsIGFuZCBJIHRoaW5rIHRo ZXJlJ3MgYSByZWFzb24gd2h5IHRoaXMKPj4+PiBtb2RlbCBpcyB1c2VkLCBhbmQgaXQgc2hvdWxk IGNvbnRpbnVlIHRvIGJlIHVzZWQuCj4+PiBUaGlzIGlzIHRoZSBmaXJzdCB1c2UtY2FzZSBhYm92 ZS4gQnV0IHRoZXJlIGFyZSByZWFsLXdvcmxkCj4+PiB1c2UtY2FzZXMgKGVtYmVkZGVkIGluIG15 IGNhc2UpIHdoZW4gcGh5c2ljYWxseSBjb250aWd1b3VzIG1lbW9yeQo+Pj4gbmVlZHMgdG8gYmUg c2hhcmVkLCBvbmUgb2YgdGhlIHBvc3NpYmxlIHdheXMgdG8gYWNoaWV2ZSB0aGlzIGlzCj4+PiB0 byBzaGFyZSBjb250aWd1b3VzIG1lbW9yeSBmcm9tIERvbTAgdG8gRG9tVSAodGhlIHNlY29uZCB1 c2UtY2FzZQo+PiBhYm92ZSkKPj4+PiBIYXZpbmcgdG8gYWRkIGxvZ2ljIGluIHRoZSBiYWNrZW5k IHRvIHByZXZlbnQgc3VjaCBhdHRhY2tzIG1lYW5zCj4+Pj4gdGhhdDoKPj4+Pgo+Pj4+ICAgIC0g V2UgbmVlZCBtb3JlIGNvZGUgaW4gdGhlIGJhY2tlbmQsIHdoaWNoIGluY3JlYXNlcyBjb21wbGV4 aXR5IGFuZAo+Pj4+ICAgICAgY2hhbmNlcyBvZiBidWdzLgo+Pj4+ICAgIC0gU3VjaCBjb2RlL2xv Z2ljIGNvdWxkIGJlIHdyb25nLCB0aHVzIGFsbG93aW5nIERvUy4KPj4+IFlvdSBjYW4gbGl2ZSB3 aXRob3V0IHRoaXMgY29kZSBhdCBhbGwsIGJ1dCB0aGlzIGlzIHRoZW4gdXAgdG8KPj4+IGJhY2tl bmQgd2hpY2ggbWF5IG1ha2UgRG9tMCBkb3duIGJlY2F1c2Ugb2YgRG9tVSdzIGZyb250ZW5kIGRv aW5nCj4+IGV2aWwKPj4+IHRoaW5ncwo+PiBJTU8gd2Ugc2hvdWxkIGRlc2lnbiBwcm90b2NvbHMg dGhhdCBkbyBub3QgYWxsb3cgc3VjaCBhdHRhY2tzIGluc3RlYWQKPj4gb2YgaGF2aW5nIHRvIGRl ZmVuZCBhZ2FpbnN0IHRoZW0uCj4+Cj4+Pj4+IDQuIHhlbi1mcm9udC9iYWNrZW5kL3hlbi16Y29w eSBzeW5jaHJvbml6YXRpb24KPj4+Pj4KPj4+Pj4gNC4xLiBBcyBJIGFscmVhZHkgc2FpZCBpbiAy KSBhbGwgdGhlIGludGVyIFZNIGNvbW11bmljYXRpb24gaGFwcGVucwo+PiBiZXR3ZWVuCj4+Pj4+ IHhlbi1mcm9udCBhbmQgdGhlIGJhY2tlbmQsIHhlbi16Y29weSBpcyBOT1QgaW52b2x2ZWQgaW4g dGhhdC4KPj4+Pj4gV2hlbiB4ZW4tZnJvbnQgd2FudHMgdG8gZGVzdHJveSBhIGRpc3BsYXkgYnVm ZmVyIChkdW1iL2RtYS1idWYpIGl0Cj4+IGlzc3VlcyBhCj4+Pj4+IFhFTkRJU1BMX09QX0RCVUZf REVTVFJPWSBjb21tYW5kIChvcHBvc2l0ZSB0bwo+PiBYRU5ESVNQTF9PUF9EQlVGX0NSRUFURSku Cj4+Pj4+IFRoaXMgY2FsbCBpcyBzeW5jaHJvbm91cywgc28geGVuLWZyb250IGV4cGVjdHMgdGhh dCBiYWNrZW5kIGRvZXMgZnJlZQo+PiB0aGUKPj4+Pj4gYnVmZmVyIHBhZ2VzIG9uIHJldHVybi4K Pj4+Pj4KPj4+Pj4gNC4yLiBCYWNrZW5kLCBvbiBYRU5ESVNQTF9PUF9EQlVGX0RFU1RST1k6Cj4+ Pj4+ICAgwqAgLSBjbG9zZXMgYWxsIGR1bWIgaGFuZGxlcy9mZCdzIG9mIHRoZSBidWZmZXIgYWNj b3JkaW5nIHRvIFszXQo+Pj4+PiAgIMKgIC0gaXNzdWVzIERSTV9JT0NUTF9YRU5fWkNPUFlfRFVN Ql9XQUlUX0ZSRUUgSU9DVEwgdG8geGVuLQo+PiB6Y29weSB0byBtYWtlCj4+Pj4+IHN1cmUKPj4+ Pj4gICDCoMKgwqAgdGhlIGJ1ZmZlciBpcyBmcmVlZCAodGhpbmsgb2YgaXQgYXMgaXQgd2FpdHMg Zm9yIGRtYS1idWYtPnJlbGVhc2UKPj4+Pj4gY2FsbGJhY2spCj4+Pj4gU28gdGhpcyB6Y29weSB0 aGluZyBrZWVwcyBzb21lIGtpbmQgb2YgdHJhY2sgb2YgdGhlIG1lbW9yeSB1c2FnZT8gV2h5Cj4+ Pj4gY2FuJ3QgdGhlIHVzZXItc3BhY2UgYmFja2VuZCBrZWVwIHRyYWNrIG9mIHRoZSBidWZmZXIg dXNhZ2U/Cj4+PiBCZWNhdXNlIHRoZXJlIGlzIG5vIGRtYS1idWYgVUFQSSB3aGljaCBhbGxvd3Mg dG8gdHJhY2sgdGhlIGJ1ZmZlciBsaWZlIGN5Y2xlCj4+PiAoZS5nLiB3YWl0IHVudGlsIGRtYS1i dWYncyAucmVsZWFzZSBjYWxsYmFjayBpcyBjYWxsZWQpCj4+Pj4+ICAgwqAgLSByZXBsaWVzIHRv IHhlbi1mcm9udCB0aGF0IHRoZSBidWZmZXIgY2FuIGJlIGRlc3Ryb3llZC4KPj4+Pj4gVGhpcyB3 YXkgZGVsZXRpb24gb2YgdGhlIGJ1ZmZlciBoYXBwZW5zIHN5bmNocm9ub3VzbHkgb24gYm90aCBE b20wCj4+IGFuZCBEb21VCj4+Pj4+IHNpZGVzLiBJbiBjYXNlIGlmIERSTV9JT0NUTF9YRU5fWkNP UFlfRFVNQl9XQUlUX0ZSRUUgcmV0dXJucwo+PiB3aXRoIHRpbWUtb3V0Cj4+Pj4+IGVycm9yCj4+ Pj4+IChCVFcsIHdhaXQgdGltZSBpcyBhIHBhcmFtZXRlciBvZiB0aGlzIElPQ1RMKSwgWGVuIHdp bGwgZGVmZXIgZ3JhbnQKPj4+Pj4gcmVmZXJlbmNlCj4+Pj4+IHJlbW92YWwgYW5kIHdpbGwgcmV0 cnkgbGF0ZXIgdW50aWwgdGhvc2UgYXJlIGZyZWUuCj4+Pj4+Cj4+Pj4+IEhvcGUgdGhpcyBoZWxw cyB1bmRlcnN0YW5kIGhvdyBidWZmZXJzIGFyZSBzeW5jaHJvbm91c2x5IGRlbGV0ZWQgaW4KPj4g Y2FzZQo+Pj4+PiBvZiB4ZW4temNvcHkgd2l0aCBhIHNpbmdsZSBwcm90b2NvbCBjb21tYW5kLgo+ Pj4+Pgo+Pj4+PiBJIHRoaW5rIHRoZSBhYm92ZSBsb2dpYyBjYW4gYWxzbyBiZSByZS11c2VkIGJ5 IHRoZSBoeXBlci1kbWFidWYgZHJpdmVyCj4+IHdpdGgKPj4+Pj4gc29tZSBhZGRpdGlvbmFsIHdv cms6Cj4+Pj4+Cj4+Pj4+IDEuIHhlbi16Y29weSBjYW4gYmUgc3BsaXQgaW50byAyIHBhcnRzIGFu ZCBleHRlbmQ6Cj4+Pj4+IDEuMS4gWGVuIGdudGRldiBkcml2ZXIgWzRdLCBbNV0gdG8gYWxsb3cg Y3JlYXRpbmcgZG1hLWJ1ZiBmcm9tIGdyZWZzIGFuZAo+Pj4+PiB2aXNlIHZlcnNhLAo+Pj4+IEkg ZG9uJ3Qga25vdyBtdWNoIGFib3V0IHRoZSBkbWEtYnVmIGltcGxlbWVudGF0aW9uIGluIExpbnV4 LCBidXQKPj4+PiBnbnRkZXYgaXMgYSB1c2VyLXNwYWNlIGRldmljZSwgYW5kIEFGQUlDVCB1c2Vy LXNwYWNlIGFwcGxpY2F0aW9ucwo+Pj4+IGRvbid0IGhhdmUgYW55IG5vdGlvbiBvZiBkbWEgYnVm ZmVycy4gSG93IGFyZSBzdWNoIGJ1ZmZlcnMgdXNlZnVsIGZvcgo+Pj4+IHVzZXItc3BhY2U/IFdo eSBjYW4ndCB0aGlzIGp1c3QgYmUgY2FsbGVkIG1lbW9yeT8KPj4+IEEgZG1hLWJ1ZiBpcyBzZWVu IGJ5IHVzZXItc3BhY2UgYXMgYSBmaWxlIGRlc2NyaXB0b3IgYW5kIHlvdSBjYW4KPj4+IHBhc3Mg aXQgdG8gZGlmZmVyZW50IGRyaXZlcnMgdGhlbi4gRm9yIGV4YW1wbGUsIHlvdSBjYW4gc2hhcmUg YSBidWZmZXIKPj4+IHVzZWQgYnkgYSBkaXNwbGF5IGRyaXZlciBmb3Igc2Nhbm91dCB3aXRoIGEg R1BVLCB0byBjb21wb3NlIGEgcGljdHVyZQo+Pj4gaW50byBpdDoKPj4+IDEuIFVzZXItc3BhY2Ug KFVTKSBhbGxvY2F0ZXMgYSBkaXNwbGF5IGJ1ZmZlciBmcm9tIGRpc3BsYXkgZHJpdmVyCj4+PiAy LiBVUyBhc2tzIGRpc3BsYXkgZHJpdmVyIHRvIGV4cG9ydCB0aGUgZG1hLWJ1ZiB3aGljaCBiYWNr cyB1cCB0aGF0IGJ1ZmZlciwKPj4+IFVTIGdldHMgYnVmZmVyJ3MgZmQ6IGRtYV9idWZfZmQKPj4+ IDMuIFVTIGFza3MgR1BVIGRyaXZlciB0byBpbXBvcnQgYSBidWZmZXIgYW5kIHByb3ZpZGVzIGl0 IHdpdGggZG1hX2J1Zl9mZAo+Pj4gNC4gR1BVIHJlbmRlcnMgY29udGVudHMgaW50byBkaXNwbGF5 IGJ1ZmZlciAoZG1hX2J1Zl9mZCkKPj4gQWZ0ZXIgc3BlYWtpbmcgd2l0aCBPbGVrc2FuZHIgb24g SVJDLCBJIHRoaW5rIHRoZSBtYWluIHVzYWdlIG9mIHRoZQo+PiBnbnRkZXYgZXh0ZW5zaW9uIGlz IHRvOgo+Pgo+PiAxLiBDcmVhdGUgYSBkbWEtYnVmIGZyb20gYSBzZXQgb2YgZ3JhbnQgcmVmZXJl bmNlcy4KPj4gMi4gU2hhcmUgZG1hLWJ1ZiBhbmQgZ2V0IGEgbGlzdCBvZiBncmFudCByZWZlcmVu Y2VzLgo+Pgo+PiBJIHRoaW5rIHRoaXMgc2V0IG9mIG9wZXJhdGlvbnMgY291bGQgYmUgYnJva2Vu IGludG86Cj4+Cj4+IDEuMSBNYXAgZ3JhbnQgcmVmZXJlbmNlcyBpbnRvIHVzZXItc3BhY2UgdXNp bmcgdGhlIGdudGRldi4KPj4gMS4yIENyZWF0ZSBhIGRtYS1idWYgb3V0IG9mIGEgc2V0IG9mIHVz ZXItc3BhY2UgdmlydHVhbCBhZGRyZXNzZXMuCj4+Cj4+IDIuMSBNYXAgYSBkbWEtYnVmIGludG8g dXNlci1zcGFjZS4KPj4gMi4yIEdldCBncmVmcyBvdXQgb2YgdGhlIHVzZXItc3BhY2UgYWRkcmVz c2VzIHdoZXJlIHRoZSBkbWEtYnVmIGlzCj4+ICAgICAgbWFwcGVkLgo+Pgo+PiBTbyBpdCBzZWVt cyBsaWtlIHdoYXQncyBhY3R1YWxseSBtaXNzaW5nIGlzIGEgd2F5IHRvOgo+Pgo+PiAgIC0gQ3Jl YXRlIGEgZG1hLWJ1ZiBmcm9tIGEgbGlzdCBvZiB1c2VyLXNwYWNlIHZpcnR1YWwgYWRkcmVzc2Vz Lgo+PiAgIC0gQWxsb3cgdG8gbWFwIGEgZG1hLWJ1ZiBpbnRvIHVzZXItc3BhY2UsIHNvIGl0IGNh biB0aGVuIGJlIHVzZWQgd2l0aAo+PiAgICAgdGhlIGdudGRldi4KPj4KPj4gSSB0aGluayB0aGlz IGlzIGdlbmVyaWMgZW5vdWdoIHRoYXQgaXQgY291bGQgYmUgaW1wbGVtZW50ZWQgYnkgYQo+PiBk ZXZpY2Ugbm90IHRpZWQgdG8gWGVuLiBBRkFJQ1QgdGhlIGh5cGVyX2RtYSBndXlzIGFsc28gd2Fu dGVkCj4+IHNvbWV0aGluZyBzaW1pbGFyIHRvIHRoaXMuCj4+Cj4+PiBGaW5hbGx5LCB0aGlzIGlz IGluZGVlZCBzb21lIG1lbW9yeSwgYnV0IGEgYml0IG1vcmUgWzFdCj4+Pj4gQWxzbywgKHdpdGgg bXkgRnJlZUJTRCBtYWludGFpbmVyIGhhdCkgaG93IGlzIHRoaXMgZ29pbmcgdG8gdHJhbnNsYXRl Cj4+Pj4gdG8gb3RoZXIgT1Nlcz8gU28gZmFyIHRoZSBvcGVyYXRpb25zIHBlcmZvcm1lZCBieSB0 aGUgZ250ZGV2IGRldmljZQo+Pj4+IGFyZSBtb3N0bHkgT1MtYWdub3N0aWMgYmVjYXVzZSB0aGlz IGp1c3QgbWFwL3VubWFwIG1lbW9yeSwgYW5kIGluIGZhY3QKPj4+PiB0aGV5IGFyZSBpbXBsZW1l bnRlZCBieSBMaW51eCBhbmQgRnJlZUJTRC4KPj4+IEF0IHRoZSBtb21lbnQgSSBjYW4gb25seSBz ZWUgTGludXggaW1wbGVtZW50YXRpb24gYW5kIGl0IHNlZW1zCj4+PiB0byBiZSBwZXJmZWN0bHkg b2sgYXMgd2UgZG8gbm90IGNoYW5nZSBYZW4ncyBBUElzIGV0Yy4gYW5kIG9ubHkKPj4+IHVzZSB0 aGUgZXhpc3Rpbmcgb25lcyAocmVtZW1iZXIsIHdlIG9ubHkgZXh0ZW5kIGdudGRldi9iYWxsb29u Cj4+PiBkcml2ZXJzLCBhbGwgdGhlIGNoYW5nZXMgaW4gdGhlIExpbnV4IGtlcm5lbCkKPj4+IEFz IHRoZSBzZWNvbmQgbm90ZSBJIGNhbiBhbHNvIHRoaW5rIHRoYXQgd2UgZG8gbm90IGV4dGVuZCBn bnRkZXYvYmFsbG9vbgo+Pj4gZHJpdmVycyBhbmQgaGF2ZSByZS13b3JrZWQgeGVuLXpjb3B5IGRy aXZlciBiZSBhIHNlcGFyYXRlIGVudGl0eSwKPj4+IHNheSBkcml2ZXJzL3hlbi9kbWEtYnVmCj4+ Pj4+IGltcGxlbWVudCAid2FpdCIgaW9jdGwgKHdhaXQgZm9yIGRtYS1idWYtPnJlbGVhc2UpOiBj dXJyZW50bHkgdGhlc2UgYXJlCj4+Pj4+IERSTV9YRU5fWkNPUFlfRFVNQl9GUk9NX1JFRlMsCj4+ 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 cyBpbiBob3N0IHBoeXNpY2FsIG1lbW9yeSBzcGFjZT8gVGhlIElPTU1VIHNob3VsZCBoaWRlCj4+ IGFsbAo+Pj4+IHRoaXMuCj4+PiBUaGVyZSBhcmUgZHJpdmVycy9IVyB3aGljaCBjYW4gb25seSB3 b3JrIHdpdGggY29udGlnIG1lbW9yeSBhbmQKPj4+IGlmIGl0IGlzIGJhY2tlZCBieSBhbiBJT01N VSB0aGVuIHN0aWxsIGl0IGhhcyB0byBiZSBjb250aWcgaW4gSVBBCj4+PiBzcGFjZSAocmVhbCBk ZXZpY2UgZG9lc24ndCBrbm93IHRoYXQgaXQgaXMgYWN0dWFsbHkgSVBBIGNvbnRpZywgbm90IFBB KQo+PiBXaGF0J3MgSVBBIGNvbnRpZz8KPiBJIGFzc3VtZSAnSVBBJyBtZWFucyAnSU9NTVUgUGh5 c2ljYWwgQWRkcmVzcycuIEkgd29uZGVyIHdoZXRoZXIgdGhpcyBtZWFucyB3aGF0IEkndmUgdGVy bWVkICdCdXMgQWRkcmVzcycgZWxzZXdoZXJlPwpzb3JyeSBmb3Igbm90IGJlaW5nIGNsZWFyIGhl cmU6IEkgbWVhbiB0aGF0IHRoZSBkZXZpY2Ugc2VlcyBjb250aWd1b3VzIApyYW5nZSBvZgpJbnRl cm1lZGlhdGUgUGh5cyBBZGRyZXNzZXMKPiAgICBQYXVsCj4KPj4gVGhhbmtzLCBSb2dlci4KPj4K Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4gWGVu LWRldmVsIG1haWxpbmcgbGlzdAo+PiBYZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKPj4g aHR0cHM6Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hlbi1kZXZlbAoK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg==