From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-213.mta1.migadu.com (out-213.mta1.migadu.com [95.215.58.213]) (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 D4BD4101C6 for ; Fri, 15 Sep 2023 20:36:16 +0000 (UTC) Date: Fri, 15 Sep 2023 20:36:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1694810174; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Jh8wxRtaCDmNfJKXz9NRQ7CZIQMzCI29C3PoTr8TsLs=; b=v0fuP40FaFR3ghn7RXIwy67Q0K0A9PV4x7M7qmiJj74u7uqOJcrmJy/NRsbpejjUsPsPU4 o8NKRojsEw1KDsPIIQzBTZ71ljSVKKl4nchWZXeaA7gfwOJFxk7ZY/eqk94xQwimORQ6yv FbOt19DOumNoGkOOaXU99v5XYPYZOhU= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Shaoqin Huang Cc: Raghavendra Rao Ananta , Marc Zyngier , Alexandru Elisei , James Morse , Suzuki K Poulose , Paolo Bonzini , Zenghui Yu , Jing Zhang , Reiji Watanabe , Colton Lewis , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: Re: [PATCH v5 08/12] KVM: arm64: PMU: Allow userspace to limit PMCR_EL0.N for the guest Message-ID: References: <20230817003029.3073210-1-rananta@google.com> <20230817003029.3073210-9-rananta@google.com> <6dc460d2-c7fb-e299-b0a3-55b43de31555@redhat.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=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT On Tue, Aug 22, 2023 at 11:26:23AM +0800, Shaoqin Huang wrote: [...] > > > > +static int set_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r, > > > > + u64 val) > > > > +{ > > > > + struct kvm *kvm = vcpu->kvm; > > > > + u64 new_n, mutable_mask; > > > > + int ret = 0; > > > > + > > > > + new_n = FIELD_GET(ARMV8_PMU_PMCR_N, val); > > > > + > > > > + mutex_lock(&kvm->arch.config_lock); > > > > + if (unlikely(new_n != kvm->arch.pmcr_n)) { > > > > + /* > > > > + * The vCPU can't have more counters than the PMU > > > > + * hardware implements. > > > > + */ > > > > + if (new_n <= kvm->arch.pmcr_n_limit) > > > > + kvm->arch.pmcr_n = new_n; > > > > + else > > > > + ret = -EINVAL; > > > > + } > > > > > > Since we have set the default value of pmcr_n, if we want to set a new > > > pmcr_n, shouldn't it be a different value? > > > > > > So how about change the checking to: > > > > > > if (likely(new_n <= kvm->arch.pmcr_n_limit) > > > kvm->arch.pmcr_n = new_n; > > > else > > > ret = -EINVAL; > > > > > > what do you think? > > > > > Sorry, I guess I didn't fully understand your suggestion. Are you > > saying that it's 'likely' that userspace would configure the correct > > value? > > > It depends on how userspace use this api to limit the number of pmcr. I > think what you mean in the code is that userspace need to set every vcpu's > pmcr to the same value, so the `unlikely` here is right, only one vcpu can > change the kvm->arch.pmcr.n, it saves the cpu cycles. > > What suggest above might be wrong. Since I think when userspace want to > limit the number of pmcr, it may just set the new_n on one vcpu, since the > kvm->arch.pmcr_n is a VM-local value, every vcpu can see it, so it's > `likely` the (new_n <= kvm->arch.pmcr_n_limit), it can decrease one checking > statement. How about we just do away with branch hints in the first place? This is _not_ a hot path. -- Thanks, Oliver 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 43977CD37AC for ; Fri, 15 Sep 2023 20:37:00 +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=lDeX+TgVxuyhyXBB+NCeNWyHxHXhse9vBtzSykQwLVI=; b=MwugUlAieAFu87 57ipyFCyUVApuSQY2nvT5wv1VeZndbTKu8lD9HWzRT3djYNOaOGONCQVsMqbWVpQRPgOCAsDf/AoW qntc7GmYBAMTyLFN2OvFbEYLNV7E20QT8mYfdv8gIlSI3hAZ9NslZWddHNbljp/j2oDIR/sQpYBLu JKd385AZxQ0vNojZK9zakMGCOG1QUTJeqnH99z8xSXzJh6ifO9OwEZRfxQxfZ7yifXQAr1UKSPv0R ZAowx1aKp55M5M5mz3VbNiIkBPnG5sgR8PILP720r84fLVkeD9J46Nq+Suq8Gv9wO1kMkDK7a8Vmp lr5RjocQeGAVUm7m6i8g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qhFYB-00BL6Z-2c; Fri, 15 Sep 2023 20:36:27 +0000 Received: from out-210.mta1.migadu.com ([95.215.58.210]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qhFY2-00BL5x-00 for linux-arm-kernel@lists.infradead.org; Fri, 15 Sep 2023 20:36:23 +0000 Date: Fri, 15 Sep 2023 20:36:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1694810174; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Jh8wxRtaCDmNfJKXz9NRQ7CZIQMzCI29C3PoTr8TsLs=; b=v0fuP40FaFR3ghn7RXIwy67Q0K0A9PV4x7M7qmiJj74u7uqOJcrmJy/NRsbpejjUsPsPU4 o8NKRojsEw1KDsPIIQzBTZ71ljSVKKl4nchWZXeaA7gfwOJFxk7ZY/eqk94xQwimORQ6yv FbOt19DOumNoGkOOaXU99v5XYPYZOhU= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Shaoqin Huang Cc: Raghavendra Rao Ananta , Marc Zyngier , Alexandru Elisei , James Morse , Suzuki K Poulose , Paolo Bonzini , Zenghui Yu , Jing Zhang , Reiji Watanabe , Colton Lewis , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: Re: [PATCH v5 08/12] KVM: arm64: PMU: Allow userspace to limit PMCR_EL0.N for the guest Message-ID: References: <20230817003029.3073210-1-rananta@google.com> <20230817003029.3073210-9-rananta@google.com> <6dc460d2-c7fb-e299-b0a3-55b43de31555@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230915_133622_293535_96DE85E7 X-CRM114-Status: GOOD ( 24.47 ) 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="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Aug 22, 2023 at 11:26:23AM +0800, Shaoqin Huang wrote: [...] > > > > +static int set_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r, > > > > + u64 val) > > > > +{ > > > > + struct kvm *kvm = vcpu->kvm; > > > > + u64 new_n, mutable_mask; > > > > + int ret = 0; > > > > + > > > > + new_n = FIELD_GET(ARMV8_PMU_PMCR_N, val); > > > > + > > > > + mutex_lock(&kvm->arch.config_lock); > > > > + if (unlikely(new_n != kvm->arch.pmcr_n)) { > > > > + /* > > > > + * The vCPU can't have more counters than the PMU > > > > + * hardware implements. > > > > + */ > > > > + if (new_n <= kvm->arch.pmcr_n_limit) > > > > + kvm->arch.pmcr_n = new_n; > > > > + else > > > > + ret = -EINVAL; > > > > + } > > > > > > Since we have set the default value of pmcr_n, if we want to set a new > > > pmcr_n, shouldn't it be a different value? > > > > > > So how about change the checking to: > > > > > > if (likely(new_n <= kvm->arch.pmcr_n_limit) > > > kvm->arch.pmcr_n = new_n; > > > else > > > ret = -EINVAL; > > > > > > what do you think? > > > > > Sorry, I guess I didn't fully understand your suggestion. Are you > > saying that it's 'likely' that userspace would configure the correct > > value? > > > It depends on how userspace use this api to limit the number of pmcr. I > think what you mean in the code is that userspace need to set every vcpu's > pmcr to the same value, so the `unlikely` here is right, only one vcpu can > change the kvm->arch.pmcr.n, it saves the cpu cycles. > > What suggest above might be wrong. Since I think when userspace want to > limit the number of pmcr, it may just set the new_n on one vcpu, since the > kvm->arch.pmcr_n is a VM-local value, every vcpu can see it, so it's > `likely` the (new_n <= kvm->arch.pmcr_n_limit), it can decrease one checking > statement. How about we just do away with branch hints in the first place? This is _not_ a hot path. -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel