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.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 DE135C10F13 for ; Tue, 9 Apr 2019 00:35:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9B28F21874 for ; Tue, 9 Apr 2019 00:35:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1554770122; bh=/Vy//+so3VDSR4WKdBq0CaM88Ncn2coDH8E/MuBqYQw=; h=Date:From:To:cc:Subject:In-Reply-To:References:List-ID:From; b=NsHgK+lq13KX2GfxACHe9ZypAf6ouYYTCpi4aOoFVRAkUJZycOgC5ELwWuzOcee+n M/gJ58BWw2H2QTeMGHpWjI1jfOAGgxeZDGJTzHqAQqhG1QPGmRaQ+3YTwbUiweo9Vr WfURF3na9gWipLkjKn19TJEKcpMlFnOJgXzUJ/40= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726582AbfDIAfV (ORCPT ); Mon, 8 Apr 2019 20:35:21 -0400 Received: from mail.kernel.org ([198.145.29.99]:49960 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726349AbfDIAfV (ORCPT ); Mon, 8 Apr 2019 20:35:21 -0400 Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 03A33213F2; Tue, 9 Apr 2019 00:35:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1554770119; bh=/Vy//+so3VDSR4WKdBq0CaM88Ncn2coDH8E/MuBqYQw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=uP41OXEPQR25KmXi4eNSpLbcAs5p7YhVlp37WhvOZ89tnesIT9IMTzz5NWiOUzoFd TV1qJhugj5QTeoU5S/KjLRI4MgUWK74FjmB3lRG3a4jfTWiLCfU19EbuZE5W0D5fQW gG1UusFYnnoeWk7gvHzAQVBOms+zZCnPcGb1TbAI= Date: Mon, 8 Apr 2019 17:35:11 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-X260 To: Joao Martins cc: Juergen Gross , Paolo Bonzini , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Ankur Arora , Boris Ostrovsky , =?UTF-8?Q?Radim_Kr=C4=8Dm=C3=A1=C5=99?= , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , x86@kernel.org, Stefano Stabellini , xen-devel@lists.xenproject.org, Artem_Mygaiev@epam.com Subject: Re: [PATCH RFC 00/39] x86/KVM: Xen HVM guest support In-Reply-To: <97808492-58ee-337f-c894-900b34b7b1a5@oracle.com> Message-ID: References: <20190220201609.28290-1-joao.m.martins@oracle.com> <35051310-c497-8ad5-4434-1b8426a317d2@redhat.com> <8b1f4912-4f92-69ae-ae01-d899d5640572@oracle.com> <3ee91f33-2973-c2db-386f-afbf138081b4@redhat.com> <59676804-786d-3df8-7752-8e45dec6d65b@oracle.com> <94738323-ebdf-d58e-55b6-313e27c923b0@oracle.com> <585163c2-8dea-728d-7556-9cb3559f0eca@suse.com> <97808492-58ee-337f-c894-900b34b7b1a5@oracle.com> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 8 Apr 2019, Joao Martins wrote: > On 4/8/19 11:42 AM, Juergen Gross wrote: > > On 08/04/2019 12:36, Joao Martins wrote: > >> On 4/8/19 7:44 AM, Juergen Gross wrote: > >>> On 12/03/2019 18:14, Joao Martins wrote: > >>>> On 2/22/19 4:59 PM, Paolo Bonzini wrote: > >>>>> On 21/02/19 12:45, Joao Martins wrote: > >>>>>> On 2/20/19 9:09 PM, Paolo Bonzini wrote: > >>>>>>> On 20/02/19 21:15, Joao Martins wrote: > >>>>>>>> 2. PV Driver support (patches 17 - 39) > >>>>>>>> > >>>>>>>> We start by redirecting hypercalls from the backend to routines > >>>>>>>> which emulate the behaviour that PV backends expect i.e. grant > >>>>>>>> table and interdomain events. Next, we add support for late > >>>>>>>> initialization of xenbus, followed by implementing > >>>>>>>> frontend/backend communication mechanisms (i.e. grant tables and > >>>>>>>> interdomain event channels). Finally, introduce xen-shim.ko, > >>>>>>>> which will setup a limited Xen environment. This uses the added > >>>>>>>> functionality of Xen specific shared memory (grant tables) and > >>>>>>>> notifications (event channels). > >>>>>>> > >>>>>>> I am a bit worried by the last patches, they seem really brittle and > >>>>>>> prone to breakage. I don't know Xen well enough to understand if the > >>>>>>> lack of support for GNTMAP_host_map is fixable, but if not, you have to > >>>>>>> define a completely different hypercall. > >>>>>>> > >>>>>> I guess Ankur already answered this; so just to stack this on top of his comment. > >>>>>> > >>>>>> The xen_shim_domain() is only meant to handle the case where the backend > >>>>>> has/can-have full access to guest memory [i.e. netback and blkback would work > >>>>>> with similar assumptions as vhost?]. For the normal case, where a backend *in a > >>>>>> guest* maps and unmaps other guest memory, this is not applicable and these > >>>>>> changes don't affect that case. > >>>>>> > >>>>>> IOW, the PV backend here sits on the hypervisor, and the hypercalls aren't > >>>>>> actual hypercalls but rather invoking shim_hypercall(). The call chain would go > >>>>>> more or less like: > >>>>>> > >>>>>> > >>>>>> gnttab_map_refs(map_ops, pages) > >>>>>> HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,...) > >>>>>> shim_hypercall() > >>>>>> shim_hcall_gntmap() > >>>>>> > >>>>>> Our reasoning was that given we are already in KVM, why mapping a page if the > >>>>>> user (i.e. the kernel PV backend) is himself? The lack of GNTMAP_host_map is how > >>>>>> the shim determines its user doesn't want to map the page. Also, there's another > >>>>>> issue where PV backends always need a struct page to reference the device > >>>>>> inflight data as Ankur pointed out. > >>>>> > >>>>> Ultimately it's up to the Xen people. It does make their API uglier, > >>>>> especially the in/out change for the parameter. If you can at least > >>>>> avoid that, it would alleviate my concerns quite a bit. > >>>> > >>>> In my view, we have two options overall: > >>>> > >>>> 1) Make it explicit, the changes the PV drivers we have to make in > >>>> order to support xen_shim_domain(). This could mean e.g. a) add a callback > >>>> argument to gnttab_map_refs() that is invoked for every page that gets looked up > >>>> successfully, and inside this callback the PV driver may update it's tracking > >>>> page. Here we no longer have this in/out parameter in gnttab_map_refs, and all > >>>> shim_domain specific bits would be a little more abstracted from Xen PV > >>>> backends. See netback example below the scissors mark. Or b) have sort of a > >>>> translate_gref() and put_gref() API that Xen PV drivers use which make it even > >>>> more explicit that there's no grant ops involved. The latter is more invasive. > >>>> > >>>> 2) The second option is to support guest grant mapping/unmapping [*] to allow > >>>> hosting PV backends inside the guest. This would remove the Xen changes in this > >>>> series completely. But it would require another guest being used > >>>> as netback/blkback/xenstored, and less performance than 1) (though, in theory, > >>>> it would be equivalent to what does Xen with grants/events). The only changes in > >>>> Linux Xen code is adding xenstored domain support, but that is useful on its own > >>>> outside the scope of this work. > >>>> > >>>> I think there's value on both; 1) is probably more familiar for KVM users > >>>> perhaps (as it is similar to what vhost does?) while 2) equates to implementing > >>>> Xen disagregation capabilities in KVM. > >>>> > >>>> Thoughts? Xen maintainers what's your take on this? > >>> > >>> What I'd like best would be a new handle (e.g. xenhost_t *) used as an > >>> abstraction layer for this kind of stuff. It should be passed to the > >>> backends and those would pass it on to low-level Xen drivers (xenbus, > >>> event channels, grant table, ...). > >>> > >> So if IIRC backends would use the xenhost layer to access grants or frames > >> referenced by grants, and that would grok into some of this. IOW, you would have > >> two implementors of xenhost: one for nested remote/local events+grants and > >> another for this "shim domain" ? > > > > As I'd need that for nested Xen I guess that would make it 3 variants. > > Probably the xen-shim variant would need more hooks, but that should be > > no problem. > > > I probably messed up in the short description but "nested remote/local > events+grants" was referring to nested Xen (FWIW remote meant L0 and local L1). > So maybe only 2 variants are needed? > > >>> I was planning to do that (the xenhost_t * stuff) soon in order to add > >>> support for nested Xen using PV devices (you need two Xenstores for that > >>> as the nested dom0 is acting as Xen backend server, while using PV > >>> frontends for accessing the "real" world outside). > >>> > >>> The xenhost_t should be used for: > >>> > >>> - accessing Xenstore > >>> - issuing and receiving events > >>> - doing hypercalls > >>> - grant table operations > >>> > >> > >> In the text above, I sort of suggested a slice of this on 1.b) with a > >> translate_gref() and put_gref() API -- to get the page from a gref. This was > >> because of the flags|host_addr hurdle we depicted above wrt to using using grant > >> maps/unmaps. You think some of the xenhost layer would be ammenable to support > >> this case? > > > > I think so, yes. > > > >> > >>> So exactly the kind of stuff you want to do, too. > >>> > >> Cool idea! > > > > In the end you might make my life easier for nested Xen. :-) > > > Hehe :) > > > Do you want to have a try with that idea or should I do that? I might be > > able to start working on that in about a month. > > > Ankur (CC'ed) will give a shot at it, and should start a new thread on this > xenhost abstraction layer. If you are up for it, it would be great to write some documentation too. We are starting to have decent docs for some PV protocols, describing a specific PV interface, but we are lacking docs about the basic building blocks to bring up PV drivers in general. They would be extremely useful. Given that you have just done the work, you are in a great position to write those docs. Even bad English would be fine, I am sure somebody else could volunteer to clean-up the language. Anything would help :-) 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=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,SPF_HELO_NONE,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 BA136C10F13 for ; Tue, 9 Apr 2019 00:35:40 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (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 85EAE213F2 for ; Tue, 9 Apr 2019 00:35:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="uP41OXEP" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 85EAE213F2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1hDejT-0003LY-0z; Tue, 09 Apr 2019 00:35:23 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1hDejS-0003LT-05 for xen-devel@lists.xenproject.org; Tue, 09 Apr 2019 00:35:22 +0000 X-Inumbo-ID: 5a8e9be0-5a5f-11e9-89df-0fe93c4d4910 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 5a8e9be0-5a5f-11e9-89df-0fe93c4d4910; Tue, 09 Apr 2019 00:35:20 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 03A33213F2; Tue, 9 Apr 2019 00:35:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1554770119; bh=/Vy//+so3VDSR4WKdBq0CaM88Ncn2coDH8E/MuBqYQw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=uP41OXEPQR25KmXi4eNSpLbcAs5p7YhVlp37WhvOZ89tnesIT9IMTzz5NWiOUzoFd TV1qJhugj5QTeoU5S/KjLRI4MgUWK74FjmB3lRG3a4jfTWiLCfU19EbuZE5W0D5fQW gG1UusFYnnoeWk7gvHzAQVBOms+zZCnPcGb1TbAI= Date: Mon, 8 Apr 2019 17:35:11 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-X260 To: Joao Martins In-Reply-To: <97808492-58ee-337f-c894-900b34b7b1a5@oracle.com> Message-ID: References: <20190220201609.28290-1-joao.m.martins@oracle.com> <35051310-c497-8ad5-4434-1b8426a317d2@redhat.com> <8b1f4912-4f92-69ae-ae01-d899d5640572@oracle.com> <3ee91f33-2973-c2db-386f-afbf138081b4@redhat.com> <59676804-786d-3df8-7752-8e45dec6d65b@oracle.com> <94738323-ebdf-d58e-55b6-313e27c923b0@oracle.com> <585163c2-8dea-728d-7556-9cb3559f0eca@suse.com> <97808492-58ee-337f-c894-900b34b7b1a5@oracle.com> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Subject: Re: [Xen-devel] [PATCH RFC 00/39] x86/KVM: Xen HVM guest support X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Artem_Mygaiev@epam.com, Stefano Stabellini , xen-devel@lists.xenproject.org, kvm@vger.kernel.org, =?UTF-8?Q?Radim_Kr=C4=8Dm=C3=A1=C5=99?= , x86@kernel.org, linux-kernel@vger.kernel.org, Ankur Arora , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Paolo Bonzini , Boris Ostrovsky , Thomas Gleixner Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" T24gTW9uLCA4IEFwciAyMDE5LCBKb2FvIE1hcnRpbnMgd3JvdGU6Cj4gT24gNC84LzE5IDExOjQy IEFNLCBKdWVyZ2VuIEdyb3NzIHdyb3RlOgo+ID4gT24gMDgvMDQvMjAxOSAxMjozNiwgSm9hbyBN YXJ0aW5zIHdyb3RlOgo+ID4+IE9uIDQvOC8xOSA3OjQ0IEFNLCBKdWVyZ2VuIEdyb3NzIHdyb3Rl Ogo+ID4+PiBPbiAxMi8wMy8yMDE5IDE4OjE0LCBKb2FvIE1hcnRpbnMgd3JvdGU6Cj4gPj4+PiBP biAyLzIyLzE5IDQ6NTkgUE0sIFBhb2xvIEJvbnppbmkgd3JvdGU6Cj4gPj4+Pj4gT24gMjEvMDIv MTkgMTI6NDUsIEpvYW8gTWFydGlucyB3cm90ZToKPiA+Pj4+Pj4gT24gMi8yMC8xOSA5OjA5IFBN LCBQYW9sbyBCb256aW5pIHdyb3RlOgo+ID4+Pj4+Pj4gT24gMjAvMDIvMTkgMjE6MTUsIEpvYW8g TWFydGlucyB3cm90ZToKPiA+Pj4+Pj4+PiAgMi4gUFYgRHJpdmVyIHN1cHBvcnQgKHBhdGNoZXMg MTcgLSAzOSkKPiA+Pj4+Pj4+Pgo+ID4+Pj4+Pj4+ICBXZSBzdGFydCBieSByZWRpcmVjdGluZyBo eXBlcmNhbGxzIGZyb20gdGhlIGJhY2tlbmQgdG8gcm91dGluZXMKPiA+Pj4+Pj4+PiAgd2hpY2gg ZW11bGF0ZSB0aGUgYmVoYXZpb3VyIHRoYXQgUFYgYmFja2VuZHMgZXhwZWN0IGkuZS4gZ3JhbnQK PiA+Pj4+Pj4+PiAgdGFibGUgYW5kIGludGVyZG9tYWluIGV2ZW50cy4gTmV4dCwgd2UgYWRkIHN1 cHBvcnQgZm9yIGxhdGUKPiA+Pj4+Pj4+PiAgaW5pdGlhbGl6YXRpb24gb2YgeGVuYnVzLCBmb2xs b3dlZCBieSBpbXBsZW1lbnRpbmcKPiA+Pj4+Pj4+PiAgZnJvbnRlbmQvYmFja2VuZCBjb21tdW5p Y2F0aW9uIG1lY2hhbmlzbXMgKGkuZS4gZ3JhbnQgdGFibGVzIGFuZAo+ID4+Pj4+Pj4+ICBpbnRl cmRvbWFpbiBldmVudCBjaGFubmVscykuIEZpbmFsbHksIGludHJvZHVjZSB4ZW4tc2hpbS5rbywK PiA+Pj4+Pj4+PiAgd2hpY2ggd2lsbCBzZXR1cCBhIGxpbWl0ZWQgWGVuIGVudmlyb25tZW50LiBU aGlzIHVzZXMgdGhlIGFkZGVkCj4gPj4+Pj4+Pj4gIGZ1bmN0aW9uYWxpdHkgb2YgWGVuIHNwZWNp ZmljIHNoYXJlZCBtZW1vcnkgKGdyYW50IHRhYmxlcykgYW5kCj4gPj4+Pj4+Pj4gIG5vdGlmaWNh dGlvbnMgKGV2ZW50IGNoYW5uZWxzKS4KPiA+Pj4+Pj4+Cj4gPj4+Pj4+PiBJIGFtIGEgYml0IHdv cnJpZWQgYnkgdGhlIGxhc3QgcGF0Y2hlcywgdGhleSBzZWVtIHJlYWxseSBicml0dGxlIGFuZAo+ ID4+Pj4+Pj4gcHJvbmUgdG8gYnJlYWthZ2UuICBJIGRvbid0IGtub3cgWGVuIHdlbGwgZW5vdWdo IHRvIHVuZGVyc3RhbmQgaWYgdGhlCj4gPj4+Pj4+PiBsYWNrIG9mIHN1cHBvcnQgZm9yIEdOVE1B UF9ob3N0X21hcCBpcyBmaXhhYmxlLCBidXQgaWYgbm90LCB5b3UgaGF2ZSB0bwo+ID4+Pj4+Pj4g ZGVmaW5lIGEgY29tcGxldGVseSBkaWZmZXJlbnQgaHlwZXJjYWxsLgo+ID4+Pj4+Pj4KPiA+Pj4+ Pj4gSSBndWVzcyBBbmt1ciBhbHJlYWR5IGFuc3dlcmVkIHRoaXM7IHNvIGp1c3QgdG8gc3RhY2sg dGhpcyBvbiB0b3Agb2YgaGlzIGNvbW1lbnQuCj4gPj4+Pj4+Cj4gPj4+Pj4+IFRoZSB4ZW5fc2hp bV9kb21haW4oKSBpcyBvbmx5IG1lYW50IHRvIGhhbmRsZSB0aGUgY2FzZSB3aGVyZSB0aGUgYmFj a2VuZAo+ID4+Pj4+PiBoYXMvY2FuLWhhdmUgZnVsbCBhY2Nlc3MgdG8gZ3Vlc3QgbWVtb3J5IFtp LmUuIG5ldGJhY2sgYW5kIGJsa2JhY2sgd291bGQgd29yawo+ID4+Pj4+PiB3aXRoIHNpbWlsYXIg YXNzdW1wdGlvbnMgYXMgdmhvc3Q/XS4gRm9yIHRoZSBub3JtYWwgY2FzZSwgd2hlcmUgYSBiYWNr ZW5kICppbiBhCj4gPj4+Pj4+IGd1ZXN0KiBtYXBzIGFuZCB1bm1hcHMgb3RoZXIgZ3Vlc3QgbWVt b3J5LCB0aGlzIGlzIG5vdCBhcHBsaWNhYmxlIGFuZCB0aGVzZQo+ID4+Pj4+PiBjaGFuZ2VzIGRv bid0IGFmZmVjdCB0aGF0IGNhc2UuCj4gPj4+Pj4+Cj4gPj4+Pj4+IElPVywgdGhlIFBWIGJhY2tl bmQgaGVyZSBzaXRzIG9uIHRoZSBoeXBlcnZpc29yLCBhbmQgdGhlIGh5cGVyY2FsbHMgYXJlbid0 Cj4gPj4+Pj4+IGFjdHVhbCBoeXBlcmNhbGxzIGJ1dCByYXRoZXIgaW52b2tpbmcgc2hpbV9oeXBl cmNhbGwoKS4gVGhlIGNhbGwgY2hhaW4gd291bGQgZ28KPiA+Pj4+Pj4gbW9yZSBvciBsZXNzIGxp a2U6Cj4gPj4+Pj4+Cj4gPj4+Pj4+IDxuZXRiYWNrfGJsa2JhY2t8c2NzaWJhY2s+Cj4gPj4+Pj4+ ICBnbnR0YWJfbWFwX3JlZnMobWFwX29wcywgcGFnZXMpCj4gPj4+Pj4+ICAgIEhZUEVSVklTT1Jf Z3JhbnRfdGFibGVfb3AoR05UVEFCT1BfbWFwX2dyYW50X3JlZiwuLi4pCj4gPj4+Pj4+ICAgICAg c2hpbV9oeXBlcmNhbGwoKQo+ID4+Pj4+PiAgICAgICAgc2hpbV9oY2FsbF9nbnRtYXAoKQo+ID4+ Pj4+Pgo+ID4+Pj4+PiBPdXIgcmVhc29uaW5nIHdhcyB0aGF0IGdpdmVuIHdlIGFyZSBhbHJlYWR5 IGluIEtWTSwgd2h5IG1hcHBpbmcgYSBwYWdlIGlmIHRoZQo+ID4+Pj4+PiB1c2VyIChpLmUuIHRo ZSBrZXJuZWwgUFYgYmFja2VuZCkgaXMgaGltc2VsZj8gVGhlIGxhY2sgb2YgR05UTUFQX2hvc3Rf bWFwIGlzIGhvdwo+ID4+Pj4+PiB0aGUgc2hpbSBkZXRlcm1pbmVzIGl0cyB1c2VyIGRvZXNuJ3Qg d2FudCB0byBtYXAgdGhlIHBhZ2UuIEFsc28sIHRoZXJlJ3MgYW5vdGhlcgo+ID4+Pj4+PiBpc3N1 ZSB3aGVyZSBQViBiYWNrZW5kcyBhbHdheXMgbmVlZCBhIHN0cnVjdCBwYWdlIHRvIHJlZmVyZW5j ZSB0aGUgZGV2aWNlCj4gPj4+Pj4+IGluZmxpZ2h0IGRhdGEgYXMgQW5rdXIgcG9pbnRlZCBvdXQu Cj4gPj4+Pj4KPiA+Pj4+PiBVbHRpbWF0ZWx5IGl0J3MgdXAgdG8gdGhlIFhlbiBwZW9wbGUuICBJ dCBkb2VzIG1ha2UgdGhlaXIgQVBJIHVnbGllciwKPiA+Pj4+PiBlc3BlY2lhbGx5IHRoZSBpbi9v dXQgY2hhbmdlIGZvciB0aGUgcGFyYW1ldGVyLiAgSWYgeW91IGNhbiBhdCBsZWFzdAo+ID4+Pj4+ IGF2b2lkIHRoYXQsIGl0IHdvdWxkIGFsbGV2aWF0ZSBteSBjb25jZXJucyBxdWl0ZSBhIGJpdC4K PiA+Pj4+Cj4gPj4+PiBJbiBteSB2aWV3LCB3ZSBoYXZlIHR3byBvcHRpb25zIG92ZXJhbGw6Cj4g Pj4+Pgo+ID4+Pj4gMSkgTWFrZSBpdCBleHBsaWNpdCwgdGhlIGNoYW5nZXMgdGhlIFBWIGRyaXZl cnMgd2UgaGF2ZSB0byBtYWtlIGluCj4gPj4+PiBvcmRlciB0byBzdXBwb3J0IHhlbl9zaGltX2Rv bWFpbigpLiBUaGlzIGNvdWxkIG1lYW4gZS5nLiBhKSBhZGQgYSBjYWxsYmFjawo+ID4+Pj4gYXJn dW1lbnQgdG8gZ250dGFiX21hcF9yZWZzKCkgdGhhdCBpcyBpbnZva2VkIGZvciBldmVyeSBwYWdl IHRoYXQgZ2V0cyBsb29rZWQgdXAKPiA+Pj4+IHN1Y2Nlc3NmdWxseSwgYW5kIGluc2lkZSB0aGlz IGNhbGxiYWNrIHRoZSBQViBkcml2ZXIgbWF5IHVwZGF0ZSBpdCdzIHRyYWNraW5nCj4gPj4+PiBw YWdlLiBIZXJlIHdlIG5vIGxvbmdlciBoYXZlIHRoaXMgaW4vb3V0IHBhcmFtZXRlciBpbiBnbnR0 YWJfbWFwX3JlZnMsIGFuZCBhbGwKPiA+Pj4+IHNoaW1fZG9tYWluIHNwZWNpZmljIGJpdHMgd291 bGQgYmUgYSBsaXR0bGUgbW9yZSBhYnN0cmFjdGVkIGZyb20gWGVuIFBWCj4gPj4+PiBiYWNrZW5k cy4gU2VlIG5ldGJhY2sgZXhhbXBsZSBiZWxvdyB0aGUgc2Npc3NvcnMgbWFyay4gT3IgYikgaGF2 ZSBzb3J0IG9mIGEKPiA+Pj4+IHRyYW5zbGF0ZV9ncmVmKCkgYW5kIHB1dF9ncmVmKCkgQVBJIHRo YXQgWGVuIFBWIGRyaXZlcnMgdXNlIHdoaWNoIG1ha2UgaXQgZXZlbgo+ID4+Pj4gbW9yZSBleHBs aWNpdCB0aGF0IHRoZXJlJ3Mgbm8gZ3JhbnQgb3BzIGludm9sdmVkLiBUaGUgbGF0dGVyIGlzIG1v cmUgaW52YXNpdmUuCj4gPj4+Pgo+ID4+Pj4gMikgVGhlIHNlY29uZCBvcHRpb24gaXMgdG8gc3Vw cG9ydCBndWVzdCBncmFudCBtYXBwaW5nL3VubWFwcGluZyBbKl0gdG8gYWxsb3cKPiA+Pj4+IGhv c3RpbmcgUFYgYmFja2VuZHMgaW5zaWRlIHRoZSBndWVzdC4gVGhpcyB3b3VsZCByZW1vdmUgdGhl IFhlbiBjaGFuZ2VzIGluIHRoaXMKPiA+Pj4+IHNlcmllcyBjb21wbGV0ZWx5LiBCdXQgaXQgd291 bGQgcmVxdWlyZSBhbm90aGVyIGd1ZXN0IGJlaW5nIHVzZWQKPiA+Pj4+IGFzIG5ldGJhY2svYmxr YmFjay94ZW5zdG9yZWQsIGFuZCBsZXNzIHBlcmZvcm1hbmNlIHRoYW4gMSkgKHRob3VnaCwgaW4g dGhlb3J5LAo+ID4+Pj4gaXQgd291bGQgYmUgZXF1aXZhbGVudCB0byB3aGF0IGRvZXMgWGVuIHdp dGggZ3JhbnRzL2V2ZW50cykuIFRoZSBvbmx5IGNoYW5nZXMgaW4KPiA+Pj4+IExpbnV4IFhlbiBj b2RlIGlzIGFkZGluZyB4ZW5zdG9yZWQgZG9tYWluIHN1cHBvcnQsIGJ1dCB0aGF0IGlzIHVzZWZ1 bCBvbiBpdHMgb3duCj4gPj4+PiBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIHdvcmsuCj4gPj4+ Pgo+ID4+Pj4gSSB0aGluayB0aGVyZSdzIHZhbHVlIG9uIGJvdGg7IDEpIGlzIHByb2JhYmx5IG1v cmUgZmFtaWxpYXIgZm9yIEtWTSB1c2Vycwo+ID4+Pj4gcGVyaGFwcyAoYXMgaXQgaXMgc2ltaWxh ciB0byB3aGF0IHZob3N0IGRvZXM/KSB3aGlsZSAgMikgZXF1YXRlcyB0byBpbXBsZW1lbnRpbmcK PiA+Pj4+IFhlbiBkaXNhZ3JlZ2F0aW9uIGNhcGFiaWxpdGllcyBpbiBLVk0uCj4gPj4+Pgo+ID4+ Pj4gVGhvdWdodHM/IFhlbiBtYWludGFpbmVycyB3aGF0J3MgeW91ciB0YWtlIG9uIHRoaXM/Cj4g Pj4+Cj4gPj4+IFdoYXQgSSdkIGxpa2UgYmVzdCB3b3VsZCBiZSBhIG5ldyBoYW5kbGUgKGUuZy4g eGVuaG9zdF90ICopIHVzZWQgYXMgYW4KPiA+Pj4gYWJzdHJhY3Rpb24gbGF5ZXIgZm9yIHRoaXMg a2luZCBvZiBzdHVmZi4gSXQgc2hvdWxkIGJlIHBhc3NlZCB0byB0aGUKPiA+Pj4gYmFja2VuZHMg YW5kIHRob3NlIHdvdWxkIHBhc3MgaXQgb24gdG8gbG93LWxldmVsIFhlbiBkcml2ZXJzICh4ZW5i dXMsCj4gPj4+IGV2ZW50IGNoYW5uZWxzLCBncmFudCB0YWJsZSwgLi4uKS4KPiA+Pj4KPiA+PiBT byBpZiBJSVJDIGJhY2tlbmRzIHdvdWxkIHVzZSB0aGUgeGVuaG9zdCBsYXllciB0byBhY2Nlc3Mg Z3JhbnRzIG9yIGZyYW1lcwo+ID4+IHJlZmVyZW5jZWQgYnkgZ3JhbnRzLCBhbmQgdGhhdCB3b3Vs ZCBncm9rIGludG8gc29tZSBvZiB0aGlzLiBJT1csIHlvdSB3b3VsZCBoYXZlCj4gPj4gdHdvIGlt cGxlbWVudG9ycyBvZiB4ZW5ob3N0OiBvbmUgZm9yIG5lc3RlZCByZW1vdGUvbG9jYWwgZXZlbnRz K2dyYW50cyBhbmQKPiA+PiBhbm90aGVyIGZvciB0aGlzICJzaGltIGRvbWFpbiIgPwo+ID4gCj4g PiBBcyBJJ2QgbmVlZCB0aGF0IGZvciBuZXN0ZWQgWGVuIEkgZ3Vlc3MgdGhhdCB3b3VsZCBtYWtl IGl0IDMgdmFyaWFudHMuCj4gPiBQcm9iYWJseSB0aGUgeGVuLXNoaW0gdmFyaWFudCB3b3VsZCBu ZWVkIG1vcmUgaG9va3MsIGJ1dCB0aGF0IHNob3VsZCBiZQo+ID4gbm8gcHJvYmxlbS4KPiA+IAo+ IEkgcHJvYmFibHkgbWVzc2VkIHVwIGluIHRoZSBzaG9ydCBkZXNjcmlwdGlvbiBidXQgIm5lc3Rl ZCByZW1vdGUvbG9jYWwKPiBldmVudHMrZ3JhbnRzIiB3YXMgcmVmZXJyaW5nIHRvIG5lc3RlZCBY ZW4gKEZXSVcgcmVtb3RlIG1lYW50IEwwIGFuZCBsb2NhbCBMMSkuCj4gU28gbWF5YmUgb25seSAy IHZhcmlhbnRzIGFyZSBuZWVkZWQ/Cj4gCj4gPj4+IEkgd2FzIHBsYW5uaW5nIHRvIGRvIHRoYXQg KHRoZSB4ZW5ob3N0X3QgKiBzdHVmZikgc29vbiBpbiBvcmRlciB0byBhZGQKPiA+Pj4gc3VwcG9y dCBmb3IgbmVzdGVkIFhlbiB1c2luZyBQViBkZXZpY2VzICh5b3UgbmVlZCB0d28gWGVuc3RvcmVz IGZvciB0aGF0Cj4gPj4+IGFzIHRoZSBuZXN0ZWQgZG9tMCBpcyBhY3RpbmcgYXMgWGVuIGJhY2tl bmQgc2VydmVyLCB3aGlsZSB1c2luZyBQVgo+ID4+PiBmcm9udGVuZHMgZm9yIGFjY2Vzc2luZyB0 aGUgInJlYWwiIHdvcmxkIG91dHNpZGUpLgo+ID4+Pgo+ID4+PiBUaGUgeGVuaG9zdF90IHNob3Vs ZCBiZSB1c2VkIGZvcjoKPiA+Pj4KPiA+Pj4gLSBhY2Nlc3NpbmcgWGVuc3RvcmUKPiA+Pj4gLSBp c3N1aW5nIGFuZCByZWNlaXZpbmcgZXZlbnRzCj4gPj4+IC0gZG9pbmcgaHlwZXJjYWxscwo+ID4+ PiAtIGdyYW50IHRhYmxlIG9wZXJhdGlvbnMKPiA+Pj4KPiA+Pgo+ID4+IEluIHRoZSB0ZXh0IGFi b3ZlLCBJIHNvcnQgb2Ygc3VnZ2VzdGVkIGEgc2xpY2Ugb2YgdGhpcyBvbiAxLmIpIHdpdGggYQo+ ID4+IHRyYW5zbGF0ZV9ncmVmKCkgYW5kIHB1dF9ncmVmKCkgQVBJIC0tIHRvIGdldCB0aGUgcGFn ZSBmcm9tIGEgZ3JlZi4gVGhpcyB3YXMKPiA+PiBiZWNhdXNlIG9mIHRoZSBmbGFnc3xob3N0X2Fk ZHIgaHVyZGxlIHdlIGRlcGljdGVkIGFib3ZlIHdydCB0byB1c2luZyB1c2luZyBncmFudAo+ID4+ IG1hcHMvdW5tYXBzLiBZb3UgdGhpbmsgc29tZSBvZiB0aGUgeGVuaG9zdCBsYXllciB3b3VsZCBi ZSBhbW1lbmFibGUgdG8gc3VwcG9ydAo+ID4+IHRoaXMgY2FzZT8KPiA+IAo+ID4gSSB0aGluayBz bywgeWVzLgo+ID4gCj4gPj4KPiA+Pj4gU28gZXhhY3RseSB0aGUga2luZCBvZiBzdHVmZiB5b3Ug d2FudCB0byBkbywgdG9vLgo+ID4+Pgo+ID4+IENvb2wgaWRlYSEKPiA+IAo+ID4gSW4gdGhlIGVu ZCB5b3UgbWlnaHQgbWFrZSBteSBsaWZlIGVhc2llciBmb3IgbmVzdGVkIFhlbi4gOi0pCj4gPiAK PiBIZWhlIDopCj4gCj4gPiBEbyB5b3Ugd2FudCB0byBoYXZlIGEgdHJ5IHdpdGggdGhhdCBpZGVh IG9yIHNob3VsZCBJIGRvIHRoYXQ/IEkgbWlnaHQgYmUKPiA+IGFibGUgdG8gc3RhcnQgd29ya2lu ZyBvbiB0aGF0IGluIGFib3V0IGEgbW9udGguCj4gPiAKPiBBbmt1ciAoQ0MnZWQpIHdpbGwgZ2l2 ZSBhIHNob3QgYXQgaXQsIGFuZCBzaG91bGQgc3RhcnQgYSBuZXcgdGhyZWFkIG9uIHRoaXMKPiB4 ZW5ob3N0IGFic3RyYWN0aW9uIGxheWVyLgoKSWYgeW91IGFyZSB1cCBmb3IgaXQsIGl0IHdvdWxk IGJlIGdyZWF0IHRvIHdyaXRlIHNvbWUgZG9jdW1lbnRhdGlvbiB0b28uCldlIGFyZSBzdGFydGlu ZyB0byBoYXZlIGRlY2VudCBkb2NzIGZvciBzb21lIFBWIHByb3RvY29scywgZGVzY3JpYmluZyBh CnNwZWNpZmljIFBWIGludGVyZmFjZSwgYnV0IHdlIGFyZSBsYWNraW5nIGRvY3MgYWJvdXQgdGhl IGJhc2ljIGJ1aWxkaW5nCmJsb2NrcyB0byBicmluZyB1cCBQViBkcml2ZXJzIGluIGdlbmVyYWwu IFRoZXkgd291bGQgYmUgZXh0cmVtZWx5CnVzZWZ1bC4gR2l2ZW4gdGhhdCB5b3UgaGF2ZSBqdXN0 IGRvbmUgdGhlIHdvcmssIHlvdSBhcmUgaW4gYSBncmVhdApwb3NpdGlvbiB0byB3cml0ZSB0aG9z ZSBkb2NzLiBFdmVuIGJhZCBFbmdsaXNoIHdvdWxkIGJlIGZpbmUsIEkgYW0gc3VyZQpzb21lYm9k eSBlbHNlIGNvdWxkIHZvbHVudGVlciB0byBjbGVhbi11cCB0aGUgbGFuZ3VhZ2UuIEFueXRoaW5n IHdvdWxkCmhlbHAgOi0pCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0 Lm9yZwpodHRwczovL2xpc3RzLnhlbnByb2plY3Qub3JnL21haWxtYW4vbGlzdGluZm8veGVuLWRl dmVs