From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 848D4110E for ; Thu, 6 Jul 2023 07:19:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1688627975; x=1720163975; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=2g1bfmb7JvyQO85ZXkV2EeVN1io1hktM1VBz/kom3ng=; b=O4kEhY8o19tVgYcLZUToDCznW+quQpWsCCCjWMyDrSZ8iihaqJ8mNRF/ BpDS+fEjoz6Xuo5dXWsD+GxoVchv0TI9C28zsW5U+I3CmwK6eyRMv/wYa DI1SlhnI+D1vJCwhh3xdwcfIMqzL9qI/yez8gKCzOluPHDdFLNuElB0O2 GOMxYuZQ9GVlx3vpMxoeTBI+1s8WAQE7P0P+LKoEO4mkNg6ZOKB3MIYzy 7M8qi8cA7mQ/uGlCOqmgIXDJom/FVKEW34yGxByRP0UkstIy/mPoTmOR+ mzWIXQoLcQ1QqTMKEeScfc1zVRWMZwZNqDudZ0SxrRmsWhk2Q7FS2/R1u w==; X-IronPort-AV: E=McAfee;i="6600,9927,10762"; a="367015573" X-IronPort-AV: E=Sophos;i="6.01,185,1684825200"; d="scan'208";a="367015573" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jul 2023 00:19:34 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10762"; a="784818848" X-IronPort-AV: E=Sophos;i="6.01,185,1684825200"; d="scan'208";a="784818848" Received: from hegang-mobl.ccr.corp.intel.com (HELO localhost) ([10.255.31.139]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jul 2023 00:19:30 -0700 Date: Thu, 6 Jul 2023 15:19:28 +0800 From: Yu Zhang To: David Stevens Cc: Sean Christopherson , Marc Zyngier , Michael Ellerman , Peter Xu , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org Subject: Re: [PATCH v7 5/8] KVM: x86/mmu: Don't pass FOLL_GET to __kvm_follow_pfn Message-ID: <20230706071927.o7gwmryonr3v3dpp@linux.intel.com> References: <20230704075054.3344915-1-stevensd@google.com> <20230704075054.3344915-6-stevensd@google.com> <20230705101800.ut4c6topn6ylwczs@linux.intel.com> Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20171215 On Thu, Jul 06, 2023 at 01:52:08PM +0900, David Stevens wrote: > On Wed, Jul 5, 2023 at 7:17 PM Yu Zhang wrote: > > > > On Tue, Jul 04, 2023 at 04:50:50PM +0900, David Stevens wrote: > > > From: David Stevens > > > > > > Stop passing FOLL_GET to __kvm_follow_pfn. This allows the host to map > > > memory into the guest that is backed by un-refcounted struct pages - for > > > example, higher order non-compound pages allocated by the amdgpu driver > > > via ttm_pool_alloc_page. > > > > I guess you mean the tail pages of the higher order non-compound pages? > > And as to the head page, it is said to be set to one coincidentally[*], > > and shall not be considered as refcounted. IIUC, refcount of this head > > page will be increased and decreased soon in hva_to_pfn_remapped(), so > > this may not be a problem(?). But treating this head page differently, > > as a refcounted one(e.g., to set the A/D flags), is weired. > > > > Or maybe I missed some context, e.g., can the head page be allocted to > > guest at all? > > Yes, this is to allow mapping the tail pages of higher order > non-compound pages - I should have been more precise in my wording. > The head pages can already be mapped into the guest. > > Treating the head and tail pages would require changing how KVM > behaves in a situation it supports today (rather than just adding > support for an unsupported situation). Currently, without this series, > KVM can map VM_PFNMAP|VM_IO memory backed by refcounted pages into the > guest. When that happens, KVM sets the A/D flags. I'm not sure whether > that's actually valid behavior, nor do I know whether anyone actually > cares about it. But it's what KVM does today, and I would shy away > from modifying that behavior without good reason. I know the A/D status of the refcounted, VM_PFNMAP|VM_IO backed pages will be recorded. And I have no idea if this is a necessary requirement either. But it feels awkward to see the head and the tail ones of non-compound pages be treated inconsistently. After all, the head page just happens to have its refcount being 1, it is not a real refcounted page. So I would suggest to mention such different behehavior in the commit message at least. :) > > > > > > @@ -883,7 +884,7 @@ static gpa_t FNAME(gva_to_gpa)(struct kvm_vcpu *vcpu, struct kvm_mmu *mmu, > > > */ > > > static int FNAME(sync_spte)(struct kvm_vcpu *vcpu, struct kvm_mmu_page *sp, int i) > > > { > > > - bool host_writable; > > > + bool host_writable, is_refcounted; > > > gpa_t first_pte_gpa; > > > u64 *sptep, spte; > > > struct kvm_memory_slot *slot; > > > @@ -940,10 +941,12 @@ static int FNAME(sync_spte)(struct kvm_vcpu *vcpu, struct kvm_mmu_page *sp, int > > > sptep = &sp->spt[i]; > > > spte = *sptep; > > > host_writable = spte & shadow_host_writable_mask; > > > + // TODO: is this correct? > > > + is_refcounted = spte & SPTE_MMU_PAGE_REFCOUNTED; > > > slot = kvm_vcpu_gfn_to_memslot(vcpu, gfn); > > > make_spte(vcpu, sp, slot, pte_access, gfn, > > > spte_to_pfn(spte), spte, true, false, > > > - host_writable, &spte); > > > + host_writable, is_refcounted, &spte); > > > > Could we restrict that a non-refcounted page shall not be used as shadow page? > > I'm not very familiar with the shadow mmu, so my response might not > make sense. But do you mean not allowing non-refcoutned pages as the > guest page tables shadowed by a kvm_mmu_page? It would probably be > possible to do that, and I doubt anyone would care about the > restriction. But as far as I can tell, the guest page table is only > accessed via kvm_vcpu_read_guest_atomic, which handles non-refcounted > pages just fine. Sorry, my brain just got baked... Pls just ignore this question :) B.R. Yu 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (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 0C4A7EB64DD for ; Thu, 6 Jul 2023 07:20:31 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=AFQRH+n2; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4QxSby20fzz3btj for ; Thu, 6 Jul 2023 17:20:30 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=AFQRH+n2; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=linux.intel.com (client-ip=134.134.136.65; helo=mga03.intel.com; envelope-from=yu.c.zhang@linux.intel.com; receiver=lists.ozlabs.org) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4QxSZz0b4jz2y1b for ; Thu, 6 Jul 2023 17:19:37 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1688627979; x=1720163979; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=2g1bfmb7JvyQO85ZXkV2EeVN1io1hktM1VBz/kom3ng=; b=AFQRH+n2ZKfrzhrDQAebVk8wVx3BgdnGrbIKY6Nv7wcoSCuAEjzD71Py 83imbFO0EWJ1oTAn7UMS+xAUUsEhimKptW8SNYMyzhSEDh2xMgXcuOPjs +qc7xMyqrSi4xmTiixq5FR4kHYt0QhpfswNmW6AiwFC5z05puGoxFgh94 lQ/hYcIMP0JuOC3hkFk+ALkRaEQd1J/9eUbtStmFIiFjIbjjnZ/YiJSgy ww1sxhh9ZAdh01nLkZIPzy44SUbKy8BFnfhuW6eFoqBsuVONh2v3NpUZa lEKnLEX0V689js8eK5AwUSKXa8+3LrYYs2cOJbErGe+ZprYtK47zZTNRG Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10762"; a="367015578" X-IronPort-AV: E=Sophos;i="6.01,185,1684825200"; d="scan'208";a="367015578" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jul 2023 00:19:34 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10762"; a="784818848" X-IronPort-AV: E=Sophos;i="6.01,185,1684825200"; d="scan'208";a="784818848" Received: from hegang-mobl.ccr.corp.intel.com (HELO localhost) ([10.255.31.139]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jul 2023 00:19:30 -0700 Date: Thu, 6 Jul 2023 15:19:28 +0800 From: Yu Zhang To: David Stevens Subject: Re: [PATCH v7 5/8] KVM: x86/mmu: Don't pass FOLL_GET to __kvm_follow_pfn Message-ID: <20230706071927.o7gwmryonr3v3dpp@linux.intel.com> References: <20230704075054.3344915-1-stevensd@google.com> <20230704075054.3344915-6-stevensd@google.com> <20230705101800.ut4c6topn6ylwczs@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20171215 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Marc Zyngier , kvm@vger.kernel.org, Sean Christopherson , linux-kernel@vger.kernel.org, Peter Xu , kvmarm@lists.linux.dev, linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Thu, Jul 06, 2023 at 01:52:08PM +0900, David Stevens wrote: > On Wed, Jul 5, 2023 at 7:17 PM Yu Zhang wrote: > > > > On Tue, Jul 04, 2023 at 04:50:50PM +0900, David Stevens wrote: > > > From: David Stevens > > > > > > Stop passing FOLL_GET to __kvm_follow_pfn. This allows the host to map > > > memory into the guest that is backed by un-refcounted struct pages - for > > > example, higher order non-compound pages allocated by the amdgpu driver > > > via ttm_pool_alloc_page. > > > > I guess you mean the tail pages of the higher order non-compound pages? > > And as to the head page, it is said to be set to one coincidentally[*], > > and shall not be considered as refcounted. IIUC, refcount of this head > > page will be increased and decreased soon in hva_to_pfn_remapped(), so > > this may not be a problem(?). But treating this head page differently, > > as a refcounted one(e.g., to set the A/D flags), is weired. > > > > Or maybe I missed some context, e.g., can the head page be allocted to > > guest at all? > > Yes, this is to allow mapping the tail pages of higher order > non-compound pages - I should have been more precise in my wording. > The head pages can already be mapped into the guest. > > Treating the head and tail pages would require changing how KVM > behaves in a situation it supports today (rather than just adding > support for an unsupported situation). Currently, without this series, > KVM can map VM_PFNMAP|VM_IO memory backed by refcounted pages into the > guest. When that happens, KVM sets the A/D flags. I'm not sure whether > that's actually valid behavior, nor do I know whether anyone actually > cares about it. But it's what KVM does today, and I would shy away > from modifying that behavior without good reason. I know the A/D status of the refcounted, VM_PFNMAP|VM_IO backed pages will be recorded. And I have no idea if this is a necessary requirement either. But it feels awkward to see the head and the tail ones of non-compound pages be treated inconsistently. After all, the head page just happens to have its refcount being 1, it is not a real refcounted page. So I would suggest to mention such different behehavior in the commit message at least. :) > > > > > > @@ -883,7 +884,7 @@ static gpa_t FNAME(gva_to_gpa)(struct kvm_vcpu *vcpu, struct kvm_mmu *mmu, > > > */ > > > static int FNAME(sync_spte)(struct kvm_vcpu *vcpu, struct kvm_mmu_page *sp, int i) > > > { > > > - bool host_writable; > > > + bool host_writable, is_refcounted; > > > gpa_t first_pte_gpa; > > > u64 *sptep, spte; > > > struct kvm_memory_slot *slot; > > > @@ -940,10 +941,12 @@ static int FNAME(sync_spte)(struct kvm_vcpu *vcpu, struct kvm_mmu_page *sp, int > > > sptep = &sp->spt[i]; > > > spte = *sptep; > > > host_writable = spte & shadow_host_writable_mask; > > > + // TODO: is this correct? > > > + is_refcounted = spte & SPTE_MMU_PAGE_REFCOUNTED; > > > slot = kvm_vcpu_gfn_to_memslot(vcpu, gfn); > > > make_spte(vcpu, sp, slot, pte_access, gfn, > > > spte_to_pfn(spte), spte, true, false, > > > - host_writable, &spte); > > > + host_writable, is_refcounted, &spte); > > > > Could we restrict that a non-refcounted page shall not be used as shadow page? > > I'm not very familiar with the shadow mmu, so my response might not > make sense. But do you mean not allowing non-refcoutned pages as the > guest page tables shadowed by a kvm_mmu_page? It would probably be > possible to do that, and I doubt anyone would care about the > restriction. But as far as I can tell, the guest page table is only > accessed via kvm_vcpu_read_guest_atomic, which handles non-refcounted > pages just fine. Sorry, my brain just got baked... Pls just ignore this question :) B.R. Yu 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 DC26EEB64D9 for ; Thu, 6 Jul 2023 07:20:07 +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=igW0RDfkBOM/G1u0kndmmE6hkEVMtMpMAOxtR8mBXb8=; b=pn75IPL1d2gi4p AEjUmNUisaQZOLTnZonmE+wKZyVT/DM23dO26q5/nJB3bDCgDwsZzQfjdsv1l3vBCSjj+RqZqmMXt nMONkxPlKMW7VxQooJsnBP36ovGCVy4F/Bn0osgAfQJ7+KLKN6QYXOMXQpBizszX3xjphn1Lb3NRQ ITm0GB6ZH7T3033f0KpSE0VJ9hcbqSZtFr2p9wNSXAensMSAQbhl9SHAyxTloPsT7LzwNl9N1Ms8m oxVxUMKF3PMaB+Zztba5cAJERxR1PbiN5opt87/4WRabyswNQJvGnhch6ajpUVPzkrk7/vcIBf0qS kXfneVOqeiiXF10M0gRA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qHJHF-000leV-0v; Thu, 06 Jul 2023 07:19:45 +0000 Received: from mga03.intel.com ([134.134.136.65]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qHJHC-000ld1-1I for linux-arm-kernel@lists.infradead.org; Thu, 06 Jul 2023 07:19:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1688627982; x=1720163982; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=2g1bfmb7JvyQO85ZXkV2EeVN1io1hktM1VBz/kom3ng=; b=YUwX85iMEUEf0fLrTAcACcV7DqOg7w8DsX4L+Sh2YNlbNi5OMZwlAK+G tDD0IqulKjbZVtD//iilemU5EjwUoTja18bFFjEoyJ7jUQvMtTIRQBE5R l0fXXzeIjpvhqYYf0h0L77CJWxtbJBeASzXxDFIpkJD29+xTjvD9QN7Q6 CLoW9A04olun0ViNThM8C+k4oGtzFK+eED4EAaK83IcqF//+wtL05+Tjj AvhuHTLmrxJtyMgVAozkAxQX4Y4BpAkEsOlbC0D1+2mVlEuQgygj2gjrZ e2pou4KyQ7hqC3ALf6OGMIqEbGpPglWRrDyhfvyR7a36GJQJm6aLf1nqZ A==; X-IronPort-AV: E=McAfee;i="6600,9927,10762"; a="367015576" X-IronPort-AV: E=Sophos;i="6.01,185,1684825200"; d="scan'208";a="367015576" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jul 2023 00:19:34 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10762"; a="784818848" X-IronPort-AV: E=Sophos;i="6.01,185,1684825200"; d="scan'208";a="784818848" Received: from hegang-mobl.ccr.corp.intel.com (HELO localhost) ([10.255.31.139]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jul 2023 00:19:30 -0700 Date: Thu, 6 Jul 2023 15:19:28 +0800 From: Yu Zhang To: David Stevens Cc: Sean Christopherson , Marc Zyngier , Michael Ellerman , Peter Xu , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org Subject: Re: [PATCH v7 5/8] KVM: x86/mmu: Don't pass FOLL_GET to __kvm_follow_pfn Message-ID: <20230706071927.o7gwmryonr3v3dpp@linux.intel.com> References: <20230704075054.3344915-1-stevensd@google.com> <20230704075054.3344915-6-stevensd@google.com> <20230705101800.ut4c6topn6ylwczs@linux.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230706_001942_487197_B8730C7C X-CRM114-Status: GOOD ( 34.71 ) 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 T24gVGh1LCBKdWwgMDYsIDIwMjMgYXQgMDE6NTI6MDhQTSArMDkwMCwgRGF2aWQgU3RldmVucyB3 cm90ZToKPiBPbiBXZWQsIEp1bCA1LCAyMDIzIGF0IDc6MTfigK9QTSBZdSBaaGFuZyA8eXUuYy56 aGFuZ0BsaW51eC5pbnRlbC5jb20+IHdyb3RlOgo+ID4KPiA+IE9uIFR1ZSwgSnVsIDA0LCAyMDIz IGF0IDA0OjUwOjUwUE0gKzA5MDAsIERhdmlkIFN0ZXZlbnMgd3JvdGU6Cj4gPiA+IEZyb206IERh dmlkIFN0ZXZlbnMgPHN0ZXZlbnNkQGNocm9taXVtLm9yZz4KPiA+ID4KPiA+ID4gU3RvcCBwYXNz aW5nIEZPTExfR0VUIHRvIF9fa3ZtX2ZvbGxvd19wZm4uIFRoaXMgYWxsb3dzIHRoZSBob3N0IHRv IG1hcAo+ID4gPiBtZW1vcnkgaW50byB0aGUgZ3Vlc3QgdGhhdCBpcyBiYWNrZWQgYnkgdW4tcmVm Y291bnRlZCBzdHJ1Y3QgcGFnZXMgLSBmb3IKPiA+ID4gZXhhbXBsZSwgaGlnaGVyIG9yZGVyIG5v bi1jb21wb3VuZCBwYWdlcyBhbGxvY2F0ZWQgYnkgdGhlIGFtZGdwdSBkcml2ZXIKPiA+ID4gdmlh IHR0bV9wb29sX2FsbG9jX3BhZ2UuCj4gPgo+ID4gSSBndWVzcyB5b3UgbWVhbiB0aGUgdGFpbCBw YWdlcyBvZiB0aGUgaGlnaGVyIG9yZGVyIG5vbi1jb21wb3VuZCBwYWdlcz8KPiA+IEFuZCBhcyB0 byB0aGUgaGVhZCBwYWdlLCBpdCBpcyBzYWlkIHRvIGJlIHNldCB0byBvbmUgY29pbmNpZGVudGFs bHlbKl0sCj4gPiBhbmQgc2hhbGwgbm90IGJlIGNvbnNpZGVyZWQgYXMgcmVmY291bnRlZC4gIElJ VUMsIHJlZmNvdW50IG9mIHRoaXMgaGVhZAo+ID4gcGFnZSB3aWxsIGJlIGluY3JlYXNlZCBhbmQg ZGVjcmVhc2VkIHNvb24gaW4gaHZhX3RvX3Bmbl9yZW1hcHBlZCgpLCBzbwo+ID4gdGhpcyBtYXkg bm90IGJlIGEgcHJvYmxlbSg/KS4gQnV0IHRyZWF0aW5nIHRoaXMgaGVhZCBwYWdlIGRpZmZlcmVu dGx5LAo+ID4gYXMgYSByZWZjb3VudGVkIG9uZShlLmcuLCB0byBzZXQgdGhlIEEvRCBmbGFncyks IGlzIHdlaXJlZC4KPiA+Cj4gPiBPciBtYXliZSBJIG1pc3NlZCBzb21lIGNvbnRleHQsIGUuZy4s IGNhbiB0aGUgaGVhZCBwYWdlIGJlIGFsbG9jdGVkIHRvCj4gPiBndWVzdCBhdCBhbGw/Cj4gCj4g WWVzLCB0aGlzIGlzIHRvIGFsbG93IG1hcHBpbmcgdGhlIHRhaWwgcGFnZXMgb2YgaGlnaGVyIG9y ZGVyCj4gbm9uLWNvbXBvdW5kIHBhZ2VzIC0gSSBzaG91bGQgaGF2ZSBiZWVuIG1vcmUgcHJlY2lz ZSBpbiBteSB3b3JkaW5nLgo+IFRoZSBoZWFkIHBhZ2VzIGNhbiBhbHJlYWR5IGJlIG1hcHBlZCBp bnRvIHRoZSBndWVzdC4KPiAKPiBUcmVhdGluZyB0aGUgaGVhZCBhbmQgdGFpbCBwYWdlcyB3b3Vs ZCByZXF1aXJlIGNoYW5naW5nIGhvdyBLVk0KPiBiZWhhdmVzIGluIGEgc2l0dWF0aW9uIGl0IHN1 cHBvcnRzIHRvZGF5IChyYXRoZXIgdGhhbiBqdXN0IGFkZGluZwo+IHN1cHBvcnQgZm9yIGFuIHVu c3VwcG9ydGVkIHNpdHVhdGlvbikuIEN1cnJlbnRseSwgd2l0aG91dCB0aGlzIHNlcmllcywKPiBL Vk0gY2FuIG1hcCBWTV9QRk5NQVB8Vk1fSU8gbWVtb3J5IGJhY2tlZCBieSByZWZjb3VudGVkIHBh Z2VzIGludG8gdGhlCj4gZ3Vlc3QuIFdoZW4gdGhhdCBoYXBwZW5zLCBLVk0gc2V0cyB0aGUgQS9E IGZsYWdzLiBJJ20gbm90IHN1cmUgd2hldGhlcgo+IHRoYXQncyBhY3R1YWxseSB2YWxpZCBiZWhh dmlvciwgbm9yIGRvIEkga25vdyB3aGV0aGVyIGFueW9uZSBhY3R1YWxseQo+IGNhcmVzIGFib3V0 IGl0LiBCdXQgaXQncyB3aGF0IEtWTSBkb2VzIHRvZGF5LCBhbmQgSSB3b3VsZCBzaHkgYXdheQo+ IGZyb20gbW9kaWZ5aW5nIHRoYXQgYmVoYXZpb3Igd2l0aG91dCBnb29kIHJlYXNvbi4KCkkga25v dyB0aGUgQS9EIHN0YXR1cyBvZiB0aGUgcmVmY291bnRlZCwgVk1fUEZOTUFQfFZNX0lPIGJhY2tl ZCBwYWdlcwp3aWxsIGJlIHJlY29yZGVkLiBBbmQgSSBoYXZlIG5vIGlkZWEgaWYgdGhpcyBpcyBh IG5lY2Vzc2FyeSByZXF1aXJlbWVudAplaXRoZXIuCgpCdXQgaXQgZmVlbHMgYXdrd2FyZCB0byBz ZWUgdGhlIGhlYWQgYW5kIHRoZSB0YWlsIG9uZXMgb2Ygbm9uLWNvbXBvdW5kCnBhZ2VzIGJlIHRy ZWF0ZWQgaW5jb25zaXN0ZW50bHkuIEFmdGVyIGFsbCwgdGhlIGhlYWQgcGFnZSBqdXN0IGhhcHBl bnMKdG8gaGF2ZSBpdHMgcmVmY291bnQgYmVpbmcgMSwgaXQgaXMgbm90IGEgcmVhbCByZWZjb3Vu dGVkIHBhZ2UuCgpTbyBJIHdvdWxkIHN1Z2dlc3QgdG8gbWVudGlvbiBzdWNoIGRpZmZlcmVudCBi ZWhlaGF2aW9yIGluIHRoZSBjb21taXQKbWVzc2FnZSBhdCBsZWFzdC4gOikKCj4gPiA+Cj4gPiA+ IEBAIC04ODMsNyArODg0LDcgQEAgc3RhdGljIGdwYV90IEZOQU1FKGd2YV90b19ncGEpKHN0cnVj dCBrdm1fdmNwdSAqdmNwdSwgc3RydWN0IGt2bV9tbXUgKm1tdSwKPiA+ID4gICAqLwo+ID4gPiAg c3RhdGljIGludCBGTkFNRShzeW5jX3NwdGUpKHN0cnVjdCBrdm1fdmNwdSAqdmNwdSwgc3RydWN0 IGt2bV9tbXVfcGFnZSAqc3AsIGludCBpKQo+ID4gPiAgewo+ID4gPiAtICAgICBib29sIGhvc3Rf d3JpdGFibGU7Cj4gPiA+ICsgICAgIGJvb2wgaG9zdF93cml0YWJsZSwgaXNfcmVmY291bnRlZDsK PiA+ID4gICAgICAgZ3BhX3QgZmlyc3RfcHRlX2dwYTsKPiA+ID4gICAgICAgdTY0ICpzcHRlcCwg c3B0ZTsKPiA+ID4gICAgICAgc3RydWN0IGt2bV9tZW1vcnlfc2xvdCAqc2xvdDsKPiA+ID4gQEAg LTk0MCwxMCArOTQxLDEyIEBAIHN0YXRpYyBpbnQgRk5BTUUoc3luY19zcHRlKShzdHJ1Y3Qga3Zt X3ZjcHUgKnZjcHUsIHN0cnVjdCBrdm1fbW11X3BhZ2UgKnNwLCBpbnQKPiA+ID4gICAgICAgc3B0 ZXAgPSAmc3AtPnNwdFtpXTsKPiA+ID4gICAgICAgc3B0ZSA9ICpzcHRlcDsKPiA+ID4gICAgICAg aG9zdF93cml0YWJsZSA9IHNwdGUgJiBzaGFkb3dfaG9zdF93cml0YWJsZV9tYXNrOwo+ID4gPiAr ICAgICAvLyBUT0RPOiBpcyB0aGlzIGNvcnJlY3Q/Cj4gPiA+ICsgICAgIGlzX3JlZmNvdW50ZWQg PSBzcHRlICYgU1BURV9NTVVfUEFHRV9SRUZDT1VOVEVEOwo+ID4gPiAgICAgICBzbG90ID0ga3Zt X3ZjcHVfZ2ZuX3RvX21lbXNsb3QodmNwdSwgZ2ZuKTsKPiA+ID4gICAgICAgbWFrZV9zcHRlKHZj cHUsIHNwLCBzbG90LCBwdGVfYWNjZXNzLCBnZm4sCj4gPiA+ICAgICAgICAgICAgICAgICBzcHRl X3RvX3BmbihzcHRlKSwgc3B0ZSwgdHJ1ZSwgZmFsc2UsCj4gPiA+IC0gICAgICAgICAgICAgICBo b3N0X3dyaXRhYmxlLCAmc3B0ZSk7Cj4gPiA+ICsgICAgICAgICAgICAgICBob3N0X3dyaXRhYmxl LCBpc19yZWZjb3VudGVkLCAmc3B0ZSk7Cj4gPgo+ID4gQ291bGQgd2UgcmVzdHJpY3QgdGhhdCBh IG5vbi1yZWZjb3VudGVkIHBhZ2Ugc2hhbGwgbm90IGJlIHVzZWQgYXMgc2hhZG93IHBhZ2U/Cj4g Cj4gSSdtIG5vdCB2ZXJ5IGZhbWlsaWFyIHdpdGggdGhlIHNoYWRvdyBtbXUsIHNvIG15IHJlc3Bv bnNlIG1pZ2h0IG5vdAo+IG1ha2Ugc2Vuc2UuIEJ1dCBkbyB5b3UgbWVhbiBub3QgYWxsb3dpbmcg bm9uLXJlZmNvdXRuZWQgcGFnZXMgYXMgdGhlCj4gZ3Vlc3QgcGFnZSB0YWJsZXMgc2hhZG93ZWQg YnkgYSBrdm1fbW11X3BhZ2U/IEl0IHdvdWxkIHByb2JhYmx5IGJlCj4gcG9zc2libGUgdG8gZG8g dGhhdCwgYW5kIEkgZG91YnQgYW55b25lIHdvdWxkIGNhcmUgYWJvdXQgdGhlCj4gcmVzdHJpY3Rp b24uIEJ1dCBhcyBmYXIgYXMgSSBjYW4gdGVsbCwgdGhlIGd1ZXN0IHBhZ2UgdGFibGUgaXMgb25s eQo+IGFjY2Vzc2VkIHZpYSBrdm1fdmNwdV9yZWFkX2d1ZXN0X2F0b21pYywgd2hpY2ggaGFuZGxl cyBub24tcmVmY291bnRlZAo+IHBhZ2VzIGp1c3QgZmluZS4KClNvcnJ5LCBteSBicmFpbiBqdXN0 IGdvdCBiYWtlZC4uLiBQbHMganVzdCBpZ25vcmUgdGhpcyBxdWVzdGlvbiA6KQoKQi5SLgpZdQoK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGludXgtYXJt LWtlcm5lbCBtYWlsaW5nIGxpc3QKbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3Jn Cmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtYXJtLWtl cm5lbAo=