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=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham 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 9903EC64E75 for ; Mon, 24 Dec 2018 18:12:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6B2672229E for ; Mon, 24 Dec 2018 18:12:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725892AbeLXSMw (ORCPT ); Mon, 24 Dec 2018 13:12:52 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55240 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725747AbeLXSMv (ORCPT ); Mon, 24 Dec 2018 13:12:51 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2625C88E53; Mon, 24 Dec 2018 18:12:51 +0000 (UTC) Received: from redhat.com (ovpn-120-80.rdu2.redhat.com [10.10.120.80]) by smtp.corp.redhat.com (Postfix) with ESMTP id 65EC46092E; Mon, 24 Dec 2018 18:12:50 +0000 (UTC) Date: Mon, 24 Dec 2018 13:12:49 -0500 From: "Michael S. Tsirkin" To: Jason Wang Cc: kvm@vger.kernel.org, virtualization@lists.linux-foundation.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next 0/3] vhost: accelerate metadata access through vmap() Message-ID: <20181224131040-mutt-send-email-mst@kernel.org> References: <20181213101022.12475-1-jasowang@redhat.com> <20181213102315-mutt-send-email-mst@kernel.org> <9459e227-a943-8553-732b-d7f5225a0f22@redhat.com> <20181214072334-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Mon, 24 Dec 2018 18:12:51 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 24, 2018 at 04:32:39PM +0800, Jason Wang wrote: > > On 2018/12/14 下午8:33, Michael S. Tsirkin wrote: > > On Fri, Dec 14, 2018 at 11:42:18AM +0800, Jason Wang wrote: > > > On 2018/12/13 下午11:27, Michael S. Tsirkin wrote: > > > > On Thu, Dec 13, 2018 at 06:10:19PM +0800, Jason Wang wrote: > > > > > Hi: > > > > > > > > > > This series tries to access virtqueue metadata through kernel virtual > > > > > address instead of copy_user() friends since they had too much > > > > > overheads like checks, spec barriers or even hardware feature > > > > > toggling. > > > > Userspace accesses through remapping tricks and next time there's a need > > > > for a new barrier we are left to figure it out by ourselves. > > > > > > I don't get here, do you mean spec barriers? > > I mean the next barrier people decide to put into userspace > > memory accesses. > > > > > It's completely unnecessary for > > > vhost which is kernel thread. > > It's defence in depth. Take a look at the commit that added them. > > And yes quite possibly in most cases we actually have a spec > > barrier in the validation phase. If we do let's use the > > unsafe variants so they can be found. > > > unsafe variants can only work if you can batch userspace access. This is not > necessarily the case for light load. Do we care a lot about the light load? How would you benchmark it? > > > > > > And even if you're right, vhost is not the > > > only place, there's lots of vmap() based accessing in kernel. > > For sure. But if one can get by without get user pages, one > > really should. Witness recently uncovered mess with file > > backed storage. > > > We only pin metadata pages, I don't believe they will be used by any DMA. It doesn't matter really, if you dirty pages behind the MM back the problem is there. > > > > > > Think in > > > another direction, this means we won't suffer form unnecessary barriers for > > > kthread like vhost in the future, we will manually pick the one we really > > > need > > I personally think we should err on the side of caution not on the side of > > performance. > > > So what you suggest may lead unnecessary performance regression (10%-20%) > which is part of the goal of this series. We should audit and only use the > one we really need instead of depending on copy_user() friends(). > > If we do it our own, it could be slow for for security fix but it's no less > safe than before with performance kept. > > > > > > > (but it should have little possibility). > > History seems to teach otherwise. > > > What case did you mean here? > > > > > > > Please notice we only access metdata through remapping not the data itself. > > > This idea has been used for high speed userspace backend for years, e.g > > > packet socket or recent AF_XDP. > > I think their justification for the higher risk is that they are mostly > > designed for priveledged userspace. > > > I think it's the same with TUN/TAP, privileged process can pass them to > unprivileged ones. > > > > > > > The only difference is the page was remap to > > > from kernel to userspace. > > At least that avoids the g.u.p mess. > > > I'm still not very clear at the point. We only pin 2 or 4 pages, they're > several other cases that will pin much more. > > > > > > > > I don't > > > > like the idea I have to say. As a first step, why don't we switch to > > > > unsafe_put_user/unsafe_get_user etc? > > > > > > Several reasons: > > > > > > - They only have x86 variant, it won't have any difference for the rest of > > > architecture. > > Is there an issue on other architectures? If yes they can be extended > > there. > > > Consider the unexpected amount of work and in the best case it can give the > same performance to vmap(). I'm not sure it's worth. > > > > > > > - unsafe_put_user/unsafe_get_user is not sufficient for accessing structures > > > (e.g accessing descriptor) or arrays (batching). > > So you want unsafe_copy_xxx_user? I can do this. Hang on will post. > > > > > - Unless we can batch at least the accessing of two places in three of > > > avail, used and descriptor in one run. There will be no difference. E.g we > > > can batch updating used ring, but it won't make any difference in this case. > > > > > So let's batch them all? > > > Batching might not help for the case of light load. And we need to measure > the gain/cost of batching itself. > > > > > > > > > > That would be more of an apples to apples comparison, would it not? > > > > > > Apples to apples comparison only help if we are the No.1. But the fact is we > > > are not. If we want to compete with e.g dpdk or AF_XDP, vmap() is the > > > fastest method AFAIK. > > > > > > > > > Thanks > > We need to speed up the packet access itself too though. > > You can't vmap all of guest memory. > > > This series only pin and vmap very few pages (metadata). > > Thanks > > > > > > > > > > > > > > > Test shows about 24% improvement on TX PPS. It should benefit other > > > > > cases as well. > > > > > > > > > > Please review > > > > > > > > > > Jason Wang (3): > > > > > vhost: generalize adding used elem > > > > > vhost: fine grain userspace memory accessors > > > > > vhost: access vq metadata through kernel virtual address > > > > > > > > > > drivers/vhost/vhost.c | 281 ++++++++++++++++++++++++++++++++++++++---- > > > > > drivers/vhost/vhost.h | 11 ++ > > > > > 2 files changed, 266 insertions(+), 26 deletions(-) > > > > > > > > > > -- > > > > > 2.17.1 From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCH net-next 0/3] vhost: accelerate metadata access through vmap() Date: Mon, 24 Dec 2018 13:12:49 -0500 Message-ID: <20181224131040-mutt-send-email-mst@kernel.org> References: <20181213101022.12475-1-jasowang@redhat.com> <20181213102315-mutt-send-email-mst@kernel.org> <9459e227-a943-8553-732b-d7f5225a0f22@redhat.com> <20181214072334-mutt-send-email-mst@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org To: Jason Wang Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org List-Id: netdev.vger.kernel.org T24gTW9uLCBEZWMgMjQsIDIwMTggYXQgMDQ6MzI6MzlQTSArMDgwMCwgSmFzb24gV2FuZyB3cm90 ZToKPiAKPiBPbiAyMDE4LzEyLzE0IOS4i+WNiDg6MzMsIE1pY2hhZWwgUy4gVHNpcmtpbiB3cm90 ZToKPiA+IE9uIEZyaSwgRGVjIDE0LCAyMDE4IGF0IDExOjQyOjE4QU0gKzA4MDAsIEphc29uIFdh bmcgd3JvdGU6Cj4gPiA+IE9uIDIwMTgvMTIvMTMg5LiL5Y2IMTE6MjcsIE1pY2hhZWwgUy4gVHNp cmtpbiB3cm90ZToKPiA+ID4gPiBPbiBUaHUsIERlYyAxMywgMjAxOCBhdCAwNjoxMDoxOVBNICsw ODAwLCBKYXNvbiBXYW5nIHdyb3RlOgo+ID4gPiA+ID4gSGk6Cj4gPiA+ID4gPiAKPiA+ID4gPiA+ IFRoaXMgc2VyaWVzIHRyaWVzIHRvIGFjY2VzcyB2aXJ0cXVldWUgbWV0YWRhdGEgdGhyb3VnaCBr ZXJuZWwgdmlydHVhbAo+ID4gPiA+ID4gYWRkcmVzcyBpbnN0ZWFkIG9mIGNvcHlfdXNlcigpIGZy aWVuZHMgc2luY2UgdGhleSBoYWQgdG9vIG11Y2gKPiA+ID4gPiA+IG92ZXJoZWFkcyBsaWtlIGNo ZWNrcywgc3BlYyBiYXJyaWVycyBvciBldmVuIGhhcmR3YXJlIGZlYXR1cmUKPiA+ID4gPiA+IHRv Z2dsaW5nLgo+ID4gPiA+IFVzZXJzcGFjZSBhY2Nlc3NlcyB0aHJvdWdoIHJlbWFwcGluZyB0cmlj a3MgYW5kIG5leHQgdGltZSB0aGVyZSdzIGEgbmVlZAo+ID4gPiA+IGZvciBhIG5ldyBiYXJyaWVy IHdlIGFyZSBsZWZ0IHRvIGZpZ3VyZSBpdCBvdXQgYnkgb3Vyc2VsdmVzLgo+ID4gPiAKPiA+ID4g SSBkb24ndCBnZXQgaGVyZSwgZG8geW91IG1lYW4gc3BlYyBiYXJyaWVycz8KPiA+IEkgbWVhbiB0 aGUgbmV4dCBiYXJyaWVyIHBlb3BsZSBkZWNpZGUgdG8gcHV0IGludG8gdXNlcnNwYWNlCj4gPiBt ZW1vcnkgYWNjZXNzZXMuCj4gPiAKPiA+ID4gSXQncyBjb21wbGV0ZWx5IHVubmVjZXNzYXJ5IGZv cgo+ID4gPiB2aG9zdCB3aGljaCBpcyBrZXJuZWwgdGhyZWFkLgo+ID4gSXQncyBkZWZlbmNlIGlu IGRlcHRoLiBUYWtlIGEgbG9vayBhdCB0aGUgY29tbWl0IHRoYXQgYWRkZWQgdGhlbS4KPiA+IEFu ZCB5ZXMgcXVpdGUgcG9zc2libHkgaW4gbW9zdCBjYXNlcyB3ZSBhY3R1YWxseSBoYXZlIGEgc3Bl Ywo+ID4gYmFycmllciBpbiB0aGUgdmFsaWRhdGlvbiBwaGFzZS4gSWYgd2UgZG8gbGV0J3MgdXNl IHRoZQo+ID4gdW5zYWZlIHZhcmlhbnRzIHNvIHRoZXkgY2FuIGJlIGZvdW5kLgo+IAo+IAo+IHVu c2FmZSB2YXJpYW50cyBjYW4gb25seSB3b3JrIGlmIHlvdSBjYW4gYmF0Y2ggdXNlcnNwYWNlIGFj Y2Vzcy4gVGhpcyBpcyBub3QKPiBuZWNlc3NhcmlseSB0aGUgY2FzZSBmb3IgbGlnaHQgbG9hZC4K CgpEbyB3ZSBjYXJlIGEgbG90IGFib3V0IHRoZSBsaWdodCBsb2FkPyBIb3cgd291bGQgeW91IGJl bmNobWFyayBpdD8KCgo+IAo+ID4gCj4gPiA+IEFuZCBldmVuIGlmIHlvdSdyZSByaWdodCwgdmhv c3QgaXMgbm90IHRoZQo+ID4gPiBvbmx5IHBsYWNlLCB0aGVyZSdzIGxvdHMgb2Ygdm1hcCgpIGJh c2VkIGFjY2Vzc2luZyBpbiBrZXJuZWwuCj4gPiBGb3Igc3VyZS4gQnV0IGlmIG9uZSBjYW4gZ2V0 IGJ5IHdpdGhvdXQgZ2V0IHVzZXIgcGFnZXMsIG9uZQo+ID4gcmVhbGx5IHNob3VsZC4gV2l0bmVz cyByZWNlbnRseSB1bmNvdmVyZWQgbWVzcyB3aXRoIGZpbGUKPiA+IGJhY2tlZCBzdG9yYWdlLgo+ IAo+IAo+IFdlIG9ubHkgcGluIG1ldGFkYXRhIHBhZ2VzLCBJIGRvbid0IGJlbGlldmUgdGhleSB3 aWxsIGJlIHVzZWQgYnkgYW55IERNQS4KCkl0IGRvZXNuJ3QgbWF0dGVyIHJlYWxseSwgaWYgeW91 IGRpcnR5IHBhZ2VzIGJlaGluZCB0aGUgTU0gYmFjawp0aGUgcHJvYmxlbSBpcyB0aGVyZS4KCj4g Cj4gPiAKPiA+ID4gVGhpbmsgaW4KPiA+ID4gYW5vdGhlciBkaXJlY3Rpb24sIHRoaXMgbWVhbnMg d2Ugd29uJ3Qgc3VmZmVyIGZvcm0gdW5uZWNlc3NhcnkgYmFycmllcnMgZm9yCj4gPiA+IGt0aHJl YWQgbGlrZSB2aG9zdCBpbiB0aGUgZnV0dXJlLCB3ZSB3aWxsIG1hbnVhbGx5IHBpY2sgdGhlIG9u ZSB3ZSByZWFsbHkKPiA+ID4gbmVlZAo+ID4gSSBwZXJzb25hbGx5IHRoaW5rIHdlIHNob3VsZCBl cnIgb24gdGhlIHNpZGUgb2YgY2F1dGlvbiBub3Qgb24gdGhlIHNpZGUgb2YKPiA+IHBlcmZvcm1h bmNlLgo+IAo+IAo+IFNvIHdoYXQgeW91IHN1Z2dlc3QgbWF5IGxlYWQgdW5uZWNlc3NhcnkgcGVy Zm9ybWFuY2UgcmVncmVzc2lvbiAoMTAlLTIwJSkKPiB3aGljaCBpcyBwYXJ0IG9mIHRoZSBnb2Fs IG9mIHRoaXMgc2VyaWVzLiBXZSBzaG91bGQgYXVkaXQgYW5kIG9ubHkgdXNlIHRoZQo+IG9uZSB3 ZSByZWFsbHkgbmVlZCBpbnN0ZWFkIG9mIGRlcGVuZGluZyBvbiBjb3B5X3VzZXIoKSBmcmllbmRz KCkuCj4gCj4gSWYgd2UgZG8gaXQgb3VyIG93biwgaXQgY291bGQgYmUgc2xvdyBmb3IgZm9yIHNl Y3VyaXR5IGZpeCBidXQgaXQncyBubyBsZXNzCj4gc2FmZSB0aGFuIGJlZm9yZSB3aXRoIHBlcmZv cm1hbmNlIGtlcHQuCj4gCj4gCj4gPiAKPiA+ID4gKGJ1dCBpdCBzaG91bGQgaGF2ZSBsaXR0bGUg cG9zc2liaWxpdHkpLgo+ID4gSGlzdG9yeSBzZWVtcyB0byB0ZWFjaCBvdGhlcndpc2UuCj4gCj4g Cj4gV2hhdCBjYXNlIGRpZCB5b3UgbWVhbiBoZXJlPwo+IAo+IAo+ID4gCj4gPiA+IFBsZWFzZSBu b3RpY2Ugd2Ugb25seSBhY2Nlc3MgbWV0ZGF0YSB0aHJvdWdoIHJlbWFwcGluZyBub3QgdGhlIGRh dGEgaXRzZWxmLgo+ID4gPiBUaGlzIGlkZWEgaGFzIGJlZW4gdXNlZCBmb3IgaGlnaCBzcGVlZCB1 c2Vyc3BhY2UgYmFja2VuZCBmb3IgeWVhcnMsIGUuZwo+ID4gPiBwYWNrZXQgc29ja2V0IG9yIHJl Y2VudCBBRl9YRFAuCj4gPiBJIHRoaW5rIHRoZWlyIGp1c3RpZmljYXRpb24gZm9yIHRoZSBoaWdo ZXIgcmlzayBpcyB0aGF0IHRoZXkgYXJlIG1vc3RseQo+ID4gZGVzaWduZWQgZm9yIHByaXZlbGVk Z2VkIHVzZXJzcGFjZS4KPiAKPiAKPiBJIHRoaW5rIGl0J3MgdGhlIHNhbWUgd2l0aCBUVU4vVEFQ LCBwcml2aWxlZ2VkIHByb2Nlc3MgY2FuIHBhc3MgdGhlbSB0bwo+IHVucHJpdmlsZWdlZCBvbmVz Lgo+IAo+IAo+ID4gCj4gPiA+IFRoZSBvbmx5IGRpZmZlcmVuY2UgaXMgdGhlIHBhZ2Ugd2FzIHJl bWFwIHRvCj4gPiA+IGZyb20ga2VybmVsIHRvIHVzZXJzcGFjZS4KPiA+IEF0IGxlYXN0IHRoYXQg YXZvaWRzIHRoZSBnLnUucCBtZXNzLgo+IAo+IAo+IEknbSBzdGlsbCBub3QgdmVyeSBjbGVhciBh dCB0aGUgcG9pbnQuIFdlIG9ubHkgcGluIDIgb3IgNCBwYWdlcywgdGhleSdyZQo+IHNldmVyYWwg b3RoZXIgY2FzZXMgdGhhdCB3aWxsIHBpbiBtdWNoIG1vcmUuCj4gCj4gCj4gPiAKPiA+ID4gPiAg ICAgSSBkb24ndAo+ID4gPiA+IGxpa2UgdGhlIGlkZWEgSSBoYXZlIHRvIHNheS4gIEFzIGEgZmly c3Qgc3RlcCwgd2h5IGRvbid0IHdlIHN3aXRjaCB0bwo+ID4gPiA+IHVuc2FmZV9wdXRfdXNlci91 bnNhZmVfZ2V0X3VzZXIgZXRjPwo+ID4gPiAKPiA+ID4gU2V2ZXJhbCByZWFzb25zOgo+ID4gPiAK PiA+ID4gLSBUaGV5IG9ubHkgaGF2ZSB4ODYgdmFyaWFudCwgaXQgd29uJ3QgaGF2ZSBhbnkgZGlm ZmVyZW5jZSBmb3IgdGhlIHJlc3Qgb2YKPiA+ID4gYXJjaGl0ZWN0dXJlLgo+ID4gSXMgdGhlcmUg YW4gaXNzdWUgb24gb3RoZXIgYXJjaGl0ZWN0dXJlcz8gSWYgeWVzIHRoZXkgY2FuIGJlIGV4dGVu ZGVkCj4gPiB0aGVyZS4KPiAKPiAKPiBDb25zaWRlciB0aGUgdW5leHBlY3RlZCBhbW91bnQgb2Yg d29yayBhbmQgaW4gdGhlIGJlc3QgY2FzZSBpdCBjYW4gZ2l2ZSB0aGUKPiBzYW1lIHBlcmZvcm1h bmNlIHRvIHZtYXAoKS4gSSdtIG5vdCBzdXJlIGl0J3Mgd29ydGguCj4gCj4gCj4gPiAKPiA+ID4g LSB1bnNhZmVfcHV0X3VzZXIvdW5zYWZlX2dldF91c2VyIGlzIG5vdCBzdWZmaWNpZW50IGZvciBh Y2Nlc3Npbmcgc3RydWN0dXJlcwo+ID4gPiAoZS5nIGFjY2Vzc2luZyBkZXNjcmlwdG9yKSBvciBh cnJheXMgKGJhdGNoaW5nKS4KPiA+IFNvIHlvdSB3YW50IHVuc2FmZV9jb3B5X3h4eF91c2VyPyBJ IGNhbiBkbyB0aGlzLiBIYW5nIG9uIHdpbGwgcG9zdC4KPiA+IAo+ID4gPiAtIFVubGVzcyB3ZSBj YW4gYmF0Y2ggYXQgbGVhc3QgdGhlIGFjY2Vzc2luZyBvZiB0d28gcGxhY2VzIGluIHRocmVlIG9m Cj4gPiA+IGF2YWlsLCB1c2VkIGFuZCBkZXNjcmlwdG9yIGluIG9uZSBydW4uIFRoZXJlIHdpbGwg YmUgbm8gZGlmZmVyZW5jZS4gRS5nIHdlCj4gPiA+IGNhbiBiYXRjaCB1cGRhdGluZyB1c2VkIHJp bmcsIGJ1dCBpdCB3b24ndCBtYWtlIGFueSBkaWZmZXJlbmNlIGluIHRoaXMgY2FzZS4KPiA+ID4g Cj4gPiBTbyBsZXQncyBiYXRjaCB0aGVtIGFsbD8KPiAKPiAKPiBCYXRjaGluZyBtaWdodCBub3Qg aGVscCBmb3IgdGhlIGNhc2Ugb2YgbGlnaHQgbG9hZC4gQW5kIHdlIG5lZWQgdG8gbWVhc3VyZQo+ IHRoZSBnYWluL2Nvc3Qgb2YgYmF0Y2hpbmcgaXRzZWxmLgo+IAo+IAo+ID4gCj4gPiAKPiA+ID4g PiBUaGF0IHdvdWxkIGJlIG1vcmUgb2YgYW4gYXBwbGVzIHRvIGFwcGxlcyBjb21wYXJpc29uLCB3 b3VsZCBpdCBub3Q/Cj4gPiA+IAo+ID4gPiBBcHBsZXMgdG8gYXBwbGVzIGNvbXBhcmlzb24gb25s eSBoZWxwIGlmIHdlIGFyZSB0aGUgTm8uMS4gQnV0IHRoZSBmYWN0IGlzIHdlCj4gPiA+IGFyZSBu b3QuIElmIHdlIHdhbnQgdG8gY29tcGV0ZSB3aXRoIGUuZyBkcGRrIG9yIEFGX1hEUCwgdm1hcCgp IGlzIHRoZQo+ID4gPiBmYXN0ZXN0IG1ldGhvZCBBRkFJSy4KPiA+ID4gCj4gPiA+IAo+ID4gPiBU aGFua3MKPiA+IFdlIG5lZWQgdG8gc3BlZWQgdXAgdGhlIHBhY2tldCBhY2Nlc3MgaXRzZWxmIHRv byB0aG91Z2guCj4gPiBZb3UgY2FuJ3Qgdm1hcCBhbGwgb2YgZ3Vlc3QgbWVtb3J5Lgo+IAo+IAo+ IFRoaXMgc2VyaWVzIG9ubHkgcGluIGFuZCB2bWFwIHZlcnkgZmV3IHBhZ2VzIChtZXRhZGF0YSku Cj4gCj4gVGhhbmtzCj4gCj4gCj4gPiAKPiA+IAo+ID4gPiA+IAo+ID4gPiA+ID4gVGVzdCBzaG93 cyBhYm91dCAyNCUgaW1wcm92ZW1lbnQgb24gVFggUFBTLiBJdCBzaG91bGQgYmVuZWZpdCBvdGhl cgo+ID4gPiA+ID4gY2FzZXMgYXMgd2VsbC4KPiA+ID4gPiA+IAo+ID4gPiA+ID4gUGxlYXNlIHJl dmlldwo+ID4gPiA+ID4gCj4gPiA+ID4gPiBKYXNvbiBXYW5nICgzKToKPiA+ID4gPiA+ICAgICB2 aG9zdDogZ2VuZXJhbGl6ZSBhZGRpbmcgdXNlZCBlbGVtCj4gPiA+ID4gPiAgICAgdmhvc3Q6IGZp bmUgZ3JhaW4gdXNlcnNwYWNlIG1lbW9yeSBhY2Nlc3NvcnMKPiA+ID4gPiA+ICAgICB2aG9zdDog YWNjZXNzIHZxIG1ldGFkYXRhIHRocm91Z2gga2VybmVsIHZpcnR1YWwgYWRkcmVzcwo+ID4gPiA+ ID4gCj4gPiA+ID4gPiAgICBkcml2ZXJzL3Zob3N0L3Zob3N0LmMgfCAyODEgKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKystLS0tCj4gPiA+ID4gPiAgICBkcml2ZXJzL3Zob3N0 L3Zob3N0LmggfCAgMTEgKysKPiA+ID4gPiA+ICAgIDIgZmlsZXMgY2hhbmdlZCwgMjY2IGluc2Vy dGlvbnMoKyksIDI2IGRlbGV0aW9ucygtKQo+ID4gPiA+ID4gCj4gPiA+ID4gPiAtLSAKPiA+ID4g PiA+IDIuMTcuMQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XwpWaXJ0dWFsaXphdGlvbiBtYWlsaW5nIGxpc3QKVmlydHVhbGl6YXRpb25AbGlzdHMubGludXgt Zm91bmRhdGlvbi5vcmcKaHR0cHM6Ly9saXN0cy5saW51eGZvdW5kYXRpb24ub3JnL21haWxtYW4v bGlzdGluZm8vdmlydHVhbGl6YXRpb24=