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 27AB6C433EF for ; Wed, 1 Dec 2021 15:54:45 +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=t2/nIsWx96L28djPeecYAodTM9tgDeBau4zM99q80pA=; b=QDk0SxK64X5BBg LVcaZqciMgjkEuJ255kbamamFBUozi1iPM+qBDEpVWLwojXiAbbb+iO+5JodLZS3I7K8I/tfeGBsG bBZnKyj1EwmujsqevuHAUCGM9tYB+2BV7MuiwluSZSxyuRz1MN8DgUiT/qxRq4Zcct4iHmLPu/jwx kEnZtRZeKRB1X2QV3sznwf+f7KcFfhQt2yEFa6JfnDml0MAvF6VCZRtzwv1F6eylI+6eMEDBDvU4c SfYKrF32CdClnukdBgisN4Mh28DtCQCLvDknAEJrPpu13G8Y8OrTyKNK+rAQ8A0TTkou0kCbVM4t7 qsJeuCHK1MqqKC2lmt+Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1msRvD-009Gjl-6M; Wed, 01 Dec 2021 15:53:27 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1msRv9-009Gin-KO for linux-arm-kernel@lists.infradead.org; Wed, 01 Dec 2021 15:53:25 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8E489143B; Wed, 1 Dec 2021 07:53:22 -0800 (PST) Received: from monolith.localdoman (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9CDF13F766; Wed, 1 Dec 2021 07:53:20 -0800 (PST) Date: Wed, 1 Dec 2021 15:53:18 +0000 From: Alexandru Elisei To: Reiji Watanabe Cc: Eric Auger , Marc Zyngier , kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Will Deacon , Peter Shier , Paolo Bonzini , linux-arm-kernel@lists.infradead.org Subject: Re: [RFC PATCH v3 09/29] KVM: arm64: Hide IMPLEMENTATION DEFINED PMU support for the guest Message-ID: References: <20211117064359.2362060-1-reijiw@google.com> <20211117064359.2362060-10-reijiw@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211201_075323_739919_8AA0CB18 X-CRM114-Status: GOOD ( 30.34 ) 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 Hi Reiji, On Mon, Nov 29, 2021 at 09:32:02PM -0800, Reiji Watanabe wrote: > Hi Eric, > > On Thu, Nov 25, 2021 at 12:30 PM Eric Auger wrote: > > > > Hi Reiji, > > > > On 11/17/21 7:43 AM, Reiji Watanabe wrote: > > > When ID_AA64DFR0_EL1.PMUVER or ID_DFR0_EL1.PERFMON is 0xf, which > > > means IMPLEMENTATION DEFINED PMU supported, KVM unconditionally > > > expose the value for the guest as it is. Since KVM doesn't support > > > IMPLEMENTATION DEFINED PMU for the guest, in that case KVM should > > > exopse 0x0 (PMU is not implemented) instead. > > s/exopse/expose > > > > > > Change cpuid_feature_cap_perfmon_field() to update the field value > > > to 0x0 when it is 0xf. > > is it wrong to expose the guest with a Perfmon value of 0xF? Then the > > guest should not use it as a PMUv3? > > > is it wrong to expose the guest with a Perfmon value of 0xF? Then the > > guest should not use it as a PMUv3? > > For the value 0xf in ID_AA64DFR0_EL1.PMUVER and ID_DFR0_EL1.PERFMON, > Arm ARM says: > "IMPLEMENTATION DEFINED form of performance monitors supported, > PMUv3 not supported." > > Since the PMU that KVM supports for guests is PMUv3, 0xf shouldn't > be exposed to guests (And this patch series doesn't allow userspace > to set the fields to 0xf for guests). While it's true that a value of 0xf means that PMUv3 is not present (both KVM and the PMU driver handle it this way) this is an userspace visible change. Are you sure there isn't software in the wild that relies on this value being 0xf to detect that some non-Arm architected hardware is present? Since both 0 and 0xf are valid values that mean that PMUv3 is not present, I think it's best that both are kept. Thanks, Alex > > Thanks, > Reiji > > > > > Eric > > > > > > Fixes: 8e35aa642ee4 ("arm64: cpufeature: Extract capped perfmon fields") > > > Signed-off-by: Reiji Watanabe > > > --- > > > arch/arm64/include/asm/cpufeature.h | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h > > > index ef6be92b1921..fd7ad8193827 100644 > > > --- a/arch/arm64/include/asm/cpufeature.h > > > +++ b/arch/arm64/include/asm/cpufeature.h > > > @@ -553,7 +553,7 @@ cpuid_feature_cap_perfmon_field(u64 features, int field, u64 cap) > > > > > > /* Treat IMPLEMENTATION DEFINED functionality as unimplemented */ > > > if (val == ID_AA64DFR0_PMUVER_IMP_DEF) > > > - val = 0; > > > + return (features & ~mask); > > > > > > if (val > cap) { > > > features &= ~mask; > > > > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel