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=-5.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 0DD29C433DB for ; Thu, 28 Jan 2021 11:47:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C357C64DDB for ; Thu, 28 Jan 2021 11:47:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229618AbhA1Lrc (ORCPT ); Thu, 28 Jan 2021 06:47:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36434 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229569AbhA1Lrb (ORCPT ); Thu, 28 Jan 2021 06:47:31 -0500 Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8C728C061573 for ; Thu, 28 Jan 2021 03:46:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kapsi.fi; s=20161220; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=dCyaZBCtvjV1qTeH92823cziiRnr3JFyyEXR29NWh0Q=; b=jxJOoaJh+F/a/xzG22iFj0HTkA vVal6qmTshH4Pb4FvhFDfOY7cYfdeWzvC7u6hAFAveGa34W/AvrJzk+fcAe6doQpq9n+N8inu1iEe 6/MWhxoHfYE25LzF/sU7GhbjG+VcKgbc5US9bdqme4gBxFGQ6znE2PlU22GjBdDb60ZRXwwyejGmc qcWSuhiLB8Rf2u6J/p2eO08vuh+fl8QAGTeDwrF0T4AOuUGaqBKwPLWVeusyf/wVOEl1lSxUWXJhp 34G4h1H3XEPWbgEPDzNp3CdnH8624fFqF9NBm6DH7+7AeRS/uB8Mj1a7XxUdNpMoXX307+B7VozLc ucHRN+ew==; Received: from dsl-hkibng22-54f986-236.dhcp.inet.fi ([84.249.134.236] helo=[192.168.1.10]) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1l55l8-0006i2-Pw; Thu, 28 Jan 2021 13:46:46 +0200 Subject: Re: [PATCH v5 00/21] Host1x/TegraDRM UAPI To: Dmitry Osipenko , Mikko Perttunen , thierry.reding@gmail.com, jonathanh@nvidia.com, airlied@linux.ie, daniel@ffwll.ch Cc: linux-tegra@vger.kernel.org, dri-devel@lists.freedesktop.org, talho@nvidia.com, bhuntsman@nvidia.com References: <20210111130019.3515669-1-mperttunen@nvidia.com> <2f999b6d-d781-503a-78f4-d444bce72c58@kapsi.fi> <638c1aeb-921b-0ea2-5258-16c6d3183306@gmail.com> <9f755e95-97fc-4f57-5e8d-426af589c857@kapsi.fi> <007d123f-526a-c68a-3c52-aba165172cdf@gmail.com> From: Mikko Perttunen Message-ID: Date: Thu, 28 Jan 2021 13:46:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <007d123f-526a-c68a-3c52-aba165172cdf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 84.249.134.236 X-SA-Exim-Mail-From: cyndis@kapsi.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-tegra@vger.kernel.org On 1/28/21 12:06 AM, Dmitry Osipenko wrote: > 28.01.2021 00:57, Mikko Perttunen пишет: >> >> >> On 1/27/21 11:26 PM, Dmitry Osipenko wrote: >>> 26.01.2021 05:45, Mikko Perttunen пишет: >>>>> 5. The hardware state of sync points should be reset when sync point is >>>>> requested, not when host1x driver is initialized. >>>> >>>> This may be doable, but I don't think it is critical for this UAPI, so >>>> let's consider it after this series. >>>> >>>> The userspace should anyway not be able to assume the initial value of >>>> the syncpoint upon allocation. The kernel should set it to some high >>>> value to catch any issues related to wraparound. >>> >>> This is critical because min != max when sync point is requested. >> >> That I would just consider a bug, and it can be fixed. But it's >> orthogonal to whether the value gets reset every time the syncpoint is >> allocated. >> >>> >>>> Also, this makes code more complicated since it now needs to ensure all >>>> waits on the syncpoint have completed before freeing the syncpoint, >>>> which can be nontrivial e.g. if the waiter is in a different virtual >>>> machine or some other device connected via PCIe (a real usecase). >>> >>> It sounds to me that these VM sync points should be treated very >>> separately from a generic sync points, don't you think so? Let's not mix >>> them and get the generic sync points usable first. >>> >> >> They are not special in any way, I'm just referring to cases where the >> waiter (consumer) is remote. The allocator of the syncpoint (producer) >> doesn't necessarily even need to know about it. The same concern is >> applicable within a single VM, or single application as well. Just >> putting out the point that this is something that needs to be taken care >> of if we were to reset the value. > > Will kernel driver know that it deals with a VM sync point? > > Will it be possible to get a non-VM sync point explicitly? > > If driver knows that it deals with a VM sync point, then we can treat it > specially, avoiding the reset and etc. > There is no distinction between a "VM syncpoint" and a "non-VM syncpoint". To provide an example on the issue, consider we have VM1 and VM2. VM1 is running some camera software that produces frames. VM2 runs some analysis software that consumes those frames through shared memory. In between there is some software that takes the postfences of the camera software and transmits them to the analysis software to be used as prefences. Only this transmitting software needs to know anything about multiple VMs being in use. At any time, if we want to reset the value of the syncpoint in question, we must ensure that all fences waiting on that syncpoint have observed the fence's threshold first. Consider an interleaving like this: VM1 (Camera) VM2 (Analysis) ------------------------------------------------------- Send postfence (threshold=X) Recv postfence (threshold=X) Increment syncpoint value to X Free syncpoint Reset syncpoint value to Y Wait on postfence ------------------------------------------------------- Now depending on the relative values of X and Y, either VM2 progresses (correctly), or gets stuck. If we didn't reset the syncpoint, the race could not occur (unless VM1 managed to increment the syncpoint 2^31 times before VM2's wait starts, which is very unrealistic). We can remove "VM1" and "VM2" everywhere here, and just consider two applications in one VM, too, or two parts of one application. Within one VM the issue is of course easier because the driver can have knowledge about fences and solve the race internally, but I'd always prefer not having such special cases. Now, admittedly this is probably not a huge problem unless we are freeing syncpoints all the time, but nevertheless something to consider. Mikko 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=-5.0 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 BD538C433DB for ; Thu, 28 Jan 2021 11:46:51 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id F2CDD64D9A for ; Thu, 28 Jan 2021 11:46:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F2CDD64D9A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kapsi.fi Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 58F276E194; Thu, 28 Jan 2021 11:46:50 +0000 (UTC) Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) by gabe.freedesktop.org (Postfix) with ESMTPS id 1E6726E194 for ; Thu, 28 Jan 2021 11:46:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kapsi.fi; s=20161220; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=dCyaZBCtvjV1qTeH92823cziiRnr3JFyyEXR29NWh0Q=; b=jxJOoaJh+F/a/xzG22iFj0HTkA vVal6qmTshH4Pb4FvhFDfOY7cYfdeWzvC7u6hAFAveGa34W/AvrJzk+fcAe6doQpq9n+N8inu1iEe 6/MWhxoHfYE25LzF/sU7GhbjG+VcKgbc5US9bdqme4gBxFGQ6znE2PlU22GjBdDb60ZRXwwyejGmc qcWSuhiLB8Rf2u6J/p2eO08vuh+fl8QAGTeDwrF0T4AOuUGaqBKwPLWVeusyf/wVOEl1lSxUWXJhp 34G4h1H3XEPWbgEPDzNp3CdnH8624fFqF9NBm6DH7+7AeRS/uB8Mj1a7XxUdNpMoXX307+B7VozLc ucHRN+ew==; Received: from dsl-hkibng22-54f986-236.dhcp.inet.fi ([84.249.134.236] helo=[192.168.1.10]) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1l55l8-0006i2-Pw; Thu, 28 Jan 2021 13:46:46 +0200 Subject: Re: [PATCH v5 00/21] Host1x/TegraDRM UAPI To: Dmitry Osipenko , Mikko Perttunen , thierry.reding@gmail.com, jonathanh@nvidia.com, airlied@linux.ie, daniel@ffwll.ch References: <20210111130019.3515669-1-mperttunen@nvidia.com> <2f999b6d-d781-503a-78f4-d444bce72c58@kapsi.fi> <638c1aeb-921b-0ea2-5258-16c6d3183306@gmail.com> <9f755e95-97fc-4f57-5e8d-426af589c857@kapsi.fi> <007d123f-526a-c68a-3c52-aba165172cdf@gmail.com> From: Mikko Perttunen Message-ID: Date: Thu, 28 Jan 2021 13:46:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <007d123f-526a-c68a-3c52-aba165172cdf@gmail.com> Content-Language: en-US X-SA-Exim-Connect-IP: 84.249.134.236 X-SA-Exim-Mail-From: cyndis@kapsi.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-tegra@vger.kernel.org, talho@nvidia.com, bhuntsman@nvidia.com, dri-devel@lists.freedesktop.org Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" T24gMS8yOC8yMSAxMjowNiBBTSwgRG1pdHJ5IE9zaXBlbmtvIHdyb3RlOgo+IDI4LjAxLjIwMjEg MDA6NTcsIE1pa2tvIFBlcnR0dW5lbiDQv9C40YjQtdGCOgo+Pgo+Pgo+PiBPbiAxLzI3LzIxIDEx OjI2IFBNLCBEbWl0cnkgT3NpcGVua28gd3JvdGU6Cj4+PiAyNi4wMS4yMDIxIDA1OjQ1LCBNaWtr byBQZXJ0dHVuZW4g0L/QuNGI0LXRgjoKPj4+Pj4gNS4gVGhlIGhhcmR3YXJlIHN0YXRlIG9mIHN5 bmMgcG9pbnRzIHNob3VsZCBiZSByZXNldCB3aGVuIHN5bmMgcG9pbnQgaXMKPj4+Pj4gcmVxdWVz dGVkLCBub3Qgd2hlbiBob3N0MXggZHJpdmVyIGlzIGluaXRpYWxpemVkLgo+Pj4+Cj4+Pj4gVGhp cyBtYXkgYmUgZG9hYmxlLCBidXQgSSBkb24ndCB0aGluayBpdCBpcyBjcml0aWNhbCBmb3IgdGhp cyBVQVBJLCBzbwo+Pj4+IGxldCdzIGNvbnNpZGVyIGl0IGFmdGVyIHRoaXMgc2VyaWVzLgo+Pj4+ Cj4+Pj4gVGhlIHVzZXJzcGFjZSBzaG91bGQgYW55d2F5IG5vdCBiZSBhYmxlIHRvIGFzc3VtZSB0 aGUgaW5pdGlhbCB2YWx1ZSBvZgo+Pj4+IHRoZSBzeW5jcG9pbnQgdXBvbiBhbGxvY2F0aW9uLiBU aGUga2VybmVsIHNob3VsZCBzZXQgaXQgdG8gc29tZSBoaWdoCj4+Pj4gdmFsdWUgdG8gY2F0Y2gg YW55IGlzc3VlcyByZWxhdGVkIHRvIHdyYXBhcm91bmQuCj4+Pgo+Pj4gVGhpcyBpcyBjcml0aWNh bCBiZWNhdXNlIG1pbiAhPSBtYXggd2hlbiBzeW5jIHBvaW50IGlzIHJlcXVlc3RlZC4KPj4KPj4g VGhhdCBJIHdvdWxkIGp1c3QgY29uc2lkZXIgYSBidWcsIGFuZCBpdCBjYW4gYmUgZml4ZWQuIEJ1 dCBpdCdzCj4+IG9ydGhvZ29uYWwgdG8gd2hldGhlciB0aGUgdmFsdWUgZ2V0cyByZXNldCBldmVy eSB0aW1lIHRoZSBzeW5jcG9pbnQgaXMKPj4gYWxsb2NhdGVkLgo+Pgo+Pj4KPj4+PiBBbHNvLCB0 aGlzIG1ha2VzIGNvZGUgbW9yZSBjb21wbGljYXRlZCBzaW5jZSBpdCBub3cgbmVlZHMgdG8gZW5z dXJlIGFsbAo+Pj4+IHdhaXRzIG9uIHRoZSBzeW5jcG9pbnQgaGF2ZSBjb21wbGV0ZWQgYmVmb3Jl IGZyZWVpbmcgdGhlIHN5bmNwb2ludCwKPj4+PiB3aGljaCBjYW4gYmUgbm9udHJpdmlhbCBlLmcu IGlmIHRoZSB3YWl0ZXIgaXMgaW4gYSBkaWZmZXJlbnQgdmlydHVhbAo+Pj4+IG1hY2hpbmUgb3Ig c29tZSBvdGhlciBkZXZpY2UgY29ubmVjdGVkIHZpYSBQQ0llIChhIHJlYWwgdXNlY2FzZSkuCj4+ Pgo+Pj4gSXQgc291bmRzIHRvIG1lIHRoYXQgdGhlc2UgVk0gc3luYyBwb2ludHMgc2hvdWxkIGJl IHRyZWF0ZWQgdmVyeQo+Pj4gc2VwYXJhdGVseSBmcm9tIGEgZ2VuZXJpYyBzeW5jIHBvaW50cywg ZG9uJ3QgeW91IHRoaW5rIHNvPyBMZXQncyBub3QgbWl4Cj4+PiB0aGVtIGFuZCBnZXQgdGhlIGdl bmVyaWMgc3luYyBwb2ludHMgdXNhYmxlIGZpcnN0Lgo+Pj4KPj4KPj4gVGhleSBhcmUgbm90IHNw ZWNpYWwgaW4gYW55IHdheSwgSSdtIGp1c3QgcmVmZXJyaW5nIHRvIGNhc2VzIHdoZXJlIHRoZQo+ PiB3YWl0ZXIgKGNvbnN1bWVyKSBpcyByZW1vdGUuIFRoZSBhbGxvY2F0b3Igb2YgdGhlIHN5bmNw b2ludCAocHJvZHVjZXIpCj4+IGRvZXNuJ3QgbmVjZXNzYXJpbHkgZXZlbiBuZWVkIHRvIGtub3cg YWJvdXQgaXQuIFRoZSBzYW1lIGNvbmNlcm4gaXMKPj4gYXBwbGljYWJsZSB3aXRoaW4gYSBzaW5n bGUgVk0sIG9yIHNpbmdsZSBhcHBsaWNhdGlvbiBhcyB3ZWxsLiBKdXN0Cj4+IHB1dHRpbmcgb3V0 IHRoZSBwb2ludCB0aGF0IHRoaXMgaXMgc29tZXRoaW5nIHRoYXQgbmVlZHMgdG8gYmUgdGFrZW4g Y2FyZQo+PiBvZiBpZiB3ZSB3ZXJlIHRvIHJlc2V0IHRoZSB2YWx1ZS4KPiAKPiBXaWxsIGtlcm5l bCBkcml2ZXIga25vdyB0aGF0IGl0IGRlYWxzIHdpdGggYSBWTSBzeW5jIHBvaW50PyA+Cj4gV2ls bCBpdCBiZSBwb3NzaWJsZSB0byBnZXQgYSBub24tVk0gc3luYyBwb2ludCBleHBsaWNpdGx5Pwo+ IAo+IElmIGRyaXZlciBrbm93cyB0aGF0IGl0IGRlYWxzIHdpdGggYSBWTSBzeW5jIHBvaW50LCB0 aGVuIHdlIGNhbiB0cmVhdCBpdAo+IHNwZWNpYWxseSwgYXZvaWRpbmcgdGhlIHJlc2V0IGFuZCBl dGMuCj4gCgpUaGVyZSBpcyBubyBkaXN0aW5jdGlvbiBiZXR3ZWVuIGEgIlZNIHN5bmNwb2ludCIg YW5kIGEgIm5vbi1WTSAKc3luY3BvaW50Ii4gVG8gcHJvdmlkZSBhbiBleGFtcGxlIG9uIHRoZSBp c3N1ZSwgY29uc2lkZXIgd2UgaGF2ZSBWTTEgYW5kIApWTTIuIFZNMSBpcyBydW5uaW5nIHNvbWUg Y2FtZXJhIHNvZnR3YXJlIHRoYXQgcHJvZHVjZXMgZnJhbWVzLiBWTTIgcnVucyAKc29tZSBhbmFs eXNpcyBzb2Z0d2FyZSB0aGF0IGNvbnN1bWVzIHRob3NlIGZyYW1lcyB0aHJvdWdoIHNoYXJlZCBt ZW1vcnkuIApJbiBiZXR3ZWVuIHRoZXJlIGlzIHNvbWUgc29mdHdhcmUgdGhhdCB0YWtlcyB0aGUg cG9zdGZlbmNlcyBvZiB0aGUgCmNhbWVyYSBzb2Z0d2FyZSBhbmQgdHJhbnNtaXRzIHRoZW0gdG8g dGhlIGFuYWx5c2lzIHNvZnR3YXJlIHRvIGJlIHVzZWQgCmFzIHByZWZlbmNlcy4gT25seSB0aGlz IHRyYW5zbWl0dGluZyBzb2Z0d2FyZSBuZWVkcyB0byBrbm93IGFueXRoaW5nIAphYm91dCBtdWx0 aXBsZSBWTXMgYmVpbmcgaW4gdXNlLgoKQXQgYW55IHRpbWUsIGlmIHdlIHdhbnQgdG8gcmVzZXQg dGhlIHZhbHVlIG9mIHRoZSBzeW5jcG9pbnQgaW4gcXVlc3Rpb24sIAp3ZSBtdXN0IGVuc3VyZSB0 aGF0IGFsbCBmZW5jZXMgd2FpdGluZyBvbiB0aGF0IHN5bmNwb2ludCBoYXZlIG9ic2VydmVkIAp0 aGUgZmVuY2UncyB0aHJlc2hvbGQgZmlyc3QuCgpDb25zaWRlciBhbiBpbnRlcmxlYXZpbmcgbGlr ZSB0aGlzOgoKVk0xIChDYW1lcmEpCQkJCVZNMiAoQW5hbHlzaXMpCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KU2VuZCBwb3N0ZmVuY2UgKHRo cmVzaG9sZD1YKQoJCQkJCVJlY3YgcG9zdGZlbmNlICh0aHJlc2hvbGQ9WCkKSW5jcmVtZW50IHN5 bmNwb2ludCB2YWx1ZSB0byBYCkZyZWUgc3luY3BvaW50ClJlc2V0IHN5bmNwb2ludCB2YWx1ZSB0 byBZCgkJCQkJV2FpdCBvbiBwb3N0ZmVuY2UKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKTm93IGRlcGVuZGluZyBvbiB0aGUgcmVsYXRpdmUg dmFsdWVzIG9mIFggYW5kIFksIGVpdGhlciBWTTIgcHJvZ3Jlc3NlcyAKKGNvcnJlY3RseSksIG9y IGdldHMgc3R1Y2suIElmIHdlIGRpZG4ndCByZXNldCB0aGUgc3luY3BvaW50LCB0aGUgcmFjZSAK Y291bGQgbm90IG9jY3VyICh1bmxlc3MgVk0xIG1hbmFnZWQgdG8gaW5jcmVtZW50IHRoZSBzeW5j cG9pbnQgMl4zMSAKdGltZXMgYmVmb3JlIFZNMidzIHdhaXQgc3RhcnRzLCB3aGljaCBpcyB2ZXJ5 IHVucmVhbGlzdGljKS4KCldlIGNhbiByZW1vdmUgIlZNMSIgYW5kICJWTTIiIGV2ZXJ5d2hlcmUg aGVyZSwgYW5kIGp1c3QgY29uc2lkZXIgdHdvIAphcHBsaWNhdGlvbnMgaW4gb25lIFZNLCB0b28s IG9yIHR3byBwYXJ0cyBvZiBvbmUgYXBwbGljYXRpb24uIFdpdGhpbiBvbmUgClZNIHRoZSBpc3N1 ZSBpcyBvZiBjb3Vyc2UgZWFzaWVyIGJlY2F1c2UgdGhlIGRyaXZlciBjYW4gaGF2ZSBrbm93bGVk Z2UgCmFib3V0IGZlbmNlcyBhbmQgc29sdmUgdGhlIHJhY2UgaW50ZXJuYWxseSwgYnV0IEknZCBh bHdheXMgcHJlZmVyIG5vdCAKaGF2aW5nIHN1Y2ggc3BlY2lhbCBjYXNlcy4KCk5vdywgYWRtaXR0 ZWRseSB0aGlzIGlzIHByb2JhYmx5IG5vdCBhIGh1Z2UgcHJvYmxlbSB1bmxlc3Mgd2UgYXJlIApm cmVlaW5nIHN5bmNwb2ludHMgYWxsIHRoZSB0aW1lLCBidXQgbmV2ZXJ0aGVsZXNzIHNvbWV0aGlu ZyB0byBjb25zaWRlci4KCk1pa2tvCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3RzLmZyZWVk ZXNrdG9wLm9yZwpodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2RyaS1kZXZlbAo=