From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Jones Date: Thu, 11 Apr 2024 09:38:41 +0200 Subject: [PATCH v4 07/15] RISC-V: KVM: No need to exit to the user space if perf event failed In-Reply-To: <7d02c86e-8c36-4e78-9fa8-5e30f3431eb3@rivosinc.com> References: <20240229010130.1380926-1-atishp@rivosinc.com> <20240229010130.1380926-8-atishp@rivosinc.com> <20240302-1a3c0df25f2422e1e6abecf3@orel> <20240404-ea40bc0237635d671e64fef6@orel> <7d02c86e-8c36-4e78-9fa8-5e30f3431eb3@rivosinc.com> Message-ID: <20240411-6fe47ccc32d9cb7baa121b4d@orel> List-Id: To: kvm-riscv@lists.infradead.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Wed, Apr 10, 2024 at 03:44:32PM -0700, Atish Patra wrote: > On 4/4/24 05:16, Andrew Jones wrote: > > On Mon, Apr 01, 2024 at 03:37:01PM -0700, Atish Patra wrote: > > > On Sat, Mar 2, 2024 at 12:16?AM Andrew Jones wrote: > > > > > > > > On Wed, Feb 28, 2024 at 05:01:22PM -0800, Atish Patra wrote: > > > > > Currently, we return a linux error code if creating a perf event failed > > > > > in kvm. That shouldn't be necessary as guest can continue to operate > > > > > without perf profiling or profiling with firmware counters. > > > > > > > > > > Return appropriate SBI error code to indicate that PMU configuration > > > > > failed. An error message in kvm already describes the reason for failure. > > > > > > > > I don't know enough about the perf subsystem to know if there may be > > > > a concern that resources are temporarily unavailable. If so, then this > > > > > > Do you mean the hardware resources unavailable because the host is using it ? > > > > Yes (I think). The issue I'm thinking of is if kvm_pmu_create_perf_event > > (perf_event_create_kernel_counter) returns something like EBUSY and then > > we translate that to SBI_ERR_NOT_SUPPORTED. I'm not sure guests would > > interpret not-supported as an error which means they can retry. Or if > > they retry and get something other than not-supported if they'd be > > confused. > > > > At least in Linux driver, treats -ENOTSUPP and it just fails. Other guest OS > implementation may interpret it differently. But they should fail at that > point as well. I don't see how can they interpret to be retry. > > The perf user can retry again with assumption that may be enough counters > are not available at this moment. But that's different from return a retry > from driver code. > > Even if we support a retry error code, when does the caller retry it ? > The driver doesn't know how long the user is going to run the perf command > to keep the hardware resources occupied. > > I feel the perf user is the best entity to know that and should retry if it > knows the previous run is over which might have released the hardware > resources. I agree, but how does the user know that retrying makes sense? I presume -ENOTSUPP will get propagated all the way to the user in a form that means "not supported". Or, can the user list all resources and then when they see "not supported" know that means "not supported at the moment", as they've already seen that the resources exist? Anyway, as I said, I don't know enough about the perf subsystem to know if this is a real concern or not, but it sort of looks like we have potential to tell users that something isn't supported when in fact it is supported, but only temporarily unavailable. Thanks, drew From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 54E7213E40C for ; Thu, 11 Apr 2024 07:38:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712821126; cv=none; b=i0TSUWhzEN7q4o3TfCCXQmyW/cJtvjXMEaBoB6gosJi9N1y1I4q4Jj37Iv6PLaAoK4zM8iRnNFA8SX618y1CeXnwivdmyxzlzvzOMEg6MdPPb00W2J7julDm4jA32p+4NKMDE1kEyY9QBJTRCAaQmBGSfYEKucNaulFu3yySlc8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712821126; c=relaxed/simple; bh=1vkXgr7mU8ODetSlTUd524GtmWxMzUtCT+xXdKXnC+Q=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=c2lrlw2xcNoVFnx69oJ2GvzSxOLgEydL2mfHP8i6/7C/JgamqYEhGa7nK+6L2YNGqfX/utrPz+HOkDuKKux6hFg2lGJlnRAZil/huBf9WC8NJlNgWHsho2TDYONu+bcTO3TomBJVBVMcp6QQa/iNAnXMkA5gJQv6DDEid24Pi+8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ventanamicro.com; spf=pass smtp.mailfrom=ventanamicro.com; dkim=pass (2048-bit key) header.d=ventanamicro.com header.i=@ventanamicro.com header.b=PyXZMQnv; arc=none smtp.client-ip=209.85.218.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ventanamicro.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ventanamicro.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ventanamicro.com header.i=@ventanamicro.com header.b="PyXZMQnv" Received: by mail-ej1-f50.google.com with SMTP id a640c23a62f3a-a5224dfa9adso28263766b.0 for ; Thu, 11 Apr 2024 00:38:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; t=1712821122; x=1713425922; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=Qi1RHVmEtAvgNYlK/Z30HZoUwL3LvYqcc/16dHeni2I=; b=PyXZMQnv7q/B4067/6mgaOEdkORETeuEB3mvFDQ4A0rKtG2pvW2uRyba18ydAUoWmM 6AUgOfSAYS1UorUFUhBo88UfWUOA2xPYmi84UgPQMJxKYo/pykINfEuKLiyx4crR14fq nUsk5eUgBVGU0QsugfbOyQ/WLxwRXxSQ9R6LbXqY8vRueJpePn4WFi9FK1G/VbwYZ/kC VL5z1uE86679A0/BxlJIegJiLKMFt9oiA/SVNS3bdtfbrdfDdzdiKJuwgVPqcp8gdLDY 6S5qVnuyXtGd5ztBBL+ddfBQJmMQDmN1rYIlemg1I41JRAWPSP33boe+WKqaXHAPp5Xm rEyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712821122; x=1713425922; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Qi1RHVmEtAvgNYlK/Z30HZoUwL3LvYqcc/16dHeni2I=; b=GJSCTHow1oIvZxpht8IVUQFavWggc2T40GeXKG0egkWxcDOLe/tJXpghKyR9v9z6H9 YyjTi6bek0a5JW02Rt0J6DSASKspW+NqSgVyxUkhBWdpYWcGyIQNiV4M4YFS4Z+0Q6DJ IPNiUV7cPAfiOmCoopdol8ybFvOKqSoLd5Mas/8jd8BWx9VV6VzL0uVMVpvZbeuHK/7k 2oKqh55x7fqNpiK96P3asYXMHVEgKSulo+rJQKidGI67PpNvvPEBu9XuimP8GrphU6Mr nBopMHGWUY2vtKIwN17KF/rXtoOQBXk9AAMtI4fu22z8NM7QNorK4IjzlyjX26vMHXD6 /grg== X-Forwarded-Encrypted: i=1; AJvYcCW/OTX8kF7VWy204xgaBdvhOToNgFbVT5ZqD6l+3Sn7S7qRFmrjzh4Pyp6DQdzCL9jwhbgkvtSC55o+WCDxbh9JjAIOJnKBF/wzgu+Nl6QH X-Gm-Message-State: AOJu0YysY6O+ehioDMJBQrujgbyUhFWMOZdC/YszdIy8fY2LdbgiTjKG 0rK5tKBGoYzeZlJ4i8E3/jWFx2MIVsNG/PtLSn7vPngB1igkn7xCiFZ9kZR01RI= X-Google-Smtp-Source: AGHT+IHndxelT9zzrPtEEf61xurR5ZhY/uXW2mp7zI7XhBJBneHaSOP3oqNpAKZ/ndwpR0RWwH9wFg== X-Received: by 2002:a17:907:1c2a:b0:a4e:410e:9525 with SMTP id nc42-20020a1709071c2a00b00a4e410e9525mr1764454ejc.30.1712821122486; Thu, 11 Apr 2024 00:38:42 -0700 (PDT) Received: from localhost (cst2-173-16.cust.vodafone.cz. [31.30.173.16]) by smtp.gmail.com with ESMTPSA id gv7-20020a170906f10700b00a4e0df9e793sm478233ejb.136.2024.04.11.00.38.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Apr 2024 00:38:42 -0700 (PDT) Date: Thu, 11 Apr 2024 09:38:41 +0200 From: Andrew Jones To: Atish Patra Cc: Atish Patra , linux-kernel@vger.kernel.org, Anup Patel , Albert Ou , Alexandre Ghiti , Conor Dooley , Guo Ren , Icenowy Zheng , kvm-riscv@lists.infradead.org, kvm@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-riscv@lists.infradead.org, Mark Rutland , Palmer Dabbelt , Paolo Bonzini , Paul Walmsley , Shuah Khan , Will Deacon Subject: Re: [PATCH v4 07/15] RISC-V: KVM: No need to exit to the user space if perf event failed Message-ID: <20240411-6fe47ccc32d9cb7baa121b4d@orel> References: <20240229010130.1380926-1-atishp@rivosinc.com> <20240229010130.1380926-8-atishp@rivosinc.com> <20240302-1a3c0df25f2422e1e6abecf3@orel> <20240404-ea40bc0237635d671e64fef6@orel> <7d02c86e-8c36-4e78-9fa8-5e30f3431eb3@rivosinc.com> Precedence: bulk X-Mailing-List: linux-kselftest@vger.kernel.org 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: <7d02c86e-8c36-4e78-9fa8-5e30f3431eb3@rivosinc.com> On Wed, Apr 10, 2024 at 03:44:32PM -0700, Atish Patra wrote: > On 4/4/24 05:16, Andrew Jones wrote: > > On Mon, Apr 01, 2024 at 03:37:01PM -0700, Atish Patra wrote: > > > On Sat, Mar 2, 2024 at 12:16 AM Andrew Jones wrote: > > > > > > > > On Wed, Feb 28, 2024 at 05:01:22PM -0800, Atish Patra wrote: > > > > > Currently, we return a linux error code if creating a perf event failed > > > > > in kvm. That shouldn't be necessary as guest can continue to operate > > > > > without perf profiling or profiling with firmware counters. > > > > > > > > > > Return appropriate SBI error code to indicate that PMU configuration > > > > > failed. An error message in kvm already describes the reason for failure. > > > > > > > > I don't know enough about the perf subsystem to know if there may be > > > > a concern that resources are temporarily unavailable. If so, then this > > > > > > Do you mean the hardware resources unavailable because the host is using it ? > > > > Yes (I think). The issue I'm thinking of is if kvm_pmu_create_perf_event > > (perf_event_create_kernel_counter) returns something like EBUSY and then > > we translate that to SBI_ERR_NOT_SUPPORTED. I'm not sure guests would > > interpret not-supported as an error which means they can retry. Or if > > they retry and get something other than not-supported if they'd be > > confused. > > > > At least in Linux driver, treats -ENOTSUPP and it just fails. Other guest OS > implementation may interpret it differently. But they should fail at that > point as well. I don't see how can they interpret to be retry. > > The perf user can retry again with assumption that may be enough counters > are not available at this moment. But that's different from return a retry > from driver code. > > Even if we support a retry error code, when does the caller retry it ? > The driver doesn't know how long the user is going to run the perf command > to keep the hardware resources occupied. > > I feel the perf user is the best entity to know that and should retry if it > knows the previous run is over which might have released the hardware > resources. I agree, but how does the user know that retrying makes sense? I presume -ENOTSUPP will get propagated all the way to the user in a form that means "not supported". Or, can the user list all resources and then when they see "not supported" know that means "not supported at the moment", as they've already seen that the resources exist? Anyway, as I said, I don't know enough about the perf subsystem to know if this is a real concern or not, but it sort of looks like we have potential to tell users that something isn't supported when in fact it is supported, but only temporarily unavailable. Thanks, drew 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 A2BDFCD128A for ; Thu, 11 Apr 2024 07:38:53 +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:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject: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=Hom+weDEtm/sntJYsE4ngwT61YP1/D7bCqAGUw+1Stk=; b=EpQs4GNO3zJDVt z8Vz+pmpeB11l/gJQ3+jvbyx43Bbi0FvJeF7yROzOQACOjFt+rqAo423Hla/n7OJjj6Y3h8E+HCHi l3McRAa7iwfAVdgEHu5N8DvCRnxh5Fw3cNAqHX729kfcr1bnuLz4u5FfnlrAPOa4euNvdq5iWC4ce /iL0hZkfg4p3TNB8FACfheu2H35wMAyI0kWrvEckE55Um5RdQ9u3aTWgoJE0ky5nICSmq+MYmBsft io/DnZHMVKVJYDAhdSSr0FL1ggqv4zpw//XQUBepZ9PuVyGL4cDe1nmm8+qfJ1yXSzpreebCqZSJ9 m8LQcQ0vf2QMAGTsW0qA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rup1F-0000000AtPR-0TVc; Thu, 11 Apr 2024 07:38:49 +0000 Received: from mail-ej1-x632.google.com ([2a00:1450:4864:20::632]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rup1B-0000000AtMF-30cU for linux-riscv@lists.infradead.org; Thu, 11 Apr 2024 07:38:47 +0000 Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-a46ea03c2a5so96473966b.1 for ; Thu, 11 Apr 2024 00:38:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; t=1712821122; x=1713425922; darn=lists.infradead.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=Qi1RHVmEtAvgNYlK/Z30HZoUwL3LvYqcc/16dHeni2I=; b=P6Rzfk5igtBuVHz/YtQVOj+DKzC76UGr/7+xhUdBIHpBHDgLq9rF3b8UFBRi+iZdHU A54Db26JPqQfx9iU9PfMN6lnrcKygi20R5RW5IL0eHBOvv3PwNMGeZzhqkOggwSrefkW jRumDnwt6jqAgReW4r9syN6K7/hI6epJLPF9qdRKxTJvscS895BdUAKkNcvuB4ok3g9V NmVV7HCRj75iARaRSGEzIjaxqo9ghb3hy3AR3Et+a75hh5kcF17G7jw1VqA44g+3xaM2 r2iJvGajfy/B+MnLaXR5IwFe6Lfrn05LFRicArPFemaR4iUNxT08dI/HUvjYljcn6yZm 2krQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712821122; x=1713425922; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Qi1RHVmEtAvgNYlK/Z30HZoUwL3LvYqcc/16dHeni2I=; b=LMuK2CbAyWwMIAPNIit6skSC/tx1ojrLpaKJ9QUHhIfxp1EAV9N9AcKwp/fOwp1XL3 fPDOcPefqN28fIA4Y6fZ/g9QrIF+7QoS1+A+Rp3JvJ6RTlQ9aDNt4zsT2TTIFwPBru8z 2tfz7qjYXM3pHkRGtlEsxOoSqaaMUo0mFkc0OXXiJvl0BRvTNrXUpKj7pXk04u50SnLw wsyn/MVLkGYdicUa9YGB+tIbloX8xgeYG4UIWFMJ9JHbFD5hVjDMJA3Dcztki8gSSxRJ SO3bg1wgkGqZGE/4tfWcakpI8v+JMhzdfOaE8jAqxy+WohwlYHilDK6V8iWLeP7zU8o+ E3bw== X-Forwarded-Encrypted: i=1; AJvYcCUs2BF8OHKKzlwcA1A4NjLgr4CRLwwEwRo3jGXn8hPY8B5KS4iyQ5OFsdcekkwzM5L7Oi8gEYg70nMYEtn3LkRWhrFDpnoxFqEbWzo0/IoQ X-Gm-Message-State: AOJu0YwdDH/5KNG6j/O8mK8nWPtI6SdoU8P9L8iqQCW+spBjEHN7hIJ1 6XJtSZBSBaRmeWduhmAzno3JZU2SMQ+/x8Ckz5uqHxN8hsEBhmqOvffQSE6dRa4= X-Google-Smtp-Source: AGHT+IHndxelT9zzrPtEEf61xurR5ZhY/uXW2mp7zI7XhBJBneHaSOP3oqNpAKZ/ndwpR0RWwH9wFg== X-Received: by 2002:a17:907:1c2a:b0:a4e:410e:9525 with SMTP id nc42-20020a1709071c2a00b00a4e410e9525mr1764454ejc.30.1712821122486; Thu, 11 Apr 2024 00:38:42 -0700 (PDT) Received: from localhost (cst2-173-16.cust.vodafone.cz. [31.30.173.16]) by smtp.gmail.com with ESMTPSA id gv7-20020a170906f10700b00a4e0df9e793sm478233ejb.136.2024.04.11.00.38.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Apr 2024 00:38:42 -0700 (PDT) Date: Thu, 11 Apr 2024 09:38:41 +0200 From: Andrew Jones To: Atish Patra Subject: Re: [PATCH v4 07/15] RISC-V: KVM: No need to exit to the user space if perf event failed Message-ID: <20240411-6fe47ccc32d9cb7baa121b4d@orel> References: <20240229010130.1380926-1-atishp@rivosinc.com> <20240229010130.1380926-8-atishp@rivosinc.com> <20240302-1a3c0df25f2422e1e6abecf3@orel> <20240404-ea40bc0237635d671e64fef6@orel> <7d02c86e-8c36-4e78-9fa8-5e30f3431eb3@rivosinc.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <7d02c86e-8c36-4e78-9fa8-5e30f3431eb3@rivosinc.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240411_003845_864448_A1C221BE X-CRM114-Status: GOOD ( 34.34 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , linux-kselftest@vger.kernel.org, Albert Ou , Alexandre Ghiti , kvm@vger.kernel.org, Anup Patel , Paul Walmsley , Will Deacon , linux-kernel@vger.kernel.org, Conor Dooley , Paolo Bonzini , Guo Ren , kvm-riscv@lists.infradead.org, Atish Patra , Palmer Dabbelt , linux-riscv@lists.infradead.org, Shuah Khan Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org T24gV2VkLCBBcHIgMTAsIDIwMjQgYXQgMDM6NDQ6MzJQTSAtMDcwMCwgQXRpc2ggUGF0cmEgd3Jv dGU6Cj4gT24gNC80LzI0IDA1OjE2LCBBbmRyZXcgSm9uZXMgd3JvdGU6Cj4gPiBPbiBNb24sIEFw ciAwMSwgMjAyNCBhdCAwMzozNzowMVBNIC0wNzAwLCBBdGlzaCBQYXRyYSB3cm90ZToKPiA+ID4g T24gU2F0LCBNYXIgMiwgMjAyNCBhdCAxMjoxNuKAr0FNIEFuZHJldyBKb25lcyA8YWpvbmVzQHZl bnRhbmFtaWNyby5jb20+IHdyb3RlOgo+ID4gPiA+IAo+ID4gPiA+IE9uIFdlZCwgRmViIDI4LCAy MDI0IGF0IDA1OjAxOjIyUE0gLTA4MDAsIEF0aXNoIFBhdHJhIHdyb3RlOgo+ID4gPiA+ID4gQ3Vy cmVudGx5LCB3ZSByZXR1cm4gYSBsaW51eCBlcnJvciBjb2RlIGlmIGNyZWF0aW5nIGEgcGVyZiBl dmVudCBmYWlsZWQKPiA+ID4gPiA+IGluIGt2bS4gVGhhdCBzaG91bGRuJ3QgYmUgbmVjZXNzYXJ5 IGFzIGd1ZXN0IGNhbiBjb250aW51ZSB0byBvcGVyYXRlCj4gPiA+ID4gPiB3aXRob3V0IHBlcmYg cHJvZmlsaW5nIG9yIHByb2ZpbGluZyB3aXRoIGZpcm13YXJlIGNvdW50ZXJzLgo+ID4gPiA+ID4g Cj4gPiA+ID4gPiBSZXR1cm4gYXBwcm9wcmlhdGUgU0JJIGVycm9yIGNvZGUgdG8gaW5kaWNhdGUg dGhhdCBQTVUgY29uZmlndXJhdGlvbgo+ID4gPiA+ID4gZmFpbGVkLiBBbiBlcnJvciBtZXNzYWdl IGluIGt2bSBhbHJlYWR5IGRlc2NyaWJlcyB0aGUgcmVhc29uIGZvciBmYWlsdXJlLgo+ID4gPiA+ IAo+ID4gPiA+IEkgZG9uJ3Qga25vdyBlbm91Z2ggYWJvdXQgdGhlIHBlcmYgc3Vic3lzdGVtIHRv IGtub3cgaWYgdGhlcmUgbWF5IGJlCj4gPiA+ID4gYSBjb25jZXJuIHRoYXQgcmVzb3VyY2VzIGFy ZSB0ZW1wb3JhcmlseSB1bmF2YWlsYWJsZS4gSWYgc28sIHRoZW4gdGhpcwo+ID4gPiAKPiA+ID4g RG8geW91IG1lYW4gdGhlIGhhcmR3YXJlIHJlc291cmNlcyB1bmF2YWlsYWJsZSBiZWNhdXNlIHRo ZSBob3N0IGlzIHVzaW5nIGl0ID8KPiA+IAo+ID4gWWVzIChJIHRoaW5rKS4gVGhlIGlzc3VlIEkn bSB0aGlua2luZyBvZiBpcyBpZiBrdm1fcG11X2NyZWF0ZV9wZXJmX2V2ZW50Cj4gPiAocGVyZl9l dmVudF9jcmVhdGVfa2VybmVsX2NvdW50ZXIpIHJldHVybnMgc29tZXRoaW5nIGxpa2UgRUJVU1kg YW5kIHRoZW4KPiA+IHdlIHRyYW5zbGF0ZSB0aGF0IHRvIFNCSV9FUlJfTk9UX1NVUFBPUlRFRC4g SSdtIG5vdCBzdXJlIGd1ZXN0cyB3b3VsZAo+ID4gaW50ZXJwcmV0IG5vdC1zdXBwb3J0ZWQgYXMg YW4gZXJyb3Igd2hpY2ggbWVhbnMgdGhleSBjYW4gcmV0cnkuIE9yIGlmCj4gPiB0aGV5IHJldHJ5 IGFuZCBnZXQgc29tZXRoaW5nIG90aGVyIHRoYW4gbm90LXN1cHBvcnRlZCBpZiB0aGV5J2QgYmUK PiA+IGNvbmZ1c2VkLgo+ID4gCj4gCj4gQXQgbGVhc3QgaW4gTGludXggZHJpdmVyLCB0cmVhdHMg LUVOT1RTVVBQIGFuZCBpdCBqdXN0IGZhaWxzLiBPdGhlciBndWVzdCBPUwo+IGltcGxlbWVudGF0 aW9uIG1heSBpbnRlcnByZXQgaXQgZGlmZmVyZW50bHkuIEJ1dCB0aGV5IHNob3VsZCBmYWlsIGF0 IHRoYXQKPiBwb2ludCBhcyB3ZWxsLiBJIGRvbid0IHNlZSBob3cgY2FuIHRoZXkgaW50ZXJwcmV0 IHRvIGJlIHJldHJ5Lgo+IAo+IFRoZSBwZXJmIHVzZXIgY2FuIHJldHJ5IGFnYWluIHdpdGggYXNz dW1wdGlvbiB0aGF0IG1heSBiZSBlbm91Z2ggY291bnRlcnMKPiBhcmUgbm90IGF2YWlsYWJsZSBh dCB0aGlzIG1vbWVudC4gQnV0IHRoYXQncyBkaWZmZXJlbnQgZnJvbSByZXR1cm4gYSByZXRyeQo+ IGZyb20gZHJpdmVyIGNvZGUuCj4gCj4gRXZlbiBpZiB3ZSBzdXBwb3J0IGEgcmV0cnkgZXJyb3Ig Y29kZSwgd2hlbiBkb2VzIHRoZSBjYWxsZXIgcmV0cnkgaXQgPwo+IFRoZSBkcml2ZXIgZG9lc24n dCBrbm93IGhvdyBsb25nIHRoZSB1c2VyIGlzIGdvaW5nIHRvIHJ1biB0aGUgcGVyZiBjb21tYW5k Cj4gdG8ga2VlcCB0aGUgaGFyZHdhcmUgcmVzb3VyY2VzIG9jY3VwaWVkLgo+IAo+IEkgZmVlbCB0 aGUgcGVyZiB1c2VyIGlzIHRoZSBiZXN0IGVudGl0eSB0byBrbm93IHRoYXQgYW5kIHNob3VsZCBy ZXRyeSBpZiBpdAo+IGtub3dzIHRoZSBwcmV2aW91cyBydW4gaXMgb3ZlciB3aGljaCBtaWdodCBo YXZlIHJlbGVhc2VkIHRoZSBoYXJkd2FyZQo+IHJlc291cmNlcy4KCkkgYWdyZWUsIGJ1dCBob3cg ZG9lcyB0aGUgdXNlciBrbm93IHRoYXQgcmV0cnlpbmcgbWFrZXMgc2Vuc2U/IEkgcHJlc3VtZQot RU5PVFNVUFAgd2lsbCBnZXQgcHJvcGFnYXRlZCBhbGwgdGhlIHdheSB0byB0aGUgdXNlciBpbiBh IGZvcm0gdGhhdAptZWFucyAibm90IHN1cHBvcnRlZCIuIE9yLCBjYW4gdGhlIHVzZXIgbGlzdCBh bGwgcmVzb3VyY2VzIGFuZCB0aGVuCndoZW4gdGhleSBzZWUgIm5vdCBzdXBwb3J0ZWQiIGtub3cg dGhhdCBtZWFucyAibm90IHN1cHBvcnRlZCBhdCB0aGUKbW9tZW50IiwgYXMgdGhleSd2ZSBhbHJl YWR5IHNlZW4gdGhhdCB0aGUgcmVzb3VyY2VzIGV4aXN0PwoKQW55d2F5LCBhcyBJIHNhaWQsIEkg ZG9uJ3Qga25vdyBlbm91Z2ggYWJvdXQgdGhlIHBlcmYgc3Vic3lzdGVtIHRvIGtub3cKaWYgdGhp cyBpcyBhIHJlYWwgY29uY2VybiBvciBub3QsIGJ1dCBpdCBzb3J0IG9mIGxvb2tzIGxpa2Ugd2Ug aGF2ZQpwb3RlbnRpYWwgdG8gdGVsbCB1c2VycyB0aGF0IHNvbWV0aGluZyBpc24ndCBzdXBwb3J0 ZWQgd2hlbiBpbiBmYWN0IGl0CmlzIHN1cHBvcnRlZCwgYnV0IG9ubHkgdGVtcG9yYXJpbHkgdW5h dmFpbGFibGUuCgpUaGFua3MsCmRyZXcKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCmxpbnV4LXJpc2N2IG1haWxpbmcgbGlzdApsaW51eC1yaXNjdkBsaXN0 cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGlu Zm8vbGludXgtcmlzY3YK