From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-192.mta0.migadu.com (out-192.mta0.migadu.com [91.218.175.192]) (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 AA5FF946E for ; Tue, 17 Oct 2023 05:52:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="OdmnPA8A" Date: Tue, 17 Oct 2023 05:52:24 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1697521950; 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=fVj3QOXnTr/Xh7eUU3olV979cXmOJTmj7/jYZIF4yF4=; b=OdmnPA8A+91moypBiaGZn8ibVGmZmN0HlfkfnzmzJQJBXglPtzHGRWJlvkfP5NADESecPn LfHytZzAvYtJ/AuWS3MjDUzpoPd1KHYxGwXalx8C92EpY8eHM4WMityUHrBuqJvQO9N3Y6 ePHgtv1NQGXK0zyXqDl1SenjwijfMhQ= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Raghavendra Rao Ananta Cc: Sebastian Ott , Marc Zyngier , Alexandru Elisei , James Morse , Suzuki K Poulose , Paolo Bonzini , Zenghui Yu , Shaoqin Huang , 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 v7 07/12] KVM: arm64: PMU: Set PMCR_EL0.N for vCPU based on the associated PMU Message-ID: References: <20231009230858.3444834-1-rananta@google.com> <20231009230858.3444834-8-rananta@google.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 Mon, Oct 16, 2023 at 02:35:52PM -0700, Raghavendra Rao Ananta wrote: [...] > > What's the point of doing this in the first place? The implementation of > > kvm_vcpu_read_pmcr() is populating PMCR_EL0.N using the VM-scoped value. > > > I guess originally the change replaced read_sysreg(pmcr_el0) with > kvm_vcpu_read_pmcr(vcpu) to maintain consistency with others. > But if you and Sebastian feel that it's an overkill and directly > getting the value via vcpu->kvm->arch.pmcr_n is more readable, I'm > happy to make the change. No, I'd rather you delete the line where PMCR_EL0.N altogether. reset_pmcr() tries to initialize the field, but your kvm_vcpu_read_pmcr() winds up replacing it with pmcr_n. > @@ -1105,8 +1109,16 @@ u8 kvm_arm_pmu_get_pmuver_limit(void) > /** > * kvm_vcpu_read_pmcr - Read PMCR_EL0 register for the vCPU > * @vcpu: The vcpu pointer > + * > + * The function returns the value of PMCR.N based on the per-VM tracked > + * value (kvm->arch.pmcr_n). This is to ensure that the register field > + * remains consistent for the VM, even on heterogeneous systems where > + * the value may vary when read from different CPUs (during vCPU reset). Since I'm looking at this again, I don't believe the comment is adding much. KVM doesn't read pmcr_el0 directly anymore, and kvm_arch is clearly VM-scoped context. > */ > u64 kvm_vcpu_read_pmcr(struct kvm_vcpu *vcpu) > { > - return __vcpu_sys_reg(vcpu, PMCR_EL0); > + u64 pmcr = __vcpu_sys_reg(vcpu, PMCR_EL0) & > + ~(ARMV8_PMU_PMCR_N_MASK << ARMV8_PMU_PMCR_N_SHIFT); > + > + return pmcr | ((u64)vcpu->kvm->arch.pmcr_n << ARMV8_PMU_PMCR_N_SHIFT); > } -- 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 04A6DCDB482 for ; Tue, 17 Oct 2023 05:53:06 +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=3SMCP0T2HkpnaIhyD1JZvJ8UClxM+acl9UyGKxbPDcM=; b=knMcWj6V4AQ4k+ WTqULNhG4IkiC41F1bcKEoNfA5Zzb7wv6AZb+6lylDKm3WWeJWyu+KsLDG0cLK3h610D0jQs9mHdM G+gleRG9CrFIDGOeEtdQnAhjRdc3U+85hGxN538KVg4mwu8lxKIbEMW4T6KEC6MwnbUaIj3nXWHVf T5J9iGez3oMC2ggcFUnU5v4hid2c1UIg37PeGYnjo8GGtqcWGQ/evIFa2BzZesGtwmiDdEojnSbmA u7uus/eAg0mSSjirE5flZK9BJBu0VWdv2CKqMPjBaFXTYY2yAsxlSqih9TMt3MjLgEkxc8eceN/tc QOMUnWRxtjdRFvT239wQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qsd0R-00BKHm-0E; Tue, 17 Oct 2023 05:52:39 +0000 Received: from out-198.mta0.migadu.com ([2001:41d0:1004:224b::c6]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qsd0N-00BKF9-1t for linux-arm-kernel@lists.infradead.org; Tue, 17 Oct 2023 05:52:37 +0000 Date: Tue, 17 Oct 2023 05:52:24 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1697521950; 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=fVj3QOXnTr/Xh7eUU3olV979cXmOJTmj7/jYZIF4yF4=; b=OdmnPA8A+91moypBiaGZn8ibVGmZmN0HlfkfnzmzJQJBXglPtzHGRWJlvkfP5NADESecPn LfHytZzAvYtJ/AuWS3MjDUzpoPd1KHYxGwXalx8C92EpY8eHM4WMityUHrBuqJvQO9N3Y6 ePHgtv1NQGXK0zyXqDl1SenjwijfMhQ= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Raghavendra Rao Ananta Cc: Sebastian Ott , Marc Zyngier , Alexandru Elisei , James Morse , Suzuki K Poulose , Paolo Bonzini , Zenghui Yu , Shaoqin Huang , 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 v7 07/12] KVM: arm64: PMU: Set PMCR_EL0.N for vCPU based on the associated PMU Message-ID: References: <20231009230858.3444834-1-rananta@google.com> <20231009230858.3444834-8-rananta@google.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-20231016_225235_774748_4DDC956B X-CRM114-Status: GOOD ( 16.82 ) 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 Mon, Oct 16, 2023 at 02:35:52PM -0700, Raghavendra Rao Ananta wrote: [...] > > What's the point of doing this in the first place? The implementation of > > kvm_vcpu_read_pmcr() is populating PMCR_EL0.N using the VM-scoped value. > > > I guess originally the change replaced read_sysreg(pmcr_el0) with > kvm_vcpu_read_pmcr(vcpu) to maintain consistency with others. > But if you and Sebastian feel that it's an overkill and directly > getting the value via vcpu->kvm->arch.pmcr_n is more readable, I'm > happy to make the change. No, I'd rather you delete the line where PMCR_EL0.N altogether. reset_pmcr() tries to initialize the field, but your kvm_vcpu_read_pmcr() winds up replacing it with pmcr_n. > @@ -1105,8 +1109,16 @@ u8 kvm_arm_pmu_get_pmuver_limit(void) > /** > * kvm_vcpu_read_pmcr - Read PMCR_EL0 register for the vCPU > * @vcpu: The vcpu pointer > + * > + * The function returns the value of PMCR.N based on the per-VM tracked > + * value (kvm->arch.pmcr_n). This is to ensure that the register field > + * remains consistent for the VM, even on heterogeneous systems where > + * the value may vary when read from different CPUs (during vCPU reset). Since I'm looking at this again, I don't believe the comment is adding much. KVM doesn't read pmcr_el0 directly anymore, and kvm_arch is clearly VM-scoped context. > */ > u64 kvm_vcpu_read_pmcr(struct kvm_vcpu *vcpu) > { > - return __vcpu_sys_reg(vcpu, PMCR_EL0); > + u64 pmcr = __vcpu_sys_reg(vcpu, PMCR_EL0) & > + ~(ARMV8_PMU_PMCR_N_MASK << ARMV8_PMU_PMCR_N_SHIFT); > + > + return pmcr | ((u64)vcpu->kvm->arch.pmcr_n << ARMV8_PMU_PMCR_N_SHIFT); > } -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel