From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965632AbbBCN2v (ORCPT ); Tue, 3 Feb 2015 08:28:51 -0500 Received: from mail-wi0-f170.google.com ([209.85.212.170]:37906 "EHLO mail-wi0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965381AbbBCN2s (ORCPT ); Tue, 3 Feb 2015 08:28:48 -0500 MIME-Version: 1.0 In-Reply-To: <20150203122813.GN8656@n2100.arm.linux.org.uk> References: <1422347154-15258-2-git-send-email-sumit.semwal@linaro.org> <20150129143908.GA26493@n2100.arm.linux.org.uk> <20150129154718.GB26493@n2100.arm.linux.org.uk> <20150129192610.GE26493@n2100.arm.linux.org.uk> <20150202165405.GX14009@phenom.ffwll.local> <20150203074856.GF14009@phenom.ffwll.local> <20150203122813.GN8656@n2100.arm.linux.org.uk> From: Christian Gmeiner Date: Tue, 3 Feb 2015 14:28:26 +0100 Message-ID: Subject: Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms To: Russell King - ARM Linux Cc: Daniel Vetter , Linaro Kernel Mailman List , Robin Murphy , LKML , DRI mailing list , Linaro MM SIG Mailman List , "linux-mm@kvack.org" , Marek Szyprowski , Tomasz Stanislawski , "linux-arm-kernel@lists.infradead.org" , "linux-media@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2015-02-03 13:28 GMT+01:00 Russell King - ARM Linux : > On Tue, Feb 03, 2015 at 08:48:56AM +0100, Daniel Vetter wrote: >> On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote: >> > On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter wrote: >> > >> My initial thought is for dma-buf to not try to prevent something than >> > >> an exporter can actually do.. I think the scenario you describe could >> > >> be handled by two sg-lists, if the exporter was clever enough. >> > > >> > > That's already needed, each attachment has it's own sg-list. After all >> > > there's no array of dma_addr_t in the sg tables, so you can't use one sg >> > > for more than one mapping. And due to different iommu different devices >> > > can easily end up with different addresses. >> > >> > >> > Well, to be fair it may not be explicitly stated, but currently one >> > should assume the dma_addr_t's in the dmabuf sglist are bogus. With >> > gpu's that implement per-process/context page tables, I'm not really >> > sure that there is a sane way to actually do anything else.. >> >> Hm, what does per-process/context page tables have to do here? At least on >> i915 we have a two levels of page tables: >> - first level for vm/device isolation, used through dma api >> - 2nd level for per-gpu-context isolation and context switching, handled >> internally. >> >> Since atm the dma api doesn't have any context of contexts or different >> pagetables, I don't see who you could use that at all. > > What I've found with *my* etnaviv drm implementation (not Christian's - I > found it impossible to work with Christian, especially with the endless > "msm doesn't do it that way, so we shouldn't" responses and his attitude > towards cherry-picking my development work [*]) is that it's much easier to > keep the GPU MMU local to the GPU and under the control of the DRM MM code, > rather than attaching the IOMMU to the DMA API and handling it that way. > Keep in mind that I tried to reach you several times via mail and irc and you simply ignored me. Did you know that took almost all of your patches (with small changes)? And I needed to cherry pick you patches as they were a) wrong, b) solved in a different way or c) had "hack" in the subject. I am quite sorry that I ended that way, but it is not only my fault! > There are several reasons for that: > > 1. DRM has a better idea about when the memory needs to be mapped to the > GPU, and it can more effectively manage the GPU MMU. > > 2. The GPU MMU may have TLBs which can only be flushed via a command in > the GPU command stream, so it's fundamentally necessary for the MMU to > be managed by the GPU driver so that it knows when (and how) to insert > the flushes. > > > * - as a direct result of that, I've stopped all further development of > etnaviv drm, and I'm intending to strip it out from my Xorg DDX driver > as the etnaviv drm API which Christian wants is completely incompatible > with the non-etnaviv drm, and that just creates far too much pain in the > DDX driver. > That is bad, but life moves on. greets -- Christian Gmeiner, MSc https://soundcloud.com/christian-gmeiner From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-wi0-f170.google.com ([209.85.212.170]:37906 "EHLO mail-wi0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965381AbbBCN2s (ORCPT ); Tue, 3 Feb 2015 08:28:48 -0500 MIME-Version: 1.0 In-Reply-To: <20150203122813.GN8656@n2100.arm.linux.org.uk> References: <1422347154-15258-2-git-send-email-sumit.semwal@linaro.org> <20150129143908.GA26493@n2100.arm.linux.org.uk> <20150129154718.GB26493@n2100.arm.linux.org.uk> <20150129192610.GE26493@n2100.arm.linux.org.uk> <20150202165405.GX14009@phenom.ffwll.local> <20150203074856.GF14009@phenom.ffwll.local> <20150203122813.GN8656@n2100.arm.linux.org.uk> From: Christian Gmeiner Date: Tue, 3 Feb 2015 14:28:26 +0100 Message-ID: Subject: Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms To: Russell King - ARM Linux Cc: Daniel Vetter , Linaro Kernel Mailman List , Robin Murphy , LKML , DRI mailing list , Linaro MM SIG Mailman List , "linux-mm@kvack.org" , Marek Szyprowski , Tomasz Stanislawski , "linux-arm-kernel@lists.infradead.org" , "linux-media@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-media-owner@vger.kernel.org List-ID: 2015-02-03 13:28 GMT+01:00 Russell King - ARM Linux : > On Tue, Feb 03, 2015 at 08:48:56AM +0100, Daniel Vetter wrote: >> On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote: >> > On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter wrote: >> > >> My initial thought is for dma-buf to not try to prevent something than >> > >> an exporter can actually do.. I think the scenario you describe could >> > >> be handled by two sg-lists, if the exporter was clever enough. >> > > >> > > That's already needed, each attachment has it's own sg-list. After all >> > > there's no array of dma_addr_t in the sg tables, so you can't use one sg >> > > for more than one mapping. And due to different iommu different devices >> > > can easily end up with different addresses. >> > >> > >> > Well, to be fair it may not be explicitly stated, but currently one >> > should assume the dma_addr_t's in the dmabuf sglist are bogus. With >> > gpu's that implement per-process/context page tables, I'm not really >> > sure that there is a sane way to actually do anything else.. >> >> Hm, what does per-process/context page tables have to do here? At least on >> i915 we have a two levels of page tables: >> - first level for vm/device isolation, used through dma api >> - 2nd level for per-gpu-context isolation and context switching, handled >> internally. >> >> Since atm the dma api doesn't have any context of contexts or different >> pagetables, I don't see who you could use that at all. > > What I've found with *my* etnaviv drm implementation (not Christian's - I > found it impossible to work with Christian, especially with the endless > "msm doesn't do it that way, so we shouldn't" responses and his attitude > towards cherry-picking my development work [*]) is that it's much easier to > keep the GPU MMU local to the GPU and under the control of the DRM MM code, > rather than attaching the IOMMU to the DMA API and handling it that way. > Keep in mind that I tried to reach you several times via mail and irc and you simply ignored me. Did you know that took almost all of your patches (with small changes)? And I needed to cherry pick you patches as they were a) wrong, b) solved in a different way or c) had "hack" in the subject. I am quite sorry that I ended that way, but it is not only my fault! > There are several reasons for that: > > 1. DRM has a better idea about when the memory needs to be mapped to the > GPU, and it can more effectively manage the GPU MMU. > > 2. The GPU MMU may have TLBs which can only be flushed via a command in > the GPU command stream, so it's fundamentally necessary for the MMU to > be managed by the GPU driver so that it knows when (and how) to insert > the flushes. > > > * - as a direct result of that, I've stopped all further development of > etnaviv drm, and I'm intending to strip it out from my Xorg DDX driver > as the etnaviv drm API which Christian wants is completely incompatible > with the non-etnaviv drm, and that just creates far too much pain in the > DDX driver. > That is bad, but life moves on. greets -- Christian Gmeiner, MSc https://soundcloud.com/christian-gmeiner From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by kanga.kvack.org (Postfix) with ESMTP id 4CAFC6B0038 for ; Tue, 3 Feb 2015 08:28:48 -0500 (EST) Received: by mail-wi0-f180.google.com with SMTP id h11so21754573wiw.1 for ; Tue, 03 Feb 2015 05:28:47 -0800 (PST) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com. [2a00:1450:400c:c03::231]) by mx.google.com with ESMTPS id o3si28966073wiy.85.2015.02.03.05.28.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Feb 2015 05:28:46 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id l61so44895763wev.8 for ; Tue, 03 Feb 2015 05:28:46 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20150203122813.GN8656@n2100.arm.linux.org.uk> References: <1422347154-15258-2-git-send-email-sumit.semwal@linaro.org> <20150129143908.GA26493@n2100.arm.linux.org.uk> <20150129154718.GB26493@n2100.arm.linux.org.uk> <20150129192610.GE26493@n2100.arm.linux.org.uk> <20150202165405.GX14009@phenom.ffwll.local> <20150203074856.GF14009@phenom.ffwll.local> <20150203122813.GN8656@n2100.arm.linux.org.uk> From: Christian Gmeiner Date: Tue, 3 Feb 2015 14:28:26 +0100 Message-ID: Subject: Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Russell King - ARM Linux Cc: Daniel Vetter , Linaro Kernel Mailman List , Robin Murphy , LKML , DRI mailing list , Linaro MM SIG Mailman List , "linux-mm@kvack.org" , Marek Szyprowski , Tomasz Stanislawski , "linux-arm-kernel@lists.infradead.org" , "linux-media@vger.kernel.org" 2015-02-03 13:28 GMT+01:00 Russell King - ARM Linux : > On Tue, Feb 03, 2015 at 08:48:56AM +0100, Daniel Vetter wrote: >> On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote: >> > On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter wrote: >> > >> My initial thought is for dma-buf to not try to prevent something than >> > >> an exporter can actually do.. I think the scenario you describe could >> > >> be handled by two sg-lists, if the exporter was clever enough. >> > > >> > > That's already needed, each attachment has it's own sg-list. After all >> > > there's no array of dma_addr_t in the sg tables, so you can't use one sg >> > > for more than one mapping. And due to different iommu different devices >> > > can easily end up with different addresses. >> > >> > >> > Well, to be fair it may not be explicitly stated, but currently one >> > should assume the dma_addr_t's in the dmabuf sglist are bogus. With >> > gpu's that implement per-process/context page tables, I'm not really >> > sure that there is a sane way to actually do anything else.. >> >> Hm, what does per-process/context page tables have to do here? At least on >> i915 we have a two levels of page tables: >> - first level for vm/device isolation, used through dma api >> - 2nd level for per-gpu-context isolation and context switching, handled >> internally. >> >> Since atm the dma api doesn't have any context of contexts or different >> pagetables, I don't see who you could use that at all. > > What I've found with *my* etnaviv drm implementation (not Christian's - I > found it impossible to work with Christian, especially with the endless > "msm doesn't do it that way, so we shouldn't" responses and his attitude > towards cherry-picking my development work [*]) is that it's much easier to > keep the GPU MMU local to the GPU and under the control of the DRM MM code, > rather than attaching the IOMMU to the DMA API and handling it that way. > Keep in mind that I tried to reach you several times via mail and irc and you simply ignored me. Did you know that took almost all of your patches (with small changes)? And I needed to cherry pick you patches as they were a) wrong, b) solved in a different way or c) had "hack" in the subject. I am quite sorry that I ended that way, but it is not only my fault! > There are several reasons for that: > > 1. DRM has a better idea about when the memory needs to be mapped to the > GPU, and it can more effectively manage the GPU MMU. > > 2. The GPU MMU may have TLBs which can only be flushed via a command in > the GPU command stream, so it's fundamentally necessary for the MMU to > be managed by the GPU driver so that it knows when (and how) to insert > the flushes. > > > * - as a direct result of that, I've stopped all further development of > etnaviv drm, and I'm intending to strip it out from my Xorg DDX driver > as the etnaviv drm API which Christian wants is completely incompatible > with the non-etnaviv drm, and that just creates far too much pain in the > DDX driver. > That is bad, but life moves on. greets -- Christian Gmeiner, MSc https://soundcloud.com/christian-gmeiner -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: christian.gmeiner@gmail.com (Christian Gmeiner) Date: Tue, 3 Feb 2015 14:28:26 +0100 Subject: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms In-Reply-To: <20150203122813.GN8656@n2100.arm.linux.org.uk> References: <1422347154-15258-2-git-send-email-sumit.semwal@linaro.org> <20150129143908.GA26493@n2100.arm.linux.org.uk> <20150129154718.GB26493@n2100.arm.linux.org.uk> <20150129192610.GE26493@n2100.arm.linux.org.uk> <20150202165405.GX14009@phenom.ffwll.local> <20150203074856.GF14009@phenom.ffwll.local> <20150203122813.GN8656@n2100.arm.linux.org.uk> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 2015-02-03 13:28 GMT+01:00 Russell King - ARM Linux : > On Tue, Feb 03, 2015 at 08:48:56AM +0100, Daniel Vetter wrote: >> On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote: >> > On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter wrote: >> > >> My initial thought is for dma-buf to not try to prevent something than >> > >> an exporter can actually do.. I think the scenario you describe could >> > >> be handled by two sg-lists, if the exporter was clever enough. >> > > >> > > That's already needed, each attachment has it's own sg-list. After all >> > > there's no array of dma_addr_t in the sg tables, so you can't use one sg >> > > for more than one mapping. And due to different iommu different devices >> > > can easily end up with different addresses. >> > >> > >> > Well, to be fair it may not be explicitly stated, but currently one >> > should assume the dma_addr_t's in the dmabuf sglist are bogus. With >> > gpu's that implement per-process/context page tables, I'm not really >> > sure that there is a sane way to actually do anything else.. >> >> Hm, what does per-process/context page tables have to do here? At least on >> i915 we have a two levels of page tables: >> - first level for vm/device isolation, used through dma api >> - 2nd level for per-gpu-context isolation and context switching, handled >> internally. >> >> Since atm the dma api doesn't have any context of contexts or different >> pagetables, I don't see who you could use that at all. > > What I've found with *my* etnaviv drm implementation (not Christian's - I > found it impossible to work with Christian, especially with the endless > "msm doesn't do it that way, so we shouldn't" responses and his attitude > towards cherry-picking my development work [*]) is that it's much easier to > keep the GPU MMU local to the GPU and under the control of the DRM MM code, > rather than attaching the IOMMU to the DMA API and handling it that way. > Keep in mind that I tried to reach you several times via mail and irc and you simply ignored me. Did you know that took almost all of your patches (with small changes)? And I needed to cherry pick you patches as they were a) wrong, b) solved in a different way or c) had "hack" in the subject. I am quite sorry that I ended that way, but it is not only my fault! > There are several reasons for that: > > 1. DRM has a better idea about when the memory needs to be mapped to the > GPU, and it can more effectively manage the GPU MMU. > > 2. The GPU MMU may have TLBs which can only be flushed via a command in > the GPU command stream, so it's fundamentally necessary for the MMU to > be managed by the GPU driver so that it knows when (and how) to insert > the flushes. > > > * - as a direct result of that, I've stopped all further development of > etnaviv drm, and I'm intending to strip it out from my Xorg DDX driver > as the etnaviv drm API which Christian wants is completely incompatible > with the non-etnaviv drm, and that just creates far too much pain in the > DDX driver. > That is bad, but life moves on. greets -- Christian Gmeiner, MSc https://soundcloud.com/christian-gmeiner From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Gmeiner Subject: Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms Date: Tue, 3 Feb 2015 14:28:26 +0100 Message-ID: References: <1422347154-15258-2-git-send-email-sumit.semwal@linaro.org> <20150129143908.GA26493@n2100.arm.linux.org.uk> <20150129154718.GB26493@n2100.arm.linux.org.uk> <20150129192610.GE26493@n2100.arm.linux.org.uk> <20150202165405.GX14009@phenom.ffwll.local> <20150203074856.GF14009@phenom.ffwll.local> <20150203122813.GN8656@n2100.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by gabe.freedesktop.org (Postfix) with ESMTP id 1E2FA6E3AC for ; Tue, 3 Feb 2015 05:28:47 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id n3so24332702wiv.1 for ; Tue, 03 Feb 2015 05:28:46 -0800 (PST) In-Reply-To: <20150203122813.GN8656@n2100.arm.linux.org.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Russell King - ARM Linux Cc: Linaro Kernel Mailman List , Tomasz Stanislawski , LKML , DRI mailing list , Linaro MM SIG Mailman List , "linux-mm@kvack.org" , "linux-media@vger.kernel.org" , Robin Murphy , "linux-arm-kernel@lists.infradead.org" , Marek Szyprowski List-Id: dri-devel@lists.freedesktop.org MjAxNS0wMi0wMyAxMzoyOCBHTVQrMDE6MDAgUnVzc2VsbCBLaW5nIC0gQVJNIExpbnV4IDxsaW51 eEBhcm0ubGludXgub3JnLnVrPjoKPiBPbiBUdWUsIEZlYiAwMywgMjAxNSBhdCAwODo0ODo1NkFN ICswMTAwLCBEYW5pZWwgVmV0dGVyIHdyb3RlOgo+PiBPbiBNb24sIEZlYiAwMiwgMjAxNSBhdCAw MzozMDoyMVBNIC0wNTAwLCBSb2IgQ2xhcmsgd3JvdGU6Cj4+ID4gT24gTW9uLCBGZWIgMiwgMjAx NSBhdCAxMTo1NCBBTSwgRGFuaWVsIFZldHRlciA8ZGFuaWVsQGZmd2xsLmNoPiB3cm90ZToKPj4g PiA+PiBNeSBpbml0aWFsIHRob3VnaHQgaXMgZm9yIGRtYS1idWYgdG8gbm90IHRyeSB0byBwcmV2 ZW50IHNvbWV0aGluZyB0aGFuCj4+ID4gPj4gYW4gZXhwb3J0ZXIgY2FuIGFjdHVhbGx5IGRvLi4g SSB0aGluayB0aGUgc2NlbmFyaW8geW91IGRlc2NyaWJlIGNvdWxkCj4+ID4gPj4gYmUgaGFuZGxl ZCBieSB0d28gc2ctbGlzdHMsIGlmIHRoZSBleHBvcnRlciB3YXMgY2xldmVyIGVub3VnaC4KPj4g PiA+Cj4+ID4gPiBUaGF0J3MgYWxyZWFkeSBuZWVkZWQsIGVhY2ggYXR0YWNobWVudCBoYXMgaXQn cyBvd24gc2ctbGlzdC4gQWZ0ZXIgYWxsCj4+ID4gPiB0aGVyZSdzIG5vIGFycmF5IG9mIGRtYV9h ZGRyX3QgaW4gdGhlIHNnIHRhYmxlcywgc28geW91IGNhbid0IHVzZSBvbmUgc2cKPj4gPiA+IGZv ciBtb3JlIHRoYW4gb25lIG1hcHBpbmcuIEFuZCBkdWUgdG8gZGlmZmVyZW50IGlvbW11IGRpZmZl cmVudCBkZXZpY2VzCj4+ID4gPiBjYW4gZWFzaWx5IGVuZCB1cCB3aXRoIGRpZmZlcmVudCBhZGRy ZXNzZXMuCj4+ID4KPj4gPgo+PiA+IFdlbGwsIHRvIGJlIGZhaXIgaXQgbWF5IG5vdCBiZSBleHBs aWNpdGx5IHN0YXRlZCwgYnV0IGN1cnJlbnRseSBvbmUKPj4gPiBzaG91bGQgYXNzdW1lIHRoZSBk bWFfYWRkcl90J3MgaW4gdGhlIGRtYWJ1ZiBzZ2xpc3QgYXJlIGJvZ3VzLiAgV2l0aAo+PiA+IGdw dSdzIHRoYXQgaW1wbGVtZW50IHBlci1wcm9jZXNzL2NvbnRleHQgcGFnZSB0YWJsZXMsIEknbSBu b3QgcmVhbGx5Cj4+ID4gc3VyZSB0aGF0IHRoZXJlIGlzIGEgc2FuZSB3YXkgdG8gYWN0dWFsbHkg ZG8gYW55dGhpbmcgZWxzZS4uCj4+Cj4+IEhtLCB3aGF0IGRvZXMgcGVyLXByb2Nlc3MvY29udGV4 dCBwYWdlIHRhYmxlcyBoYXZlIHRvIGRvIGhlcmU/IEF0IGxlYXN0IG9uCj4+IGk5MTUgd2UgaGF2 ZSBhIHR3byBsZXZlbHMgb2YgcGFnZSB0YWJsZXM6Cj4+IC0gZmlyc3QgbGV2ZWwgZm9yIHZtL2Rl dmljZSBpc29sYXRpb24sIHVzZWQgdGhyb3VnaCBkbWEgYXBpCj4+IC0gMm5kIGxldmVsIGZvciBw ZXItZ3B1LWNvbnRleHQgaXNvbGF0aW9uIGFuZCBjb250ZXh0IHN3aXRjaGluZywgaGFuZGxlZAo+ PiAgIGludGVybmFsbHkuCj4+Cj4+IFNpbmNlIGF0bSB0aGUgZG1hIGFwaSBkb2Vzbid0IGhhdmUg YW55IGNvbnRleHQgb2YgY29udGV4dHMgb3IgZGlmZmVyZW50Cj4+IHBhZ2V0YWJsZXMsIEkgZG9u J3Qgc2VlIHdobyB5b3UgY291bGQgdXNlIHRoYXQgYXQgYWxsLgo+Cj4gV2hhdCBJJ3ZlIGZvdW5k IHdpdGggKm15KiBldG5hdml2IGRybSBpbXBsZW1lbnRhdGlvbiAobm90IENocmlzdGlhbidzIC0g SQo+IGZvdW5kIGl0IGltcG9zc2libGUgdG8gd29yayB3aXRoIENocmlzdGlhbiwgZXNwZWNpYWxs eSB3aXRoIHRoZSBlbmRsZXNzCj4gIm1zbSBkb2Vzbid0IGRvIGl0IHRoYXQgd2F5LCBzbyB3ZSBz aG91bGRuJ3QiIHJlc3BvbnNlcyBhbmQgaGlzIGF0dGl0dWRlCj4gdG93YXJkcyBjaGVycnktcGlj a2luZyBteSBkZXZlbG9wbWVudCB3b3JrIFsqXSkgaXMgdGhhdCBpdCdzIG11Y2ggZWFzaWVyIHRv Cj4ga2VlcCB0aGUgR1BVIE1NVSBsb2NhbCB0byB0aGUgR1BVIGFuZCB1bmRlciB0aGUgY29udHJv bCBvZiB0aGUgRFJNIE1NIGNvZGUsCj4gcmF0aGVyIHRoYW4gYXR0YWNoaW5nIHRoZSBJT01NVSB0 byB0aGUgRE1BIEFQSSBhbmQgaGFuZGxpbmcgaXQgdGhhdCB3YXkuCj4KCktlZXAgaW4gbWluZCB0 aGF0IEkgdHJpZWQgdG8gcmVhY2ggeW91IHNldmVyYWwgdGltZXMgdmlhIG1haWwgYW5kIGlyYwph bmQgeW91IHNpbXBseQppZ25vcmVkIG1lLiBEaWQgeW91IGtub3cgdGhhdCB0b29rIGFsbW9zdCBh bGwgb2YgeW91ciBwYXRjaGVzICh3aXRoCnNtYWxsIGNoYW5nZXMpPwpBbmQgSSBuZWVkZWQgdG8g Y2hlcnJ5IHBpY2sgeW91IHBhdGNoZXMgYXMgdGhleSB3ZXJlIGEpIHdyb25nLCBiKSBzb2x2ZWQg aW4gYQpkaWZmZXJlbnQgd2F5IG9yIGMpIGhhZCAiaGFjayIgaW4gdGhlIHN1YmplY3QuIEkgYW0g cXVpdGUgc29ycnkgdGhhdCBJCmVuZGVkIHRoYXQKd2F5LCBidXQgaXQgaXMgbm90IG9ubHkgbXkg ZmF1bHQhCgo+IFRoZXJlIGFyZSBzZXZlcmFsIHJlYXNvbnMgZm9yIHRoYXQ6Cj4KPiAxLiBEUk0g aGFzIGEgYmV0dGVyIGlkZWEgYWJvdXQgd2hlbiB0aGUgbWVtb3J5IG5lZWRzIHRvIGJlIG1hcHBl ZCB0byB0aGUKPiAgICBHUFUsIGFuZCBpdCBjYW4gbW9yZSBlZmZlY3RpdmVseSBtYW5hZ2UgdGhl IEdQVSBNTVUuCj4KPiAyLiBUaGUgR1BVIE1NVSBtYXkgaGF2ZSBUTEJzIHdoaWNoIGNhbiBvbmx5 IGJlIGZsdXNoZWQgdmlhIGEgY29tbWFuZCBpbgo+ICAgIHRoZSBHUFUgY29tbWFuZCBzdHJlYW0s IHNvIGl0J3MgZnVuZGFtZW50YWxseSBuZWNlc3NhcnkgZm9yIHRoZSBNTVUgdG8KPiAgICBiZSBt YW5hZ2VkIGJ5IHRoZSBHUFUgZHJpdmVyIHNvIHRoYXQgaXQga25vd3Mgd2hlbiAoYW5kIGhvdykg dG8gaW5zZXJ0Cj4gICAgdGhlIGZsdXNoZXMuCj4KPgo+ICogLSBhcyBhIGRpcmVjdCByZXN1bHQg b2YgdGhhdCwgSSd2ZSBzdG9wcGVkIGFsbCBmdXJ0aGVyIGRldmVsb3BtZW50IG9mCj4gZXRuYXZp diBkcm0sIGFuZCBJJ20gaW50ZW5kaW5nIHRvIHN0cmlwIGl0IG91dCBmcm9tIG15IFhvcmcgRERY IGRyaXZlcgo+IGFzIHRoZSBldG5hdml2IGRybSBBUEkgd2hpY2ggQ2hyaXN0aWFuIHdhbnRzIGlz IGNvbXBsZXRlbHkgaW5jb21wYXRpYmxlCj4gd2l0aCB0aGUgbm9uLWV0bmF2aXYgZHJtLCBhbmQg dGhhdCBqdXN0IGNyZWF0ZXMgZmFyIHRvbyBtdWNoIHBhaW4gaW4gdGhlCj4gRERYIGRyaXZlci4K PgoKVGhhdCBpcyBiYWQsIGJ1dCBsaWZlIG1vdmVzIG9uLgoKZ3JlZXRzCi0tCkNocmlzdGlhbiBH bWVpbmVyLCBNU2MKCmh0dHBzOi8vc291bmRjbG91ZC5jb20vY2hyaXN0aWFuLWdtZWluZXIKX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVsIG1h aWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0cy5m cmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK