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 60693C54E49 for ; Thu, 7 Mar 2024 16:22:48 +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=pjYcLFm/bJ02pLt2Gm3e6+pzoNjTfCX//hSS8DLXtT4=; b=E1Vmu81Y1zCrchI3kPbsYP+qPm Y7E6JyihcBCldf6WODTYKuUB2NZZGbPAfKzmiqooByjIYo+Oaeqo7A4Ojv8QrrU53VYf2on89Od58 CDMOA10Q0z132EXKfOQSQZi6A6AiSTYK8S+yb/oWRdJch91ClehgmQ5VnPGUxS22Z/fnxzxM0Nh2w q2EKk45pUS5jvxnDK7RL1I+8pA4RC+iLlgOUgm4iKclwBKYR4nCeX+JzdA3gwXNC4nWdwLHBz5SIr XyEUihKBHuG8HBWAe12YtInJdLQG+9OAoJngsDWsTjUqwlW02jFOQ+gs04Q7dNchn+rtEC3/opq3d fz4T5RUg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1riGW7-00000005TWT-0v2L; Thu, 07 Mar 2024 16:22:47 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1riGW2-00000005TTI-0hen; Thu, 07 Mar 2024 16:22:44 +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 C97C1C15; Thu, 7 Mar 2024 08:23:14 -0800 (PST) Received: from pluto (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A223A3F73F; Thu, 7 Mar 2024 08:22:36 -0800 (PST) Date: Thu, 7 Mar 2024 16:22:34 +0000 From: Cristian Marussi To: Flash Liu =?utf-8?B?KOWKieeCs+WCsyk=?= Cc: "linux-kernel@vger.kernel.org" , "linux-mediatek@lists.infradead.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-20240307_082242_325470_4F12BCCF X-CRM114-Status: GOOD ( 75.93 ) 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 Thu, Mar 07, 2024 at 12:31:02PM +0000, Flash Liu (劉炳傳) wrote: > Hi Cristian, > > Thanks for reply. :) > > The uploaded patch is just to avoid getting error logs, since > mbox_client_txdone() will check the mode. ... yes right, the controller will detect the mode indeed based on how it is configured on the DT and issue the tx_tick() when the TxAck is received....your patch avoids the error when the SCMI stack tries to issue a mbox_client_txdone() and it is not expected to do so... ...what I am saying is that the TxAck txdone_irq mode is not compatible with how SCMI is designed to work in terms of transmission on the a2p channel...even if you make it work properly without any errors with your patch... ...so you will avoid the errors and make it work BUT it does not work realiably in case of multiple concurrent TX attempts...in my setup I see anomalies and loss of packets if I enable TxAck mode... > About your mentioned scenario of TxACK irq mode, not sure, but do you > mean that mbox driver may not "copy out" the REPLY mesg-X at shmem, the copy out of the REPLY is done by the SCNI layer, but anyway once the TxAck has been received there is nothing ready to be copied-out...the TxAck just means the requested message has been transmitted and it has been successfully received by the receiver (at least in my MBOX IP .. :P) > before it calls to mbox_chan_txdone()? > Could it become safe if we copy the REPLY mesg to a buffer and then > issue the tx_tick? In my understanding, the packet flow is as follows 1. Linux sends a new cmd with mbox_send_message() mbox subsys - queueus msg - submit: - tx_prepare - wait for FREE_bit on channel - copies msg in shmem area - ring doorbell 2. FW see the doorbell IRQ, a message has arrived - FW reads the incoming cmd message from shmem - FW rings the TxAck doorbell 3. Linux see the TxAck: at this point it knows that the message just sent has been received by FW...nothing more, NO reply is available to be read back at this point...Linux wait_for_completion 4. FW prepares the reply - FW writes reply to the shmem - FW sets the FREE bit in the shmem, channel ownership goes back to agent - FW rings the Doorbell 5. Linux see the RX doorbell IRQ and wakes up - reply is copied out and delivered to caller - mbox_client_txdone is called from mark_tx_done ...when TxAck ack is received at 3, there is nothing we can do Linux side because there is ONE only shmem area per-chandle both for cmd and related replies....so we cannot really do anything useful by knowing that the command we just sent was read successfully from the FW server.. ...moreover if the MBOX controller is in TxAck mode since it was configured like that by the DT, it will kick itself the tx_tick when the TxAck is received... ... that means that if you had another previous mbox_send_message() issued, that message would have been queued by mbox_subsys but not sent since a TX was already inflight, BUT now after the TxAck the tx_tick/msg_submit is called and the next message transmission is attempeted AND such request will now spin waiting for the FREE bit in cl->tx_prepare: this happens because we are at 3. and FW has still to send any reply... ..so you have one message sent and waited-for AND a new cmd queued for TX and spinning on FREE_bit waiting for the channel...so far so good ...but now in this situation imagine what will happen when finally FW replies in 4: as soon as the FREE_bit is flipped the above new transmission spinning inside tx_prepare will acquire the channel and write its payload in it, so OVERWRITING the previous reply that the FW has just written in shmem... In a nutshell, since we only have one shmem for cmd and reply in the a2p channel, we have to wait for the full SCMI transaction to be completed, and the reply to be retrieved, before writing the next command into shmem, BUT this is a knowledge that only the SCMI stack has...the mbox controller just know that a TxAck has been received, it cannot know that it is NOT allowed anyway to send the next... ..so basically in mailbox transport instead of using a lock to protect the channel (like in other transports) till the reply has been read, we let the SCMI agent client to issue the tx_tick only after the transmission has completed...this way no lock is needed because the mbox_subsys wont tx_tick and submit the next transmission till we are done...since the SCMI agent is the only one that can possibly know when it is safe to proceeed with another transmission when the TxAck is received there is nothing that we can copy-out...the reply is not available and there is nothing we can do...and in case of multiple concurrent transmissions you will have lost packets (as I see in my setup)... I would say that the check in your patch for txdone_irq could somehow become a check instead inside the mailbox_chan_setup() to detect such an unsupported controller configuration and bail out. The alternative would be to put a lock on the channel so that we can neutralized the effect of the TxAck ... but what;s the point of having it at this point :P > In addition, considering the following scenario: > > mesg-X (thread-X: low priority) > mesg-Y (thread-Y: high priority) > mesg-Z (thread-Z: high priority) > > 1. scmi: thread-X calls mbox_send_message(X) to send mesg-X, and goes > to wait_completion() > > 2. mbox: mesg-X is sent > > 3. scmi: ANOTHER mesg-Y tx is attempted via mbox_send_message(Y), > thread-Y goest to wait_completion() ...this does not even reach wat_for_completion, it will spin on the FREE_bit in tx_prepare trying to acquire the channel...so it wont even return from mailbox_send_message() > 3'. scmi: ANOTHER mesg-Z tx is attempted via mbox_send_message(Z), > thread-Z goest to wait_completion() > same .. queud on tx_prepare > 4. mbox: mesg-Y is queued > 4'. mbox: mesg-Z is queued > > 5. mbox irq received, ISR notify complete to thread-X, however system > is busy on other high priority threads, > so, thread-X doesn't back soon > ...mmm... one thing to consider indeed is what happens if I have 2 pending high-prio threads spinning on tx_prepare while the mesg-X IRQ arrives...would we be able to serve mesg-X IRQ if the cores are busy-waiting on mesg-Y / mesg-Z ? > 6. mesg-Y, mesg-Z get timed-out. > > Could the timeout situtaion of mesg-Y and Z be reduced, if tx_tick in > ISR? > > ... explains something might for TxACK irq mode... maybe you have other > observation or suggestions about this priority scenario. > I want to think about the threads prio you raised.... Thanks, Cristian > Thanks again, > Pin-Chuan > > On Wed, 2024-03-06 at 16:08 +0000, Cristian Marussi wrote: > > 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 > > > ************* MEDIATEK Confidentiality Notice ******************** > The information contained in this e-mail message (including any > attachments) may be confidential, proprietary, privileged, or otherwise > exempt from disclosure under applicable laws. It is intended to be > conveyed only to the designated recipient(s). Any use, dissemination, > distribution, printing, retaining or copying of this e-mail (including its > attachments) by unintended recipient(s) is strictly prohibited and may > be unlawful. If you are not an intended recipient of this e-mail, or believe > that you have received this e-mail in error, please notify the sender > immediately (by replying to this e-mail), delete any and all copies of > this e-mail (including any attachments) from your system, and do not > disclose the content of this e-mail to any other person. Thank you! 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 727D2C48BF6 for ; Thu, 7 Mar 2024 16:22:57 +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=MMZZA/48X7Y+Op2J69FzlL5rvTZ1hBfu/ojiezAJmvE=; b=UbpMX1wtADLqaZ rwvApQhYoeaFI+6l5sIgY06CmpTEh7pLOjNaKhGmVXbt+SlirhZdtid3R983tUy3gmEWIvqpfDNXA gAAP5avrXpQBrlhbm6wBQhCk8e4EY8xSxNZu3XT6wW4tmSWj83Mf6xhXfeTQOXISYgy6lxQB+KDaV SOIzWfT2fHa77Te5SaBB9Gek+ZFoTGZUXCR02v9v0SD7QeOw0Te8XSkbSTXXFDm9YiWCswg4tqfl6 nFFMvv3aUa88P7hrul7gRXEX7LygHNu9gZVPHxFOVLs/H/aEI3XhxZ4W/Z8bH15q/+M0r9h0Qxikq gSvd3RGFfhhVCgxRvnCQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1riGW6-00000005TVp-0TyT; Thu, 07 Mar 2024 16:22:46 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1riGW2-00000005TTI-0hen; Thu, 07 Mar 2024 16:22:44 +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 C97C1C15; Thu, 7 Mar 2024 08:23:14 -0800 (PST) Received: from pluto (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A223A3F73F; Thu, 7 Mar 2024 08:22:36 -0800 (PST) Date: Thu, 7 Mar 2024 16:22:34 +0000 From: Cristian Marussi To: Flash Liu =?utf-8?B?KOWKieeCs+WCsyk=?= Cc: "linux-kernel@vger.kernel.org" , "linux-mediatek@lists.infradead.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-20240307_082242_325470_4F12BCCF X-CRM114-Status: GOOD ( 75.93 ) 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 T24gVGh1LCBNYXIgMDcsIDIwMjQgYXQgMTI6MzE6MDJQTSArMDAwMCwgRmxhc2ggTGl1ICjlionn grPlgrMpIHdyb3RlOgo+IEhpIENyaXN0aWFuLAo+IAo+IFRoYW5rcyBmb3IgcmVwbHkuIDopCj4g Cj4gVGhlIHVwbG9hZGVkIHBhdGNoIGlzIGp1c3QgdG8gYXZvaWQgZ2V0dGluZyBlcnJvciBsb2dz LCBzaW5jZQo+IG1ib3hfY2xpZW50X3R4ZG9uZSgpIHdpbGwgY2hlY2sgdGhlIG1vZGUuCgouLi4g eWVzIHJpZ2h0LCB0aGUgY29udHJvbGxlciB3aWxsIGRldGVjdCB0aGUgbW9kZSBpbmRlZWQgYmFz ZWQgb24gaG93Cml0IGlzIGNvbmZpZ3VyZWQgb24gdGhlIERUIGFuZCBpc3N1ZSB0aGUgdHhfdGlj aygpIHdoZW4gdGhlIFR4QWNrIGlzCnJlY2VpdmVkLi4uLnlvdXIgcGF0Y2ggYXZvaWRzIHRoZSBl cnJvciB3aGVuIHRoZSBTQ01JIHN0YWNrIHRyaWVzIHRvCmlzc3VlIGEgbWJveF9jbGllbnRfdHhk b25lKCkgYW5kIGl0IGlzIG5vdCBleHBlY3RlZCB0byBkbyBzby4uLgoKLi4ud2hhdCBJIGFtIHNh eWluZyBpcyB0aGF0IHRoZSBUeEFjayB0eGRvbmVfaXJxIG1vZGUgaXMgbm90IGNvbXBhdGlibGUK d2l0aCBob3cgU0NNSSBpcyBkZXNpZ25lZCB0byB3b3JrIGluIHRlcm1zIG9mIHRyYW5zbWlzc2lv biBvbiB0aGUgYTJwCmNoYW5uZWwuLi5ldmVuIGlmIHlvdSBtYWtlIGl0IHdvcmsgcHJvcGVybHkg d2l0aG91dCBhbnkgZXJyb3JzIHdpdGggeW91cgpwYXRjaC4uLgoKLi4uc28geW91IHdpbGwgYXZv aWQgdGhlIGVycm9ycyBhbmQgbWFrZSBpdCB3b3JrIEJVVCBpdCBkb2VzIG5vdCB3b3JrCnJlYWxp YWJseSBpbiBjYXNlIG9mIG11bHRpcGxlIGNvbmN1cnJlbnQgVFggYXR0ZW1wdHMuLi5pbiBteSBz ZXR1cCBJIHNlZQphbm9tYWxpZXMgYW5kIGxvc3Mgb2YgcGFja2V0cyBpZiBJIGVuYWJsZSBUeEFj ayBtb2RlLi4uCgo+IEFib3V0IHlvdXIgbWVudGlvbmVkIHNjZW5hcmlvIG9mIFR4QUNLIGlycSBt b2RlLCBub3Qgc3VyZSwgYnV0IGRvIHlvdQo+IG1lYW4gdGhhdCBtYm94IGRyaXZlciBtYXkgbm90 ICJjb3B5IG91dCIgdGhlIFJFUExZIG1lc2ctWCBhdCBzaG1lbSwKCnRoZSBjb3B5IG91dCBvZiB0 aGUgUkVQTFkgaXMgZG9uZSBieSB0aGUgU0NOSSBsYXllciwgYnV0IGFueXdheSBvbmNlIHRoZQpU eEFjayBoYXMgYmVlbiByZWNlaXZlZCB0aGVyZSBpcyBub3RoaW5nIHJlYWR5IHRvIGJlIGNvcGll ZC1vdXQuLi50aGUKVHhBY2sganVzdCBtZWFucyB0aGUgcmVxdWVzdGVkIG1lc3NhZ2UgaGFzIGJl ZW4gdHJhbnNtaXR0ZWQgYW5kIGl0IGhhcwpiZWVuIHN1Y2Nlc3NmdWxseSByZWNlaXZlZCBieSB0 aGUgcmVjZWl2ZXIgKGF0IGxlYXN0IGluIG15IE1CT1ggSVAgLi4gOlApCgo+IGJlZm9yZSBpdCBj YWxscyB0byBtYm94X2NoYW5fdHhkb25lKCk/Cj4gQ291bGQgaXQgYmVjb21lIHNhZmUgaWYgd2Ug Y29weSB0aGUgUkVQTFkgbWVzZyB0byBhIGJ1ZmZlciBhbmQgdGhlbgo+IGlzc3VlIHRoZSB0eF90 aWNrPwoKSW4gbXkgdW5kZXJzdGFuZGluZywgdGhlIHBhY2tldCBmbG93IGlzIGFzIGZvbGxvd3MK CjEuIExpbnV4IHNlbmRzIGEgbmV3IGNtZCB3aXRoIG1ib3hfc2VuZF9tZXNzYWdlKCkKICAgbWJv eCBzdWJzeXMKICAgIC0gcXVldWV1cyBtc2cKICAgIC0gc3VibWl0OgogICAgICAtIHR4X3ByZXBh cmUKICAgICAgICAtIHdhaXQgZm9yIEZSRUVfYml0IG9uIGNoYW5uZWwKCS0gY29waWVzIG1zZyBp biBzaG1lbSBhcmVhCiAgICAgIC0gcmluZyBkb29yYmVsbAoKMi4gRlcgc2VlIHRoZSBkb29yYmVs bCBJUlEsIGEgbWVzc2FnZSBoYXMgYXJyaXZlZAogICAtIEZXIHJlYWRzIHRoZSBpbmNvbWluZyBj bWQgbWVzc2FnZSBmcm9tIHNobWVtCiAgIC0gRlcgcmluZ3MgdGhlIFR4QWNrIGRvb3JiZWxsCgoz LiBMaW51eCBzZWUgdGhlIFR4QWNrOiBhdCB0aGlzIHBvaW50IGl0IGtub3dzIHRoYXQgdGhlIG1l c3NhZ2UganVzdAogICBzZW50IGhhcyBiZWVuIHJlY2VpdmVkIGJ5IEZXLi4ubm90aGluZyBtb3Jl LCBOTyByZXBseSBpcyBhdmFpbGFibGUKICAgdG8gYmUgcmVhZCBiYWNrIGF0IHRoaXMgcG9pbnQu Li5MaW51eCB3YWl0X2Zvcl9jb21wbGV0aW9uCgo0LiBGVyBwcmVwYXJlcyB0aGUgcmVwbHkKICAg LSBGVyB3cml0ZXMgcmVwbHkgdG8gdGhlIHNobWVtCiAgIC0gRlcgc2V0cyB0aGUgRlJFRSBiaXQg aW4gdGhlIHNobWVtLCBjaGFubmVsIG93bmVyc2hpcCBnb2VzIGJhY2sgdG8KICAgICBhZ2VudAog ICAtIEZXIHJpbmdzIHRoZSBEb29yYmVsbAoKNS4gTGludXggc2VlIHRoZSBSWCBkb29yYmVsbCBJ UlEgYW5kIHdha2VzIHVwCiAgIC0gcmVwbHkgaXMgY29waWVkIG91dCBhbmQgZGVsaXZlcmVkIHRv IGNhbGxlcgogICAtIG1ib3hfY2xpZW50X3R4ZG9uZSBpcyBjYWxsZWQgZnJvbSBtYXJrX3R4X2Rv bmUKCi4uLndoZW4gVHhBY2sgYWNrIGlzIHJlY2VpdmVkIGF0IDMsIHRoZXJlIGlzIG5vdGhpbmcg d2UgY2FuIGRvIExpbnV4CnNpZGUgYmVjYXVzZSB0aGVyZSBpcyBPTkUgb25seSBzaG1lbSBhcmVh IHBlci1jaGFuZGxlIGJvdGggZm9yIGNtZCBhbmQKcmVsYXRlZCByZXBsaWVzLi4uLnNvIHdlIGNh bm5vdCByZWFsbHkgZG8gYW55dGhpbmcgdXNlZnVsIGJ5IGtub3dpbmcKdGhhdCB0aGUgY29tbWFu ZCB3ZSBqdXN0IHNlbnQgd2FzIHJlYWQgc3VjY2Vzc2Z1bGx5IGZyb20gdGhlIEZXCnNlcnZlci4u CgouLi5tb3Jlb3ZlciBpZiB0aGUgTUJPWCBjb250cm9sbGVyIGlzIGluIFR4QWNrIG1vZGUgc2lu Y2UgaXQgd2FzCmNvbmZpZ3VyZWQgbGlrZSB0aGF0IGJ5IHRoZSBEVCwgaXQgd2lsbCBraWNrIGl0 c2VsZiB0aGUgdHhfdGljayB3aGVuIHRoZQpUeEFjayBpcyByZWNlaXZlZC4uLgoKLi4uIHRoYXQg bWVhbnMgdGhhdCBpZiB5b3UgaGFkIGFub3RoZXIgcHJldmlvdXMgbWJveF9zZW5kX21lc3NhZ2Uo KSBpc3N1ZWQsCiB0aGF0IG1lc3NhZ2Ugd291bGQgaGF2ZSBiZWVuIHF1ZXVlZCBieSBtYm94X3N1 YnN5cyBidXQgbm90IHNlbnQgc2luY2UKIGEgVFggd2FzIGFscmVhZHkgaW5mbGlnaHQsIEJVVCBu b3cgYWZ0ZXIgdGhlIFR4QWNrIHRoZSB0eF90aWNrL21zZ19zdWJtaXQgaXMKIGNhbGxlZCBhbmQg dGhlIG5leHQgbWVzc2FnZSB0cmFuc21pc3Npb24gaXMgYXR0ZW1wZXRlZCBBTkQgc3VjaCByZXF1 ZXN0CiB3aWxsIG5vdyBzcGluIHdhaXRpbmcgZm9yIHRoZSBGUkVFIGJpdCBpbiBjbC0+dHhfcHJl cGFyZTogdGhpcyBoYXBwZW5zCiBiZWNhdXNlIHdlIGFyZSBhdCAzLiBhbmQgRlcgaGFzIHN0aWxs IHRvIHNlbmQgYW55IHJlcGx5Li4uCgogLi5zbyB5b3UgaGF2ZSBvbmUgbWVzc2FnZSBzZW50IGFu ZCB3YWl0ZWQtZm9yIEFORCBhIG5ldyBjbWQgcXVldWVkIGZvciBUWAogYW5kIHNwaW5uaW5nIG9u IEZSRUVfYml0IHdhaXRpbmcgZm9yIHRoZSBjaGFubmVsLi4uc28gZmFyIHNvIGdvb2QKCi4uLmJ1 dCBub3cgaW4gdGhpcyBzaXR1YXRpb24gaW1hZ2luZSB3aGF0IHdpbGwgaGFwcGVuIHdoZW4gZmlu YWxseSBGVwogcmVwbGllcyBpbiA0OiBhcyBzb29uIGFzIHRoZSBGUkVFX2JpdCBpcyBmbGlwcGVk IHRoZSBhYm92ZSBuZXcgdHJhbnNtaXNzaW9uCiBzcGlubmluZyBpbnNpZGUgdHhfcHJlcGFyZSB3 aWxsIGFjcXVpcmUgdGhlIGNoYW5uZWwgYW5kIHdyaXRlIGl0cyBwYXlsb2FkIGluCiBpdCwgc28g T1ZFUldSSVRJTkcgdGhlIHByZXZpb3VzIHJlcGx5IHRoYXQgdGhlIEZXIGhhcyBqdXN0IHdyaXR0 ZW4gaW4gc2htZW0uLi4KCiBJbiBhIG51dHNoZWxsLCBzaW5jZSB3ZSBvbmx5IGhhdmUgb25lIHNo bWVtIGZvciBjbWQgYW5kIHJlcGx5IGluIHRoZQogYTJwIGNoYW5uZWwsIHdlIGhhdmUgdG8gd2Fp dCBmb3IgdGhlIGZ1bGwgU0NNSSB0cmFuc2FjdGlvbiB0byBiZQogY29tcGxldGVkLCBhbmQgdGhl IHJlcGx5IHRvIGJlIHJldHJpZXZlZCwgYmVmb3JlIHdyaXRpbmcgdGhlIG5leHQgY29tbWFuZAog aW50byBzaG1lbSwgQlVUIHRoaXMgaXMgYSBrbm93bGVkZ2UgdGhhdCBvbmx5IHRoZSBTQ01JIHN0 YWNrIGhhcy4uLnRoZSBtYm94CiBjb250cm9sbGVyIGp1c3Qga25vdyB0aGF0IGEgVHhBY2sgaGFz IGJlZW4gcmVjZWl2ZWQsIGl0IGNhbm5vdCBrbm93CiB0aGF0IGl0IGlzIE5PVCBhbGxvd2VkIGFu eXdheSB0byBzZW5kIHRoZSBuZXh0Li4uCgogLi5zbyBiYXNpY2FsbHkgaW4gbWFpbGJveCB0cmFu c3BvcnQgaW5zdGVhZCBvZiB1c2luZyBhIGxvY2sgdG8gcHJvdGVjdCB0aGUKIGNoYW5uZWwgKGxp a2UgaW4gb3RoZXIgdHJhbnNwb3J0cykgdGlsbCB0aGUgcmVwbHkgaGFzIGJlZW4gcmVhZCwgd2Ug bGV0CiB0aGUgU0NNSSBhZ2VudCBjbGllbnQgdG8gaXNzdWUgdGhlIHR4X3RpY2sgb25seSBhZnRl ciB0aGUgdHJhbnNtaXNzaW9uIGhhcwogY29tcGxldGVkLi4udGhpcyB3YXkgbm8gbG9jayBpcyBu ZWVkZWQgYmVjYXVzZSB0aGUgbWJveF9zdWJzeXMgd29udAogdHhfdGljayBhbmQgc3VibWl0IHRo ZSBuZXh0IHRyYW5zbWlzc2lvbiB0aWxsIHdlIGFyZSBkb25lLi4uc2luY2UgdGhlIFNDTUkKIGFn ZW50IGlzIHRoZSBvbmx5IG9uZSB0aGF0IGNhbiBwb3NzaWJseSBrbm93IHdoZW4gaXQgaXMgc2Fm ZSB0byBwcm9jZWVlZCB3aXRoCiBhbm90aGVyIHRyYW5zbWlzc2lvbgoKIHdoZW4gdGhlIFR4QWNr IGlzIHJlY2VpdmVkIHRoZXJlIGlzIG5vdGhpbmcgdGhhdCB3ZSBjYW4gY29weS1vdXQuLi50aGUK IHJlcGx5IGlzIG5vdCBhdmFpbGFibGUgYW5kIHRoZXJlIGlzIG5vdGhpbmcgd2UgY2FuIGRvLi4u YW5kIGluIGNhc2Ugb2YKIG11bHRpcGxlIGNvbmN1cnJlbnQgdHJhbnNtaXNzaW9ucyB5b3Ugd2ls bCBoYXZlIGxvc3QgcGFja2V0cyAoYXMgSSBzZWUKIGluIG15IHNldHVwKS4uLgoKSSB3b3VsZCBz YXkgdGhhdCB0aGUgY2hlY2sgaW4geW91ciBwYXRjaCBmb3IgdHhkb25lX2lycSBjb3VsZCBzb21l aG93CmJlY29tZSBhIGNoZWNrIGluc3RlYWQgaW5zaWRlIHRoZSBtYWlsYm94X2NoYW5fc2V0dXAo KSB0byBkZXRlY3Qgc3VjaCBhbgp1bnN1cHBvcnRlZCBjb250cm9sbGVyIGNvbmZpZ3VyYXRpb24g YW5kIGJhaWwgb3V0LgoKVGhlIGFsdGVybmF0aXZlIHdvdWxkIGJlIHRvIHB1dCBhIGxvY2sgb24g dGhlIGNoYW5uZWwgc28gdGhhdCB3ZSBjYW4KbmV1dHJhbGl6ZWQgdGhlIGVmZmVjdCBvZiB0aGUg VHhBY2sgLi4uIGJ1dCB3aGF0O3MgdGhlIHBvaW50IG9mIGhhdmluZyBpdAphdCB0aGlzIHBvaW50 IDpQCgo+IEluIGFkZGl0aW9uLCBjb25zaWRlcmluZyB0aGUgZm9sbG93aW5nIHNjZW5hcmlvOgo+ IAo+IG1lc2ctWCAodGhyZWFkLVg6IGxvdyBwcmlvcml0eSkKPiBtZXNnLVkgKHRocmVhZC1ZOiBo aWdoIHByaW9yaXR5KQo+IG1lc2ctWiAodGhyZWFkLVo6IGhpZ2ggcHJpb3JpdHkpCj4gCj4gMS4g c2NtaTogdGhyZWFkLVggY2FsbHMgbWJveF9zZW5kX21lc3NhZ2UoWCkgdG8gc2VuZCBtZXNnLVgs IGFuZCBnb2VzCj4gdG8gd2FpdF9jb21wbGV0aW9uKCkKPiAKPiAyLiBtYm94OiBtZXNnLVggaXMg c2VudAo+IAo+IDMuIHNjbWk6IEFOT1RIRVIgbWVzZy1ZIHR4IGlzIGF0dGVtcHRlZCB2aWEgbWJv eF9zZW5kX21lc3NhZ2UoWSksCj4gdGhyZWFkLVkgZ29lc3QgdG8gd2FpdF9jb21wbGV0aW9uKCkK Ci4uLnRoaXMgZG9lcyBub3QgZXZlbiByZWFjaCB3YXRfZm9yX2NvbXBsZXRpb24sIGl0IHdpbGwg c3BpbiBvbiB0aGUKRlJFRV9iaXQgaW4gdHhfcHJlcGFyZSB0cnlpbmcgdG8gYWNxdWlyZSB0aGUg Y2hhbm5lbC4uLnNvIGl0IHdvbnQgZXZlbgpyZXR1cm4gZnJvbSBtYWlsYm94X3NlbmRfbWVzc2Fn ZSgpCgo+IDMnLiBzY21pOiBBTk9USEVSIG1lc2ctWiB0eCBpcyBhdHRlbXB0ZWQgdmlhIG1ib3hf c2VuZF9tZXNzYWdlKFopLAo+IHRocmVhZC1aIGdvZXN0IHRvIHdhaXRfY29tcGxldGlvbigpCj4g CgpzYW1lIC4uIHF1ZXVkIG9uIHR4X3ByZXBhcmUKCj4gNC4gbWJveDogbWVzZy1ZIGlzIHF1ZXVl ZAo+IDQnLiBtYm94OiBtZXNnLVogaXMgcXVldWVkCj4gCj4gNS4gbWJveCBpcnEgcmVjZWl2ZWQs IElTUiBub3RpZnkgY29tcGxldGUgdG8gdGhyZWFkLVgsIGhvd2V2ZXIgc3lzdGVtCj4gaXMgYnVz eSBvbiBvdGhlciBoaWdoIHByaW9yaXR5IHRocmVhZHMsCj4gc28sIHRocmVhZC1YIGRvZXNuJ3Qg YmFjayBzb29uCj4gCgouLi5tbW0uLi4gb25lIHRoaW5nIHRvIGNvbnNpZGVyIGluZGVlZCBpcyB3 aGF0IGhhcHBlbnMgaWYgSSBoYXZlIDIgcGVuZGluZwpoaWdoLXByaW8gdGhyZWFkcyBzcGlubmlu ZyBvbiB0eF9wcmVwYXJlIHdoaWxlIHRoZSBtZXNnLVggSVJRIGFycml2ZXMuLi53b3VsZCB3ZQpi ZSBhYmxlIHRvIHNlcnZlIG1lc2ctWCBJUlEgaWYgdGhlIGNvcmVzIGFyZSBidXN5LXdhaXRpbmcg b24gbWVzZy1ZIC8gbWVzZy1aID8KCj4gNi4gbWVzZy1ZLCBtZXNnLVogZ2V0IHRpbWVkLW91dC4K PiAKPiBDb3VsZCB0aGUgdGltZW91dCBzaXR1dGFpb24gb2YgbWVzZy1ZIGFuZCBaIGJlIHJlZHVj ZWQsIGlmIHR4X3RpY2sgaW4KPiBJU1I/Cj4gCj4gLi4uIGV4cGxhaW5zIHNvbWV0aGluZyBtaWdo dCBmb3IgVHhBQ0sgaXJxIG1vZGUuLi4gbWF5YmUgeW91IGhhdmUgb3RoZXIKPiBvYnNlcnZhdGlv biBvciBzdWdnZXN0aW9ucyBhYm91dCB0aGlzIHByaW9yaXR5IHNjZW5hcmlvLgo+IAoKSSB3YW50 IHRvIHRoaW5rIGFib3V0IHRoZSB0aHJlYWRzIHByaW8geW91IHJhaXNlZC4uLi4KClRoYW5rcywK Q3Jpc3RpYW4KCj4gVGhhbmtzIGFnYWluLAo+IFBpbi1DaHVhbgo+IAo+IE9uIFdlZCwgMjAyNC0w My0wNiBhdCAxNjowOCArMDAwMCwgQ3Jpc3RpYW4gTWFydXNzaSB3cm90ZToKPiA+IE9uIFdlZCwg TWFyIDA2LCAyMDI0IGF0IDA5OjQ5OjE2QU0gKzAwMDAsIENyaXN0aWFuIE1hcnVzc2kgd3JvdGU6 Cj4gPiA+IE9uIFdlZCwgTWFyIDA2LCAyMDI0IGF0IDA2OjEzOjQ4QU0gKzAwMDAsIEZsYXNoIExp dSAo5YqJ54Kz5YKzKSB3cm90ZToKPiA+ID4gPiBIaSBDcmlzdGlhbiwKPiA+ID4gPgo+ID4gPiA+ IEtpbmRseSBwaW5nIDopCj4gPiA+ID4KPiA+ID4KPiA+ID4gSGkgUGluLUNodWFuLAo+ID4gPgo+ ID4gPiBzb3JyeSBmb3IgdGhlIGRlbGF5Li4uSSBoYXZlIE5PVCBmb3Jnb3QgOkQsIGluZGVlZCBJ IHdhcyBqdXN0Cj4gPiA+IHRlc3RpbmcKPiA+ID4geWVzdGVyZGF5IHdpdGggc29tZSBtYWlsYm94 IElQIG9mIG91cnMgZXF1aXBwZWQgd2l0aCBhIFR4QWNrIElSUQo+ID4gPiBhbmQgSQo+ID4gPiB3 b3VsZCBoYXZlIHNvbWUgcXVlc3Rpb24gZm9yIHlvdSBiZWNhdXNlIEkndmUgc2VlbiBzb21lIGFu b21hbGllcwo+ID4gPiB3aGlsZQo+ID4gPiB1c2luZyB0aGlzOiBkb2VzIHlvdXIgc29sdXRpb24g d29yayByZWxpYWJseSBpbiB5b3VyIHNldHVwIEFMU08KPiA+ID4gd2hlbgo+ID4gPiBtdWx0aXBs ZSBTQ01JIHRyYW5zYWN0aW9ucyBhcmUgYXR0ZW1wdGVkID8gKGxpa2UgY3B1ZnJlcSBpc3N1aW5n Cj4gPiA+IGNtZHMKPiA+ID4gd2hpbGUgcG9sbGluZyBhIHNlbnNvciBmcm9tIHNvbWUgb3RoZXIg dGhyZWFkKQo+ID4gPgo+ID4gPiAuLi5JJ2xsIGRpZyBkZWVwZXIgdG9kYXkgaW4gdGhpcyBtYXR0 ZXIsIGJ1dCBteSBjdXJyZW50IHN1c3BlY3QgaXMKPiA+ID4gdGhhdAo+ID4gPiB1c2luZyB0aGUg bWFpbGJveCBUWEFjayBJUlEgdG8gbGV0IHRoZSBjb250cm9sbGVyIHRpY2sgdGhlIGludGVybmFs Cj4gPiA+IG1haWxib3gKPiA+ID4gcXVldWVzIGRvZXMgbm90IHBsYXkgd2VsbCB3aXRoIFNDTUks IHNpbmNlIHRoZSBTQ01JIFRYIGNoYW5uZWwgaXMKPiA+ID4gcmVhbGx5IHRoZQo+ID4gPiBTQ01J ICJhMnAiIGJpZGlyZWN0aW9uYWwgY2hhbm5lbCBhbmQgaXQgaXMgYXNzb2NpYXRlZCB3aXRoIGp1 c3QKPiA+ID4gb25seSBvbmUgc2htZW0KPiA+ID4gYXJlYSB1c2VkIHRvIGhvbGQgYm90aCB0aGUg ZWdyZXNzaW5nIENNRCBhbmQgdG8gcmVjZWl2ZSB0aGUKPiA+ID4gaW5jb21pbmcgUkVQTFkKPiA+ ID4gZnJvbSB0aGUgcGxhdGZvcm06IHNvIGlmIHlvdSBsZXQgdGhlIGNvbnRyb2xsZXIgdGljayB0 aGUgcXVldWVzIGFzCj4gPiA+IHNvb24gYXMgeW91Cj4gPiA+IHJlY2VpdmVkIHRoZSBUWEFjayB5 b3UgYXJlIHRlbGxpbmcgdGhlIG1haWxib3ggc3Vic3lzdGVtIHRvIHF1ZXVlCj4gPiA+IGFub3Ro ZXIgbWVzc2FnZQo+ID4gPiBvbiB0aGUgc2FtZSBhcmVhIHdoaWxlIHlvdSBhcmUgbm90IHJlYWxs eSBkb25lLCBzaW5jZSBvbmx5IHRoZQo+ID4gPiBjbGllbnQga25vdwo+ID4gPiB3aGVuIGl0J3Mg ZG9uZSB3aXRoIHRoZSB3aG9sZSBTQ01JIHRyYW5zYWN0aW9uIGFuZCB0aGUgcmVwbHkgaGFzCj4g PiA+IGJlZW4gZmV0Y2hlZC4KPiA+ID4KPiA+ID4gSW5kZWVkLCBmb3IgdGhlc2UgcmVhc29ucyB3 ZSBoYXZlIHRoZSBCVVNZL0ZSRUUgYml0IGluIHRoZSBzaG1lbSB0bwo+ID4gPiBwcm90ZWN0IGl0 Cj4gPiA+IGZyb20gcGVuZGluZyBuZXcgcmVxdWVzdHMgdW50aWwgdGhlIHByZXZpb3VzIG9uZSBo YXMgY29tcGxldGVkLCBidXQKPiA+ID4gd2hlbiB0aGUKPiA+ID4gd2FpdGVkLWZvciByZXBseSBj b21lcyBpbiwgdGhlIHBsYXRmb3JtIHdvdWxkIGhhdmUgY2xlYXJlZCB0aGUgQlVTWQo+ID4gPiBi aXQgYW5kCj4gPiA+IGxldCB0aGUgbmV3IHF1ZXVlZCBtZXNzYWdlIG92ZXJ3cml0ZSB0aGUgcGVu ZGluZyByZXBseSBwcmVtYXR1cmVseSwKPiA+ID4gYW5kIG9uZQo+ID4gPiBtZXNzYWdlIGlzIGxv c3QuLi4KPiA+ID4KPiA+ID4gLi4uYnV0IGFzIHNhaWQgSSB3YW50IHRvIGRlbHZlIGRlZXBlciBp bnRvIHRoaXMsIGFzIG9mIG5vdyBqdXN0Cj4gPiA+IHN1cHBvc2l0aW9ucwo+ID4gPiBhbmQgbWF5 YmUgSSBhbSBqdXN0IG1pc3Npbmcgc29tZXRoaW5nIG1vcmUgdGhhdCBoYXMgdG8gYmUKPiA+ID4g Y29uZmlndXJlZAo+ID4gPiBwcm9wZXJseS4uLgo+ID4gPgo+ID4gPiBUaGFua3MsCj4gPiA+IENy aXN0aWFuCj4gPiA+Cj4gPgo+ID4gSGkgYWdhaW4gOkQsCj4gPgo+ID4gc28gYXJ0aWN1bGF0aW5n IG1vcmUgb24gbXkgc3VwcG9zaXRpb24gdGhhdCBUeEFjay1jYXBhYmxlIG1haWxib3hlcwo+ID4g YW5kCj4gPiBTQ01JIGRvIG5vdCBwbGF5IHdlbGwgdG9nZXRoZXIgKGFuZCB3b3VsZCBub3QgYmUg d29ydGggZWl0aGVyCj4gPiByZWFsbHkuLi4pCj4gPgo+ID4gQ29uc2lkZXIgdGhlIGZvbGxvd2lu ZyBzY2VuYXJpby4KPiA+Cj4gPiAxLiBzY21pOiBtYm94X3NlbmRfbWVzc2FnZShYKSBpcyBjYWxs ZWQgZnJvbSBTQ01JIHN0YWNrIHRvIHNlbmQgbWVzZy0KPiA+IFgKPiA+ICAgICAgICAgIG9uIHRo ZSBhMnAgY2hhbm5lbCAoYSBjb21tYW5kKQo+ID4KPiA+IDIuIG1ib3g6IG1lc2ctWCBpcwo+ID4g ICAyYS4gcXVldWVkIGJ5IG1ib3ggc3Vic3lzdGVtIFthZGRfdG9fcmJ1ZihYKV0KPiA+ICAgMmIu IHN1Ym1pdHRlZCBmb3IgdHJhbnNtaXNzaW9uIFttc2dfc3VibWl0KFgpXQo+ID4gICAyYy4gcHJl cGFyZWQgYnkgU0NNSSBjbGstPnR4X3ByZXBhcmUKPiA+ICAgMmQuIGZpbmFsbHkgc2VudCB2aWEg bWh1IGRyaXZlciAuc2VuZF9kYXRhCj4gPiAgIDJlLiBtZXNnLVggaXMgbm93IGFuIGFjdGl2ZV9y ZXEgZm9yIG1ib3ggYW5kIGluLWZsaWdodCBmb3IgU0NNSQo+ID4KPiA+IDMuIHNjbWk6IEFOT1RI RVIgbWVzZy1ZIHR4IGlzIGF0dGVtcHRlZCB2aWEgbWJveF9zZW5kX21lc3NhZ2UoWSkKPiA+Cj4g PiA0LiBtYm94OiBtZXNnLVkgaXMKPiA+ICAgNGEuIHF1ZXVlZCBieSBtYm94X3N1YnN5cyBbYWRk X3RvX3JidWYoKV0KPiA+ICAgNGIuIE5PVCBzdWJtaXR0ZWQgc2luY2UgdGhlcmUgaXMgYWxyZWFk eSBhbiBhY3RpdmVfcmVxPW1lc2ctWAo+ID4gcGVuZGluZwo+ID4KPiA+IEFueSBmdXJ0aGVyIFND TUkgbWVzZyBUWCBhdHRlbXB0IHdpbGwgYmVoYXZlIHNpbWlsYXJseToKPiA+IHF1ZXVlZC9ub3Rf c3VibWl0dGVkCj4gPiB0aWxsIGF0IHNvbWUgaW4gdGhlIGZ1dHVyZSBzb21lb25lIGNhbGxzIHRo ZSB0eGRvbmUgcm91dGluZXMsIHdoaWNoCj4gPiBpbiB0dXJuCj4gPiBjYWxscyB0eF90aWNrKCku Li50aGlzIFNPTUVPTkUgY2FuIGJlIHRoZSBjbGllbnQsIGxpa2UgaXQgaXMgbm93LCBvcgo+ID4g dGhlCj4gPiBjb250cm9sbGVyIGlmIGl0IGlzIGNvbmZpZ3VyZWQgdG8gdXNlIHRoZSBUeEFjayBJ UlEgKGFzIHBlci15b3VyLQo+ID4gcGF0Y2gpLi4uCj4gPiAuLi5zbyBsZXRzIHNlZSB3aGF0IGhh cHBlbiBpbiB5b3VyIFR4QWNrIGVuYWJsZWQgY2FzZS4KPiA+Cj4gPiA1LiBUeEFjayBJUlEgcmVj ZWl2ZWQsIHRyYW5zbWlzc2lvbiBvZiBtZXNnLVggaGFzIGJlZW4gc3VjY2Vzc2Z1bGwKPiA+ICAg KE5PVEUgdGhhdCBTQ01JIGF0IHRoaXMgcG9pbnQgaXMgc3RpbGwgd2FpdGluZyBmb3IgYSByZXBs eSB0byBtZXNnLQo+ID4gWC4uKQo+ID4KPiA+ICAgNWEuIGNvbnRyb2xsZXIgY2FsbHMgbWJveF9j aGFuX3R4ZG9uZSgpCj4gPiAgIDViLiBtYm94IGluIHR1cm4gY2FsbHMgdHhfdGljawo+ID4gICA1 Yy4gYWN0aXZlX3JlcSBpcyBjbGVhcmVkIGFuZCBuZXh0IHF1ZXVlZCBtZXNnLVkgaXMgc3VibWl0 dGVkCj4gPiAgIDVkLiBtZXNnLVkgdHJhbnNtaXNzaW9uIGdldHMgYW55d2F5IHN0dWNrIG9uIGNs LT50eF9wcmVwYXJlIHNpbmNlCj4gPiAgICAgICB3ZSBjaGVjayB0aGUgU0NNSSBzaG1lbSBCVVNZ IGJpdCBhbmQgYnVzeS1sb29wIHRoZXJlIHRpbGwgaXQKPiA+ICAgICAgIGNsZWFyczogdGhpcyBj bGVhcmluZyBjYW4gaGFwcGVuIE9OTFkgYWZ0ZXIgdGhlIG1lc2ctWCByZXBseQo+ID4gICAgICAg aGFzIGNvbWUgdGhyb3VnaCwgc2luY2UgaXQgaXMgdGhlIHBsYXRmb3JtIFNDTUkgc2VydmVyIHRo YXQKPiA+ICAgICAgIGNsZWFycyBpdCBoYXZpbmcgZGVsaXZlcmVkIHRoZSByZXBseSBpbiB0aGUg c2htZW0uCj4gPgo+ID4gNi4gcGxhdGZvcm0gU0NNSSBzZXJ2ZXIgcmVwbGllcyB0byBtZXNnLVgg ZmluYWxseToKPiA+ICAgNmEuIHBsYXRmb3JtIHdyaXRlcyByZXBseSBpbiBzaG1lbQo+ID4gICA2 Yi4gcGxhdGZvcm0gY2xlYXJzIEJVU1kgYml0Cj4gPgo+ID4gICAtLSBub3RlIFNDTUkgc3RhY2sg aXMgc3RpbGwgd2FpdGluZyBmb3IgYSByZXBseSBhdCB0aGlzIHBvaW50Li4uCj4gPiAgICAgIHNv IHdhaXRpbmcgZm9yIGFuIElSUSBPUiBieSBzaW1wbHkgc3Bpbm5pbmcgb24gdGhhdCBzYW1lIEJV U1kKPiA+IGJpdAo+ID4gICAgICBpZiBwb2xsaW5nIG1vZGUgd2FzIHJlcXVlc3RlZCBmb3IgdGhl IHRyYW5zYWN0aW9uLi4uLgo+ID4KPiA+ICAgICAgLi4ubGV0cyBhc3N1bWUgeW91IGFyZSBpbiBJ UlEgbW9kZToKPiA+Cj4gPiA3LiBtZXNnLVkgc2VuZGVyIHdoaWNoIHdhcyBzcGlubmluZyBvbiBC VVNZIGJpdCAoYmxvY2tlZCBvbgo+ID4gdHhfcHJlcGFyZSkKPiA+ICAgIGlzIGltbWVkaWF0ZWx5 IGNsZWFyZWQgdG8gc2VuZCBhbmQgc28gdHhfcHJlcGFyZSBjYW4gcHJvY2VlZAo+ID4gZnVydGhl cgo+ID4gICAgYW5kIGNvbXBsZXRlbHkgb3ZlcndyaXRlIHRoZSBqdXN0IHJlY2VpdmVkIG1lc2ct WCwgd2hpY2ggaXMgbm93Cj4gPiBMT1NUCj4gPgo+ID4gLi5pbiBjYXNlIHlvdSB3ZXJlIHBvbGxp bmcgSSBndWVzcyB5b3Ugd2lsbCBoYXZlIGFueXdheSBzb21lCj4gPiBjb3JydXB0aW9uCj4gPiBk dWUgdG8gdGhlIHJhY2UgYmV0d2VlbiB0aGUgcG9sbGluZy1tZXNnLVgtcmVjZWl2ZXIgcmV0cmll dmluZyB0aGUKPiA+IHJlcGx5Cj4gPiBhbmQgdGhlIHNhbWUgdHhfcHJlcGFyZSBjb2RlZmxvdyBh cyBhYm92ZS4uLgo+ID4KPiA+IEluZGVlZCwgdGhlIHNwZWMgc2F5cyB0aGF0IHlvdSBzaG91bGQg cHJvdGVjdCB0aGUgY2hhbm5lbCB0aWxsIHRoZQo+ID4gcmVwbHkKPiA+IGhhcyBiZWVuIHJldHJp ZXZlZCBmcm9tIHRoZSBTQ01JIChldmVuIGFmdGVyIHRoZSBCVVNZIGJpdCBpcwo+ID4gY2xlYXJl ZCksIGFuZAo+ID4gaW4gb3RoZXIgdHJhbnNwb3J0IHdlIERPIGhhdmUgc29tZSBmb3JtIG9mIGxv Y2tzLCBCVVQgaGVyZSBpbgo+ID4gbWFpbGJveGVzCj4gPiB0aGVyZSBpcyBub3Qgc2luY2UgaXQg aXMgTk9UIG5lZWRlZCBJRiB5b3Ugc3RpY2sgdG8gdGhlIG5vbi1UeEFjawo+ID4gb3JpZ2luYWwK PiA+IGJlaGF2aW91ciwgc2luY2UgdGhlIHR4X3RpY2ssIGFzIGl0IGlzIG5vdywgd2lsbCBiZSBy dW4gYnkgdGhlIFNDTUkKPiA+IHN0YWNrCj4gPiBPTkxZIGFmdGVyIGl0IGhhcyB3YWl0ZWQgZm9y IG1lc2ctWCBhbmQgcmV0cmlldmVkIHRoZSBtZXNnLVgtcmVwbHkKPiA+IHBheWxvYWQKPiA+IC4u Lm5vdCBiZWZvcmUuCj4gPgo+ID4gSW5zdGVhZCwgaWYgeW91IGVuYWJsZSB0aGUgVHhBY2sgbW9k ZSB5b3UgYXJlIGJhc2ljYWxseSBsZXR0aW5nIHRoZQo+ID4gY29udHJvbGxlcgo+ID4gaXRzZWxm IGlzc3VlIHRoZSB0eF90aWNrKCksIHdoaWNoIG1lYW5zICJwcmV2aW91cyBUWCBpcyBkb25lLCBw bGVhc2UKPiA+IHByb2NlZWQKPiA+IHdpdGggdGhlIG5leHQiLCBCVVQgdGhlIGN1cnJlbnQgVFgg aXMgcmVhbGx5IE5PVCBkb25lIGF0IGFsbCBhcwo+ID4gaW50ZW5kZWQKPiA+IGJ5IHRoZSBjbGll bnQgKFNDTUkpLCBzaW5jZSB0aGUgcmVwbHkgaXMgbWlzc2luZyBhbmQgdGhlIG9ubHkgZW50aXR5 Cj4gPiB3aGljaAo+ID4gY2FuIGhhdmUgdGhlIHdob2xlIHBpY3R1cmUgYWJvdXQgd2hlbiBhIHRy YW5zYWN0aW9uIGlzIGNvbXBsZXRlZCAob3IKPiA+IHRpbWVkLW91dCkKPiA+IGlzIHRoZSBTQ01J IGNsaWVudC4KPiA+Cj4gPiBBcyBzYWlkLCBJIHRoaW5rIHRoZSBmdW5kYW1lbnRhbCBjbGFzaCBp cyBiZXR3ZWVuIHdoYXQgdGhlIG1haWxib3gKPiA+IHN1YnN5c3RlbSBjb25zaWRlcnMgYSBUWERP TkUgZXZlbnQgKGFuZCByZWxhdGVkIGFjdGlvbnMpIGFuZCB3aGF0Cj4gPiBpbnN0ZWFkIGlzIGNv bnNpZGVyZWQgYSBjb21wbGV0ZWQgdHJhbnNhY3Rpb24gb24gdGhlIFNDTUkgYTJwCj4gPiBjaGFu bmVsOgo+ID4gaS5lLiBDTURfc2VudCArIFJFUExZX3JldHJpZXZlZC4KPiA+Cj4gPiBBdCB0aGUg ZW5kLCBhbnl3YXksIHdvdWxkIGl0IGJlIHdvcnRoIGluIGFueSB3YXkgdG8gbGV2ZXJhZ2Ugc3Vj aAo+ID4gVHhBY2sKPiA+IGNhcGFiaWxpdGllcyAoc29tZWhvdykgb2YgYSBtYWlsYm94IGluIHRo ZSBTQ01JIHdvcmxkID8KPiA+Cj4gPiBJIG1lYW4sIGV2ZW4gaWYgd2UgbWFrZSB0aGlzIHdvcmss IHdoYXQgaXMgc3VwcG9zZWQgdG8gaGFwcGVuIGJldHRlcgo+ID4gYW5kIGZhc3Rlcgo+ID4gd2hl biB1c2luZyBhIFR4QWNrIGluc3RlYWQgb2YgYSBUWF9wb2xsaW5nIG1vZGUgbGlrZSBpdCBpcyBu b3cgPwo+ID4KPiA+IC4uLmJlY2F1c2UgdGhlIFNDTUkgc3RhY2sgY2Fubm90IHJlYWxseSBkbyBh bnl0aGluZyB3aXRoIHRoaXMKPiA+IGluZm9ybWF0aW9uIGluCj4gPiB0aGlzIGNhc2UsIGdpdmVu IHRoYXQgdGhlcmUgaXMganVzdCBvbmUgc2luZ2xlIGEycF9zaGVtIGFyZWEgZm9yCj4gPiBzZW5k aW5nIGNvbW1hbmQKPiA+IGFuZCByZWNlaXZpbmcgcmVwbGllcy4uLml0IGhhcyBqdXN0IHRvIHdh aXQgYW55d2F5IGV2ZW4gYWZ0ZXIgdGhlCj4gPiBUeEFjay4uLgo+ID4KPiA+IC4ubWF5YmUgaXQg aXMgYSBiaXQgbW9yZSBwb3dlci1mYXZvdXJhYmxlIHRvIHNsZWVwX3dhaXQgZm9yIHRoZSBUeEFj awo+ID4gSVJRCj4gPiBpbnN0ZWFkIG9mIHBvbGxpbmcgdGhlIE1IVSByZWdzID8uLi4gb3RoZXIg dGhhbiB0aGlzIHRoZSBUeEFjayBtZWFucwo+ID4gbm90aGluZwo+ID4gcmVhbGx5IGluIHRoZSBj b250ZXh0IG9mIHRoZSBTQ01JIHdvcmxkLCBzaW5jZSB5b3UgY2Fubm90IHNhZmVseQo+ID4gcXVl dWUgYW55dGhpbmcKPiA+IG1vcmUgdGlsbCB0aGUgcHJldmlvdXMgZXhjaGFuZ2UgaGFzIGZ1bGx5 IGNvbXBsZXRlZC4uLgo+ID4KPiA+IC4uLmluIG90aGVyIG5vbi1TQ01JIHNjZW5hcmlvcyB0aGF0 IEkgZXhwZXJpbWVudGVkIHdpdGgsIGl0IHJlYWxseQo+ID4gbWFrZXMgYQo+ID4gZGlmZmVyZW5j ZSBoYXZpZyB0aGUgVHhBY2sgc2luY2UgaXQgYXZvaWRzIGFsbCB0aGUgaW50ZXJuYWwKPiA+IHBv bGxpbmcvcmVxdWV1ZWluZwo+ID4gZGFuY2UgaW4gdGhlIG1haWxib3ggc3Vic3lzdGVtLCBidXQg aW4gdGhpcyBjYXNlIEkgdGhpbmsgaXMgYWxsIG1hZGUKPiA+IHVzZWxlc3MgYnkKPiA+IHRoZSB3 YXkgU0NNSS9TTVQgYmFzZWQgdHJhbnNwb3J0IHdvcmtzLi4uaS5lLiB1c2luZyBhIHNpbmdsZSBz aG1lbQo+ID4gYXJlYSBmb3IKPiA+IHRoZSBhMnAgY2hhbm5lbC4uCj4gPgo+ID4gLi4ubm90IHJl YWxseSBhIHNob3J0IGFuZCBzd2VldCBlbWFpbC4uLiA6UCAuLi4gYW55IGZlZWRiYWNrIG9yCj4g PiBmdXJ0aGVyCj4gPiBpZGVhcyBhcmUgd2VsY29tZSBhbnl3YXkuLi5lc3BlY2lhbGx5IGlmIHlv dSBjYW4gcHJvdmUgdGhhdCBhbGwgb2YKPiA+IHRoZQo+ID4gYWJvdmUgaXMgc29tZWhvdyB3cm9u Zywgb3IgdGhhdCB0aGVyZSBpcyBhIGdvb2QgcmVhc29uIHRvIGxldmVyYWdlCj4gPiB0aGUKPiA+ IFR4QWNrIGNhcGFibGUgbWFpbGJveGVzICA6RAo+ID4KPiA+IFRoYW5rcywKPiA+IENyaXN0aWFu Cj4gCj4gCj4gKioqKioqKioqKioqKiBNRURJQVRFSyBDb25maWRlbnRpYWxpdHkgTm90aWNlICoq KioqKioqKioqKioqKioqKioqCj4gVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUt bWFpbCBtZXNzYWdlIChpbmNsdWRpbmcgYW55Cj4gYXR0YWNobWVudHMpIG1heSBiZSBjb25maWRl bnRpYWwsIHByb3ByaWV0YXJ5LCBwcml2aWxlZ2VkLCBvciBvdGhlcndpc2UKPiBleGVtcHQgZnJv bSBkaXNjbG9zdXJlIHVuZGVyIGFwcGxpY2FibGUgbGF3cy4gSXQgaXMgaW50ZW5kZWQgdG8gYmUK PiBjb252ZXllZCBvbmx5IHRvIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudChzKS4gQW55IHVzZSwg ZGlzc2VtaW5hdGlvbiwKPiBkaXN0cmlidXRpb24sIHByaW50aW5nLCByZXRhaW5pbmcgb3IgY29w eWluZyBvZiB0aGlzIGUtbWFpbCAoaW5jbHVkaW5nIGl0cwo+IGF0dGFjaG1lbnRzKSBieSB1bmlu dGVuZGVkIHJlY2lwaWVudChzKSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkKPiBiZSB1 bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgZS1t YWlsLCBvciBiZWxpZXZlCj4gdGhhdCB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGUtbWFpbCBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyCj4gaW1tZWRpYXRlbHkgKGJ5IHJlcGx5aW5n IHRvIHRoaXMgZS1tYWlsKSwgZGVsZXRlIGFueSBhbmQgYWxsIGNvcGllcyBvZgo+IHRoaXMgZS1t YWlsIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBmcm9tIHlvdXIgc3lzdGVtLCBhbmQgZG8g bm90Cj4gZGlzY2xvc2UgdGhlIGNvbnRlbnQgb2YgdGhpcyBlLW1haWwgdG8gYW55IG90aGVyIHBl cnNvbi4gVGhhbmsgeW91IQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KbGludXgtYXJtLWtlcm5lbCBtYWlsaW5nIGxpc3QKbGludXgtYXJtLWtlcm5lbEBs aXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlz dGluZm8vbGludXgtYXJtLWtlcm5lbAo=