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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C16AFC5475B for ; Wed, 6 Mar 2024 17:21:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=2BXvq7/9NPYJ/Ixj6YfKKuxDkLPRgRYOWOtx68zc0u4=; b=erRdmRODAQZGS70ECyGl4rI9GE sZuXb9GP1ZR16CsjnIJb/cR+OOZs/HwbZCWJmrObZDP5/QA81SqE4cAeqtZcQlcUK5KXg9W94V5GH HkgzqIHhYU4sPhYCO333OX2QTuQNEvFiP2q2jN45jsV+fYLnYWmOgbs1bEriSStdNGnUn7psSejWN OFDZFhQ2Es8txBAYYY0G2j2rdFix6yj7OszXYQIenNGYs1ATYJPnTGNF8plDdc5SU+Rn5a+5yXsRP PjA+NpSOzql7hoHB/btVkkAshJuBMBNgpWJvdMtaG9c6oK1gk+KBIEmR15Hggsi6Qa2/ReN8p9Ff7 ucssiw1Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rhuxJ-00000001Aok-1SD7; Wed, 06 Mar 2024 17:21:25 +0000 Received: from desiato.infradead.org ([2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rhtof-00000000vYF-3BXb; Wed, 06 Mar 2024 16:08:25 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=2BXvq7/9NPYJ/Ixj6YfKKuxDkLPRgRYOWOtx68zc0u4=; b=X/frY84YmqUJjF4lzJXYt/08/j DZ891OHVHmDaBvKUNzUrVSjEp+tGEBYA5ua7a4CFY9bpOC0avco5ZN1wnq4dQonM5nvxQZMrSvnnY kzYyZql86bHjFdDSSzHyZFQszOG/Ot4+RjtkJMN9EMwL2dBKNQ7MjFiAtQjFMuX85TOfn8ZA7WgLI kM9Si5I2cektAoFDDrerXbGToH2qExfmqd2rEZ23R7dG93BDz0IGL5LCPWaSAv2q103Ni9JsRVQYk fkDpG9N2XASVi1GRc9Qz+GlfNAJyD3pyhJCjBiREQwn0ufk5UZhq8vBJyc1OnO3LAfAucdo4gWO2Z UGlzUyrg==; Received: from foss.arm.com ([217.140.110.172]) by desiato.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rhtoV-00000006BHF-06wO; Wed, 06 Mar 2024 16:08:17 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 33D301FB; Wed, 6 Mar 2024 08:08:49 -0800 (PST) Received: from pluto (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 289733F73F; Wed, 6 Mar 2024 08:08:10 -0800 (PST) Date: Wed, 6 Mar 2024 16:08:07 +0000 From: Cristian Marussi To: Flash Liu =?utf-8?B?KOWKieeCs+WCsyk=?= Cc: "linux-mediatek@lists.infradead.org" , "linux-kernel@vger.kernel.org" , wsd_upstream , Cylen Yao =?utf-8?B?KOWnmueri+S4iSk=?= , "sudeep.holla@arm.com" , "linux-arm-kernel@lists.infradead.org" , "matthias.bgg@gmail.com" , "angelogioacchino.delregno@collabora.com" Subject: Re: [PATCH v2] firmware: arm_scmi: Avoid to call mbox_client_txdone on txdone_irq mode Message-ID: References: <20240201095754.25374-1-flash.liu@mediatek.com> <053cb4a2edfe576412942daed2f7055b2ba9e207.camel@mediatek.com> <56e1b2f5adbca437a14b738e1c58a054f6302fcd.camel@mediatek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240306_160815_610340_CB424516 X-CRM114-Status: GOOD ( 34.29 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org On Wed, Mar 06, 2024 at 09:49:16AM +0000, Cristian Marussi wrote: > On Wed, Mar 06, 2024 at 06:13:48AM +0000, Flash Liu (劉炳傳) wrote: > > Hi Cristian, > > > > Kindly ping :) > > > > Hi Pin-Chuan, > > sorry for the delay...I have NOT forgot :D, indeed I was just testing > yesterday with some mailbox IP of ours equipped with a TxAck IRQ and I > would have some question for you because I've seen some anomalies while > using this: does your solution work reliably in your setup ALSO when > multiple SCMI transactions are attempted ? (like cpufreq issuing cmds > while polling a sensor from some other thread) > > ...I'll dig deeper today in this matter, but my current suspect is that > using the mailbox TXAck IRQ to let the controller tick the internal mailbox > queues does not play well with SCMI, since the SCMI TX channel is really the > SCMI "a2p" bidirectional channel and it is associated with just only one shmem > area used to hold both the egressing CMD and to receive the incoming REPLY > from the platform: so if you let the controller tick the queues as soon as you > received the TXAck you are telling the mailbox subsystem to queue another message > on the same area while you are not really done, since only the client know > when it's done with the whole SCMI transaction and the reply has been fetched. > > Indeed, for these reasons we have the BUSY/FREE bit in the shmem to protect it > from pending new requests until the previous one has completed, but when the > waited-for reply comes in, the platform would have cleared the BUSY bit and > let the new queued message overwrite the pending reply prematurely, and one > message is lost... > > ...but as said I want to delve deeper into this, as of now just suppositions > and maybe I am just missing something more that has to be configured > properly... > > Thanks, > Cristian > Hi again :D, so articulating more on my supposition that TxAck-capable mailboxes and SCMI do not play well together (and would not be worth either really...) Consider the following scenario. 1. scmi: mbox_send_message(X) is called from SCMI stack to send mesg-X on the a2p channel (a command) 2. mbox: mesg-X is 2a. queued by mbox subsystem [add_to_rbuf(X)] 2b. submitted for transmission [msg_submit(X)] 2c. prepared by SCMI clk->tx_prepare 2d. finally sent via mhu driver .send_data 2e. mesg-X is now an active_req for mbox and in-flight for SCMI 3. scmi: ANOTHER mesg-Y tx is attempted via mbox_send_message(Y) 4. mbox: mesg-Y is 4a. queued by mbox_subsys [add_to_rbuf()] 4b. NOT submitted since there is already an active_req=mesg-X pending Any further SCMI mesg TX attempt will behave similarly: queued/not_submitted till at some in the future someone calls the txdone routines, which in turn calls tx_tick()...this SOMEONE can be the client, like it is now, or the controller if it is configured to use the TxAck IRQ (as per-your-patch)... ...so lets see what happen in your TxAck enabled case. 5. TxAck IRQ received, transmission of mesg-X has been successfull (NOTE that SCMI at this point is still waiting for a reply to mesg-X..) 5a. controller calls mbox_chan_txdone() 5b. mbox in turn calls tx_tick 5c. active_req is cleared and next queued mesg-Y is submitted 5d. mesg-Y transmission gets anyway stuck on cl->tx_prepare since we check the SCMI shmem BUSY bit and busy-loop there till it clears: this clearing can happen ONLY after the mesg-X reply has come through, since it is the platform SCMI server that clears it having delivered the reply in the shmem. 6. platform SCMI server replies to mesg-X finally: 6a. platform writes reply in shmem 6b. platform clears BUSY bit -- note SCMI stack is still waiting for a reply at this point... so waiting for an IRQ OR by simply spinning on that same BUSY bit if polling mode was requested for the transaction.... ...lets assume you are in IRQ mode: 7. mesg-Y sender which was spinning on BUSY bit (blocked on tx_prepare) is immediately cleared to send and so tx_prepare can proceed further and completely overwrite the just received mesg-X, which is now LOST ..in case you were polling I guess you will have anyway some corruption due to the race between the polling-mesg-X-receiver retrieving the reply and the same tx_prepare codeflow as above... Indeed, the spec says that you should protect the channel till the reply has been retrieved from the SCMI (even after the BUSY bit is cleared), and in other transport we DO have some form of locks, BUT here in mailboxes there is not since it is NOT needed IF you stick to the non-TxAck original behaviour, since the tx_tick, as it is now, will be run by the SCMI stack ONLY after it has waited for mesg-X and retrieved the mesg-X-reply payload ...not before. Instead, if you enable the TxAck mode you are basically letting the controller itself issue the tx_tick(), which means "previous TX is done, please proceed with the next", BUT the current TX is really NOT done at all as intended by the client (SCMI), since the reply is missing and the only entity which can have the whole picture about when a transaction is completed (or timed-out) is the SCMI client. As said, I think the fundamental clash is between what the mailbox subsystem considers a TXDONE event (and related actions) and what instead is considered a completed transaction on the SCMI a2p channel: i.e. CMD_sent + REPLY_retrieved. At the end, anyway, would it be worth in any way to leverage such TxAck capabilities (somehow) of a mailbox in the SCMI world ? I mean, even if we make this work, what is supposed to happen better and faster when using a TxAck instead of a TX_polling mode like it is now ? ...because the SCMI stack cannot really do anything with this information in this case, given that there is just one single a2p_shem area for sending command and receiving replies...it has just to wait anyway even after the TxAck... ..maybe it is a bit more power-favourable to sleep_wait for the TxAck IRQ instead of polling the MHU regs ?... other than this the TxAck means nothing really in the context of the SCMI world, since you cannot safely queue anything more till the previous exchange has fully completed... ...in other non-SCMI scenarios that I experimented with, it really makes a difference havig the TxAck since it avoids all the internal polling/requeueing dance in the mailbox subsystem, but in this case I think is all made useless by the way SCMI/SMT based transport works...i.e. using a single shmem area for the a2p channel.. ...not really a short and sweet email... :P ... any feedback or further ideas are welcome anyway...especially if you can prove that all of the above is somehow wrong, or that there is a good reason to leverage the TxAck capable mailboxes :D Thanks, Cristian 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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D25EBC5475B for ; Wed, 6 Mar 2024 16:08:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=3avES6P5MfD2achbfeBrHTJGedd5nQoLnUgOD9TaJVk=; b=x5rHwQw0qM0Yf7 WlOia6ouIg2JlpxNz47Z45OazHJyWiybMOvYWjo4PWamjjncUGmXZONR+57xicVEubURokCTaqHtr thXFvEFp0sM7MnpM2u9Zqo/otnZPpfc+Du1ntqCajYs+cysJe+WSfj4bCld6WcKMEJU2iKayoysmB iz8BuzI/G8pKBmLQA0+beOA6jE0cqwrh+4t4fEo4odUou1XB5iLAXKpAK+8xFAFzUev48LxxlayvQ 2HYq93fIDVRRkMA9+qra3Ac8qVLdQMiUE43BISJTlCASMUIg62YvDQIzcNngOa5hRAT+ivre+OtBn qXKra7AF3cVX0iBaMWYw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rhtoh-00000000vbU-1C0p; Wed, 06 Mar 2024 16:08:27 +0000 Received: from desiato.infradead.org ([2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rhtof-00000000vYF-3BXb; Wed, 06 Mar 2024 16:08:25 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=2BXvq7/9NPYJ/Ixj6YfKKuxDkLPRgRYOWOtx68zc0u4=; b=X/frY84YmqUJjF4lzJXYt/08/j DZ891OHVHmDaBvKUNzUrVSjEp+tGEBYA5ua7a4CFY9bpOC0avco5ZN1wnq4dQonM5nvxQZMrSvnnY kzYyZql86bHjFdDSSzHyZFQszOG/Ot4+RjtkJMN9EMwL2dBKNQ7MjFiAtQjFMuX85TOfn8ZA7WgLI kM9Si5I2cektAoFDDrerXbGToH2qExfmqd2rEZ23R7dG93BDz0IGL5LCPWaSAv2q103Ni9JsRVQYk fkDpG9N2XASVi1GRc9Qz+GlfNAJyD3pyhJCjBiREQwn0ufk5UZhq8vBJyc1OnO3LAfAucdo4gWO2Z UGlzUyrg==; Received: from foss.arm.com ([217.140.110.172]) by desiato.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rhtoV-00000006BHF-06wO; Wed, 06 Mar 2024 16:08:17 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 33D301FB; Wed, 6 Mar 2024 08:08:49 -0800 (PST) Received: from pluto (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 289733F73F; Wed, 6 Mar 2024 08:08:10 -0800 (PST) Date: Wed, 6 Mar 2024 16:08:07 +0000 From: Cristian Marussi To: Flash Liu =?utf-8?B?KOWKieeCs+WCsyk=?= Cc: "linux-mediatek@lists.infradead.org" , "linux-kernel@vger.kernel.org" , wsd_upstream , Cylen Yao =?utf-8?B?KOWnmueri+S4iSk=?= , "sudeep.holla@arm.com" , "linux-arm-kernel@lists.infradead.org" , "matthias.bgg@gmail.com" , "angelogioacchino.delregno@collabora.com" Subject: Re: [PATCH v2] firmware: arm_scmi: Avoid to call mbox_client_txdone on txdone_irq mode Message-ID: References: <20240201095754.25374-1-flash.liu@mediatek.com> <053cb4a2edfe576412942daed2f7055b2ba9e207.camel@mediatek.com> <56e1b2f5adbca437a14b738e1c58a054f6302fcd.camel@mediatek.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240306_160815_610340_CB424516 X-CRM114-Status: GOOD ( 34.29 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org T24gV2VkLCBNYXIgMDYsIDIwMjQgYXQgMDk6NDk6MTZBTSArMDAwMCwgQ3Jpc3RpYW4gTWFydXNz aSB3cm90ZToKPiBPbiBXZWQsIE1hciAwNiwgMjAyNCBhdCAwNjoxMzo0OEFNICswMDAwLCBGbGFz aCBMaXUgKOWKieeCs+WCsykgd3JvdGU6Cj4gPiBIaSBDcmlzdGlhbiwKPiA+IAo+ID4gS2luZGx5 IHBpbmcgOikKPiA+IAo+IAo+IEhpIFBpbi1DaHVhbiwKPiAKPiBzb3JyeSBmb3IgdGhlIGRlbGF5 Li4uSSBoYXZlIE5PVCBmb3Jnb3QgOkQsIGluZGVlZCBJIHdhcyBqdXN0IHRlc3RpbmcKPiB5ZXN0 ZXJkYXkgd2l0aCBzb21lIG1haWxib3ggSVAgb2Ygb3VycyBlcXVpcHBlZCB3aXRoIGEgVHhBY2sg SVJRIGFuZCBJCj4gd291bGQgaGF2ZSBzb21lIHF1ZXN0aW9uIGZvciB5b3UgYmVjYXVzZSBJJ3Zl IHNlZW4gc29tZSBhbm9tYWxpZXMgd2hpbGUKPiB1c2luZyB0aGlzOiBkb2VzIHlvdXIgc29sdXRp b24gd29yayByZWxpYWJseSBpbiB5b3VyIHNldHVwIEFMU08gd2hlbgo+IG11bHRpcGxlIFNDTUkg dHJhbnNhY3Rpb25zIGFyZSBhdHRlbXB0ZWQgPyAobGlrZSBjcHVmcmVxIGlzc3VpbmcgY21kcwo+ IHdoaWxlIHBvbGxpbmcgYSBzZW5zb3IgZnJvbSBzb21lIG90aGVyIHRocmVhZCkKPiAKPiAuLi5J J2xsIGRpZyBkZWVwZXIgdG9kYXkgaW4gdGhpcyBtYXR0ZXIsIGJ1dCBteSBjdXJyZW50IHN1c3Bl Y3QgaXMgdGhhdAo+IHVzaW5nIHRoZSBtYWlsYm94IFRYQWNrIElSUSB0byBsZXQgdGhlIGNvbnRy b2xsZXIgdGljayB0aGUgaW50ZXJuYWwgbWFpbGJveAo+IHF1ZXVlcyBkb2VzIG5vdCBwbGF5IHdl bGwgd2l0aCBTQ01JLCBzaW5jZSB0aGUgU0NNSSBUWCBjaGFubmVsIGlzIHJlYWxseSB0aGUKPiBT Q01JICJhMnAiIGJpZGlyZWN0aW9uYWwgY2hhbm5lbCBhbmQgaXQgaXMgYXNzb2NpYXRlZCB3aXRo IGp1c3Qgb25seSBvbmUgc2htZW0KPiBhcmVhIHVzZWQgdG8gaG9sZCBib3RoIHRoZSBlZ3Jlc3Np bmcgQ01EIGFuZCB0byByZWNlaXZlIHRoZSBpbmNvbWluZyBSRVBMWQo+IGZyb20gdGhlIHBsYXRm b3JtOiBzbyBpZiB5b3UgbGV0IHRoZSBjb250cm9sbGVyIHRpY2sgdGhlIHF1ZXVlcyBhcyBzb29u IGFzIHlvdQo+IHJlY2VpdmVkIHRoZSBUWEFjayB5b3UgYXJlIHRlbGxpbmcgdGhlIG1haWxib3gg c3Vic3lzdGVtIHRvIHF1ZXVlIGFub3RoZXIgbWVzc2FnZQo+IG9uIHRoZSBzYW1lIGFyZWEgd2hp bGUgeW91IGFyZSBub3QgcmVhbGx5IGRvbmUsIHNpbmNlIG9ubHkgdGhlIGNsaWVudCBrbm93Cj4g d2hlbiBpdCdzIGRvbmUgd2l0aCB0aGUgd2hvbGUgU0NNSSB0cmFuc2FjdGlvbiBhbmQgdGhlIHJl cGx5IGhhcyBiZWVuIGZldGNoZWQuCj4gCj4gSW5kZWVkLCBmb3IgdGhlc2UgcmVhc29ucyB3ZSBo YXZlIHRoZSBCVVNZL0ZSRUUgYml0IGluIHRoZSBzaG1lbSB0byBwcm90ZWN0IGl0Cj4gZnJvbSBw ZW5kaW5nIG5ldyByZXF1ZXN0cyB1bnRpbCB0aGUgcHJldmlvdXMgb25lIGhhcyBjb21wbGV0ZWQs IGJ1dCB3aGVuIHRoZQo+IHdhaXRlZC1mb3IgcmVwbHkgY29tZXMgaW4sIHRoZSBwbGF0Zm9ybSB3 b3VsZCBoYXZlIGNsZWFyZWQgdGhlIEJVU1kgYml0IGFuZAo+IGxldCB0aGUgbmV3IHF1ZXVlZCBt ZXNzYWdlIG92ZXJ3cml0ZSB0aGUgcGVuZGluZyByZXBseSBwcmVtYXR1cmVseSwgYW5kIG9uZQo+ IG1lc3NhZ2UgaXMgbG9zdC4uLgo+IAo+IC4uLmJ1dCBhcyBzYWlkIEkgd2FudCB0byBkZWx2ZSBk ZWVwZXIgaW50byB0aGlzLCBhcyBvZiBub3cganVzdCBzdXBwb3NpdGlvbnMKPiBhbmQgbWF5YmUg SSBhbSBqdXN0IG1pc3Npbmcgc29tZXRoaW5nIG1vcmUgdGhhdCBoYXMgdG8gYmUgY29uZmlndXJl ZAo+IHByb3Blcmx5Li4uCj4gCj4gVGhhbmtzLAo+IENyaXN0aWFuCj4KCkhpIGFnYWluIDpELAoK c28gYXJ0aWN1bGF0aW5nIG1vcmUgb24gbXkgc3VwcG9zaXRpb24gdGhhdCBUeEFjay1jYXBhYmxl IG1haWxib3hlcyBhbmQKU0NNSSBkbyBub3QgcGxheSB3ZWxsIHRvZ2V0aGVyIChhbmQgd291bGQg bm90IGJlIHdvcnRoIGVpdGhlciByZWFsbHkuLi4pCgpDb25zaWRlciB0aGUgZm9sbG93aW5nIHNj ZW5hcmlvLgoKMS4gc2NtaTogbWJveF9zZW5kX21lc3NhZ2UoWCkgaXMgY2FsbGVkIGZyb20gU0NN SSBzdGFjayB0byBzZW5kIG1lc2ctWAogICAgICAgICBvbiB0aGUgYTJwIGNoYW5uZWwgKGEgY29t bWFuZCkKCjIuIG1ib3g6IG1lc2ctWCBpcwogIDJhLiBxdWV1ZWQgYnkgbWJveCBzdWJzeXN0ZW0g W2FkZF90b19yYnVmKFgpXQogIDJiLiBzdWJtaXR0ZWQgZm9yIHRyYW5zbWlzc2lvbiBbbXNnX3N1 Ym1pdChYKV0KICAyYy4gcHJlcGFyZWQgYnkgU0NNSSBjbGstPnR4X3ByZXBhcmUKICAyZC4gZmlu YWxseSBzZW50IHZpYSBtaHUgZHJpdmVyIC5zZW5kX2RhdGEKICAyZS4gbWVzZy1YIGlzIG5vdyBh biBhY3RpdmVfcmVxIGZvciBtYm94IGFuZCBpbi1mbGlnaHQgZm9yIFNDTUkKCjMuIHNjbWk6IEFO T1RIRVIgbWVzZy1ZIHR4IGlzIGF0dGVtcHRlZCB2aWEgbWJveF9zZW5kX21lc3NhZ2UoWSkKCjQu IG1ib3g6IG1lc2ctWSBpcwogIDRhLiBxdWV1ZWQgYnkgbWJveF9zdWJzeXMgW2FkZF90b19yYnVm KCldCiAgNGIuIE5PVCBzdWJtaXR0ZWQgc2luY2UgdGhlcmUgaXMgYWxyZWFkeSBhbiBhY3RpdmVf cmVxPW1lc2ctWCBwZW5kaW5nCgpBbnkgZnVydGhlciBTQ01JIG1lc2cgVFggYXR0ZW1wdCB3aWxs IGJlaGF2ZSBzaW1pbGFybHk6IHF1ZXVlZC9ub3Rfc3VibWl0dGVkCnRpbGwgYXQgc29tZSBpbiB0 aGUgZnV0dXJlIHNvbWVvbmUgY2FsbHMgdGhlIHR4ZG9uZSByb3V0aW5lcywgd2hpY2ggaW4gdHVy bgpjYWxscyB0eF90aWNrKCkuLi50aGlzIFNPTUVPTkUgY2FuIGJlIHRoZSBjbGllbnQsIGxpa2Ug aXQgaXMgbm93LCBvciB0aGUKY29udHJvbGxlciBpZiBpdCBpcyBjb25maWd1cmVkIHRvIHVzZSB0 aGUgVHhBY2sgSVJRIChhcyBwZXIteW91ci1wYXRjaCkuLi4KLi4uc28gbGV0cyBzZWUgd2hhdCBo YXBwZW4gaW4geW91ciBUeEFjayBlbmFibGVkIGNhc2UuCgo1LiBUeEFjayBJUlEgcmVjZWl2ZWQs IHRyYW5zbWlzc2lvbiBvZiBtZXNnLVggaGFzIGJlZW4gc3VjY2Vzc2Z1bGwKICAoTk9URSB0aGF0 IFNDTUkgYXQgdGhpcyBwb2ludCBpcyBzdGlsbCB3YWl0aW5nIGZvciBhIHJlcGx5IHRvIG1lc2ct WC4uKQoKICA1YS4gY29udHJvbGxlciBjYWxscyBtYm94X2NoYW5fdHhkb25lKCkKICA1Yi4gbWJv eCBpbiB0dXJuIGNhbGxzIHR4X3RpY2sKICA1Yy4gYWN0aXZlX3JlcSBpcyBjbGVhcmVkIGFuZCBu ZXh0IHF1ZXVlZCBtZXNnLVkgaXMgc3VibWl0dGVkCiAgNWQuIG1lc2ctWSB0cmFuc21pc3Npb24g Z2V0cyBhbnl3YXkgc3R1Y2sgb24gY2wtPnR4X3ByZXBhcmUgc2luY2UKICAgICAgd2UgY2hlY2sg dGhlIFNDTUkgc2htZW0gQlVTWSBiaXQgYW5kIGJ1c3ktbG9vcCB0aGVyZSB0aWxsIGl0CiAgICAg IGNsZWFyczogdGhpcyBjbGVhcmluZyBjYW4gaGFwcGVuIE9OTFkgYWZ0ZXIgdGhlIG1lc2ctWCBy ZXBseQogICAgICBoYXMgY29tZSB0aHJvdWdoLCBzaW5jZSBpdCBpcyB0aGUgcGxhdGZvcm0gU0NN SSBzZXJ2ZXIgdGhhdAogICAgICBjbGVhcnMgaXQgaGF2aW5nIGRlbGl2ZXJlZCB0aGUgcmVwbHkg aW4gdGhlIHNobWVtLgoKNi4gcGxhdGZvcm0gU0NNSSBzZXJ2ZXIgcmVwbGllcyB0byBtZXNnLVgg ZmluYWxseToKICA2YS4gcGxhdGZvcm0gd3JpdGVzIHJlcGx5IGluIHNobWVtCiAgNmIuIHBsYXRm b3JtIGNsZWFycyBCVVNZIGJpdAoKICAtLSBub3RlIFNDTUkgc3RhY2sgaXMgc3RpbGwgd2FpdGlu ZyBmb3IgYSByZXBseSBhdCB0aGlzIHBvaW50Li4uCiAgICAgc28gd2FpdGluZyBmb3IgYW4gSVJR IE9SIGJ5IHNpbXBseSBzcGlubmluZyBvbiB0aGF0IHNhbWUgQlVTWSBiaXQKICAgICBpZiBwb2xs aW5nIG1vZGUgd2FzIHJlcXVlc3RlZCBmb3IgdGhlIHRyYW5zYWN0aW9uLi4uLgoKICAgICAuLi5s ZXRzIGFzc3VtZSB5b3UgYXJlIGluIElSUSBtb2RlOgoKNy4gbWVzZy1ZIHNlbmRlciB3aGljaCB3 YXMgc3Bpbm5pbmcgb24gQlVTWSBiaXQgKGJsb2NrZWQgb24gdHhfcHJlcGFyZSkKICAgaXMgaW1t ZWRpYXRlbHkgY2xlYXJlZCB0byBzZW5kIGFuZCBzbyB0eF9wcmVwYXJlIGNhbiBwcm9jZWVkIGZ1 cnRoZXIKICAgYW5kIGNvbXBsZXRlbHkgb3ZlcndyaXRlIHRoZSBqdXN0IHJlY2VpdmVkIG1lc2ct WCwgd2hpY2ggaXMgbm93IExPU1QKCi4uaW4gY2FzZSB5b3Ugd2VyZSBwb2xsaW5nIEkgZ3Vlc3Mg eW91IHdpbGwgaGF2ZSBhbnl3YXkgc29tZSBjb3JydXB0aW9uCmR1ZSB0byB0aGUgcmFjZSBiZXR3 ZWVuIHRoZSBwb2xsaW5nLW1lc2ctWC1yZWNlaXZlciByZXRyaWV2aW5nIHRoZSByZXBseQphbmQg dGhlIHNhbWUgdHhfcHJlcGFyZSBjb2RlZmxvdyBhcyBhYm92ZS4uLgoKSW5kZWVkLCB0aGUgc3Bl YyBzYXlzIHRoYXQgeW91IHNob3VsZCBwcm90ZWN0IHRoZSBjaGFubmVsIHRpbGwgdGhlIHJlcGx5 CmhhcyBiZWVuIHJldHJpZXZlZCBmcm9tIHRoZSBTQ01JIChldmVuIGFmdGVyIHRoZSBCVVNZIGJp dCBpcyBjbGVhcmVkKSwgYW5kCmluIG90aGVyIHRyYW5zcG9ydCB3ZSBETyBoYXZlIHNvbWUgZm9y bSBvZiBsb2NrcywgQlVUIGhlcmUgaW4gbWFpbGJveGVzCnRoZXJlIGlzIG5vdCBzaW5jZSBpdCBp cyBOT1QgbmVlZGVkIElGIHlvdSBzdGljayB0byB0aGUgbm9uLVR4QWNrIG9yaWdpbmFsCmJlaGF2 aW91ciwgc2luY2UgdGhlIHR4X3RpY2ssIGFzIGl0IGlzIG5vdywgd2lsbCBiZSBydW4gYnkgdGhl IFNDTUkgc3RhY2sKT05MWSBhZnRlciBpdCBoYXMgd2FpdGVkIGZvciBtZXNnLVggYW5kIHJldHJp ZXZlZCB0aGUgbWVzZy1YLXJlcGx5IHBheWxvYWQKLi4ubm90IGJlZm9yZS4KCkluc3RlYWQsIGlm IHlvdSBlbmFibGUgdGhlIFR4QWNrIG1vZGUgeW91IGFyZSBiYXNpY2FsbHkgbGV0dGluZyB0aGUg Y29udHJvbGxlcgppdHNlbGYgaXNzdWUgdGhlIHR4X3RpY2soKSwgd2hpY2ggbWVhbnMgInByZXZp b3VzIFRYIGlzIGRvbmUsIHBsZWFzZSBwcm9jZWVkCndpdGggdGhlIG5leHQiLCBCVVQgdGhlIGN1 cnJlbnQgVFggaXMgcmVhbGx5IE5PVCBkb25lIGF0IGFsbCBhcyBpbnRlbmRlZApieSB0aGUgY2xp ZW50IChTQ01JKSwgc2luY2UgdGhlIHJlcGx5IGlzIG1pc3NpbmcgYW5kIHRoZSBvbmx5IGVudGl0 eSB3aGljaApjYW4gaGF2ZSB0aGUgd2hvbGUgcGljdHVyZSBhYm91dCB3aGVuIGEgdHJhbnNhY3Rp b24gaXMgY29tcGxldGVkIChvciB0aW1lZC1vdXQpCmlzIHRoZSBTQ01JIGNsaWVudC4KCkFzIHNh aWQsIEkgdGhpbmsgdGhlIGZ1bmRhbWVudGFsIGNsYXNoIGlzIGJldHdlZW4gd2hhdCB0aGUgbWFp bGJveApzdWJzeXN0ZW0gY29uc2lkZXJzIGEgVFhET05FIGV2ZW50IChhbmQgcmVsYXRlZCBhY3Rp b25zKSBhbmQgd2hhdAppbnN0ZWFkIGlzIGNvbnNpZGVyZWQgYSBjb21wbGV0ZWQgdHJhbnNhY3Rp b24gb24gdGhlIFNDTUkgYTJwIGNoYW5uZWw6CmkuZS4gQ01EX3NlbnQgKyBSRVBMWV9yZXRyaWV2 ZWQuCgpBdCB0aGUgZW5kLCBhbnl3YXksIHdvdWxkIGl0IGJlIHdvcnRoIGluIGFueSB3YXkgdG8g bGV2ZXJhZ2Ugc3VjaCBUeEFjawpjYXBhYmlsaXRpZXMgKHNvbWVob3cpIG9mIGEgbWFpbGJveCBp biB0aGUgU0NNSSB3b3JsZCA/CgpJIG1lYW4sIGV2ZW4gaWYgd2UgbWFrZSB0aGlzIHdvcmssIHdo YXQgaXMgc3VwcG9zZWQgdG8gaGFwcGVuIGJldHRlciBhbmQgZmFzdGVyCndoZW4gdXNpbmcgYSBU eEFjayBpbnN0ZWFkIG9mIGEgVFhfcG9sbGluZyBtb2RlIGxpa2UgaXQgaXMgbm93ID8KCi4uLmJl Y2F1c2UgdGhlIFNDTUkgc3RhY2sgY2Fubm90IHJlYWxseSBkbyBhbnl0aGluZyB3aXRoIHRoaXMg aW5mb3JtYXRpb24gaW4KdGhpcyBjYXNlLCBnaXZlbiB0aGF0IHRoZXJlIGlzIGp1c3Qgb25lIHNp bmdsZSBhMnBfc2hlbSBhcmVhIGZvciBzZW5kaW5nIGNvbW1hbmQKYW5kIHJlY2VpdmluZyByZXBs aWVzLi4uaXQgaGFzIGp1c3QgdG8gd2FpdCBhbnl3YXkgZXZlbiBhZnRlciB0aGUKVHhBY2suLi4K Ci4ubWF5YmUgaXQgaXMgYSBiaXQgbW9yZSBwb3dlci1mYXZvdXJhYmxlIHRvIHNsZWVwX3dhaXQg Zm9yIHRoZSBUeEFjayBJUlEKaW5zdGVhZCBvZiBwb2xsaW5nIHRoZSBNSFUgcmVncyA/Li4uIG90 aGVyIHRoYW4gdGhpcyB0aGUgVHhBY2sgbWVhbnMgbm90aGluZwpyZWFsbHkgaW4gdGhlIGNvbnRl eHQgb2YgdGhlIFNDTUkgd29ybGQsIHNpbmNlIHlvdSBjYW5ub3Qgc2FmZWx5IHF1ZXVlIGFueXRo aW5nCm1vcmUgdGlsbCB0aGUgcHJldmlvdXMgZXhjaGFuZ2UgaGFzIGZ1bGx5IGNvbXBsZXRlZC4u LgoKLi4uaW4gb3RoZXIgbm9uLVNDTUkgc2NlbmFyaW9zIHRoYXQgSSBleHBlcmltZW50ZWQgd2l0 aCwgaXQgcmVhbGx5IG1ha2VzIGEKZGlmZmVyZW5jZSBoYXZpZyB0aGUgVHhBY2sgc2luY2UgaXQg YXZvaWRzIGFsbCB0aGUgaW50ZXJuYWwgcG9sbGluZy9yZXF1ZXVlaW5nCmRhbmNlIGluIHRoZSBt YWlsYm94IHN1YnN5c3RlbSwgYnV0IGluIHRoaXMgY2FzZSBJIHRoaW5rIGlzIGFsbCBtYWRlIHVz ZWxlc3MgYnkKdGhlIHdheSBTQ01JL1NNVCBiYXNlZCB0cmFuc3BvcnQgd29ya3MuLi5pLmUuIHVz aW5nIGEgc2luZ2xlIHNobWVtIGFyZWEgZm9yCnRoZSBhMnAgY2hhbm5lbC4uCgouLi5ub3QgcmVh bGx5IGEgc2hvcnQgYW5kIHN3ZWV0IGVtYWlsLi4uIDpQIC4uLiBhbnkgZmVlZGJhY2sgb3IgZnVy dGhlcgppZGVhcyBhcmUgd2VsY29tZSBhbnl3YXkuLi5lc3BlY2lhbGx5IGlmIHlvdSBjYW4gcHJv dmUgdGhhdCBhbGwgb2YgdGhlCmFib3ZlIGlzIHNvbWVob3cgd3JvbmcsIG9yIHRoYXQgdGhlcmUg aXMgYSBnb29kIHJlYXNvbiB0byBsZXZlcmFnZSB0aGUKVHhBY2sgY2FwYWJsZSBtYWlsYm94ZXMg IDpECgpUaGFua3MsCkNyaXN0aWFuCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KbGludXgtYXJtLWtlcm5lbCBtYWlsaW5nIGxpc3QKbGludXgtYXJtLWtl cm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxt YW4vbGlzdGluZm8vbGludXgtYXJtLWtlcm5lbAo=