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 mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id E6707C433FE for ; Thu, 3 Nov 2022 10:25:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 4CC284B25A; Thu, 3 Nov 2022 06:25:14 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@kernel.org Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRXSZ0QXJ2aD; Thu, 3 Nov 2022 06:25:13 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 367274B636; Thu, 3 Nov 2022 06:25:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id B95194B25A for ; Thu, 3 Nov 2022 06:25:12 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKhw1ZrOJyRx for ; Thu, 3 Nov 2022 06:25:09 -0400 (EDT) Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id CEB5E4B71F for ; Thu, 3 Nov 2022 06:25:08 -0400 (EDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 5E30AB826A8; Thu, 3 Nov 2022 10:25:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0722BC433D7; Thu, 3 Nov 2022 10:25:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1667471106; bh=1WjLvryUdEjCQvaGHVT4ulj0LOaBupI7N5OU9BiVl5w=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=MF+ZKTQo493m4vReC6RjdsC4JAi2ZaqHn73bOyvEx+WIcIGg+3Xd3iyEQYzVtzHKy oVi6wgoi1cjocgXOlvZe9Nbuk88wrlqofN3qL5qWkmi9ilCzWDiMeRXEbkCRWITxBD Wb24a7y/dgLeK34nevpfsa4JfAHkUI0OihIHk1wmu5PZWN3KXGwP2RR46cNka58BDD FF2IuFj1rXpsn0Y7ZK576xDKTK86az/4DotWOp5vSeJ4r37RxIk0zjMvCXistMRjnA WvGx+bpSvjFpYfO4b5PxV98bnHYGd/vqYpbjo7KT3e3kGkhkZ3xpvGc8pseTv+zER9 WDCoakY1H7PBg== Received: from [104.132.45.97] (helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1oqXPD-003TRe-JS; Thu, 03 Nov 2022 10:25:03 +0000 Date: Thu, 03 Nov 2022 10:24:33 +0000 Message-ID: <87tu3gfi8u.wl-maz@kernel.org> From: Marc Zyngier To: Reiji Watanabe Subject: Re: [PATCH v2 11/14] KVM: arm64: PMU: Allow ID_AA64DFR0_EL1.PMUver to be set from userspace In-Reply-To: References: <20221028105402.2030192-1-maz@kernel.org> <20221028105402.2030192-12-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 104.132.45.97 X-SA-Exim-Rcpt-To: reijiw@google.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvmarm@lists.linux.dev, kvm@vger.kernel.org, james.morse@arm.com, suzuki.poulose@arm.com, alexandru.elisei@arm.com, oliver.upton@linux.dev, ricarkol@google.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Cc: kvm@vger.kernel.org, kvmarm@lists.linux.dev, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Thu, 03 Nov 2022 05:31:56 +0000, Reiji Watanabe wrote: > > Hi Marc, > > On Fri, Oct 28, 2022 at 4:16 AM Marc Zyngier wrote: > > > > Allow userspace to write ID_AA64DFR0_EL1, on the condition that only > > the PMUver field can be altered and be at most the one that was > > initially computed for the guest. > > > > Signed-off-by: Marc Zyngier > > --- > > arch/arm64/kvm/sys_regs.c | 37 ++++++++++++++++++++++++++++++++++++- > > 1 file changed, 36 insertions(+), 1 deletion(-) > > > > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > > index 7a4cd644b9c0..4fa14b4ae2a6 100644 > > --- a/arch/arm64/kvm/sys_regs.c > > +++ b/arch/arm64/kvm/sys_regs.c > > @@ -1247,6 +1247,40 @@ static int set_id_aa64pfr0_el1(struct kvm_vcpu *vcpu, > > return 0; > > } > > > > +static int set_id_aa64dfr0_el1(struct kvm_vcpu *vcpu, > > + const struct sys_reg_desc *rd, > > + u64 val) > > +{ > > + u8 pmuver, host_pmuver; > > + > > + host_pmuver = kvm_arm_pmu_get_pmuver_limit(); > > + > > + /* > > + * Allow AA64DFR0_EL1.PMUver to be set from userspace as long > > + * as it doesn't promise more than what the HW gives us. We > > + * allow an IMPDEF PMU though, only if no PMU is supported > > + * (KVM backward compatibility handling). > > + */ > > It appears the patch allows userspace to set IMPDEF even > when host_pmuver == 0. Shouldn't it be allowed only when > host_pmuver == IMPDEF (as before)? > Probably, it may not cause any real problems though. Given that we don't treat the two cases any differently, I thought it would be reasonable to relax this particular case, and I can't see any reason why we shouldn't tolerate this sort of migration. > > > > + pmuver = FIELD_GET(ARM64_FEATURE_MASK(ID_AA64DFR0_EL1_PMUVer), val); > > + if (pmuver != ID_AA64DFR0_EL1_PMUVer_IMP_DEF && pmuver > host_pmuver) > > + return -EINVAL; > > + > > + /* We already have a PMU, don't try to disable it... */ > > + if (kvm_vcpu_has_pmu(vcpu) && > > + (pmuver == 0 || pmuver == ID_AA64DFR0_EL1_PMUVer_IMP_DEF)) > > + return -EINVAL; > > Nit: Perhaps it might be useful to return a different error code for the > above two (new) error cases (I plan to use -E2BIG and -EPERM > respectively for those cases with my ID register series). My worry in doing so is that we don't have an established practice for these cases. I'm fine with introducing new error codes, but I'm not sure there is an existing practice in userspace to actually interpret them. Even -EPERM has a slightly different meaning, and although there is some language there saying that it is all nonsense, we should be very careful. Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 6054023B1 for ; Thu, 3 Nov 2022 10:25:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0722BC433D7; Thu, 3 Nov 2022 10:25:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1667471106; bh=1WjLvryUdEjCQvaGHVT4ulj0LOaBupI7N5OU9BiVl5w=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=MF+ZKTQo493m4vReC6RjdsC4JAi2ZaqHn73bOyvEx+WIcIGg+3Xd3iyEQYzVtzHKy oVi6wgoi1cjocgXOlvZe9Nbuk88wrlqofN3qL5qWkmi9ilCzWDiMeRXEbkCRWITxBD Wb24a7y/dgLeK34nevpfsa4JfAHkUI0OihIHk1wmu5PZWN3KXGwP2RR46cNka58BDD FF2IuFj1rXpsn0Y7ZK576xDKTK86az/4DotWOp5vSeJ4r37RxIk0zjMvCXistMRjnA WvGx+bpSvjFpYfO4b5PxV98bnHYGd/vqYpbjo7KT3e3kGkhkZ3xpvGc8pseTv+zER9 WDCoakY1H7PBg== Received: from [104.132.45.97] (helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1oqXPD-003TRe-JS; Thu, 03 Nov 2022 10:25:03 +0000 Date: Thu, 03 Nov 2022 10:24:33 +0000 Message-ID: <87tu3gfi8u.wl-maz@kernel.org> From: Marc Zyngier To: Reiji Watanabe Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvmarm@lists.linux.dev, kvm@vger.kernel.org, James Morse , Suzuki K Poulose , Alexandru Elisei , Oliver Upton , Ricardo Koller Subject: Re: [PATCH v2 11/14] KVM: arm64: PMU: Allow ID_AA64DFR0_EL1.PMUver to be set from userspace In-Reply-To: References: <20221028105402.2030192-1-maz@kernel.org> <20221028105402.2030192-12-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 104.132.45.97 X-SA-Exim-Rcpt-To: reijiw@google.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvmarm@lists.linux.dev, kvm@vger.kernel.org, james.morse@arm.com, suzuki.poulose@arm.com, alexandru.elisei@arm.com, oliver.upton@linux.dev, ricarkol@google.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Message-ID: <20221103102433.14h0-gKSmr4gRfOG_9uzQAMR-qpSdpECfcsCQNpBUUM@z> On Thu, 03 Nov 2022 05:31:56 +0000, Reiji Watanabe wrote: > > Hi Marc, > > On Fri, Oct 28, 2022 at 4:16 AM Marc Zyngier wrote: > > > > Allow userspace to write ID_AA64DFR0_EL1, on the condition that only > > the PMUver field can be altered and be at most the one that was > > initially computed for the guest. > > > > Signed-off-by: Marc Zyngier > > --- > > arch/arm64/kvm/sys_regs.c | 37 ++++++++++++++++++++++++++++++++++++- > > 1 file changed, 36 insertions(+), 1 deletion(-) > > > > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > > index 7a4cd644b9c0..4fa14b4ae2a6 100644 > > --- a/arch/arm64/kvm/sys_regs.c > > +++ b/arch/arm64/kvm/sys_regs.c > > @@ -1247,6 +1247,40 @@ static int set_id_aa64pfr0_el1(struct kvm_vcpu *vcpu, > > return 0; > > } > > > > +static int set_id_aa64dfr0_el1(struct kvm_vcpu *vcpu, > > + const struct sys_reg_desc *rd, > > + u64 val) > > +{ > > + u8 pmuver, host_pmuver; > > + > > + host_pmuver = kvm_arm_pmu_get_pmuver_limit(); > > + > > + /* > > + * Allow AA64DFR0_EL1.PMUver to be set from userspace as long > > + * as it doesn't promise more than what the HW gives us. We > > + * allow an IMPDEF PMU though, only if no PMU is supported > > + * (KVM backward compatibility handling). > > + */ > > It appears the patch allows userspace to set IMPDEF even > when host_pmuver == 0. Shouldn't it be allowed only when > host_pmuver == IMPDEF (as before)? > Probably, it may not cause any real problems though. Given that we don't treat the two cases any differently, I thought it would be reasonable to relax this particular case, and I can't see any reason why we shouldn't tolerate this sort of migration. > > > > + pmuver = FIELD_GET(ARM64_FEATURE_MASK(ID_AA64DFR0_EL1_PMUVer), val); > > + if (pmuver != ID_AA64DFR0_EL1_PMUVer_IMP_DEF && pmuver > host_pmuver) > > + return -EINVAL; > > + > > + /* We already have a PMU, don't try to disable it... */ > > + if (kvm_vcpu_has_pmu(vcpu) && > > + (pmuver == 0 || pmuver == ID_AA64DFR0_EL1_PMUVer_IMP_DEF)) > > + return -EINVAL; > > Nit: Perhaps it might be useful to return a different error code for the > above two (new) error cases (I plan to use -E2BIG and -EPERM > respectively for those cases with my ID register series). My worry in doing so is that we don't have an established practice for these cases. I'm fine with introducing new error codes, but I'm not sure there is an existing practice in userspace to actually interpret them. Even -EPERM has a slightly different meaning, and although there is some language there saying that it is all nonsense, we should be very careful. Thanks, M. -- Without deviation from the norm, progress is not possible. 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 0F554C4332F for ; Thu, 3 Nov 2022 10:26:10 +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:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=xz9rGi0O9PusWUdm5ri6ZAHYJpvgm8G0WCTUgNGxW28=; b=B+NkSDxBP3JSu6 aNsmOG0svKHUlJYCJs0Rtxwv1mF6FeQkGEuCxIbejlXMHFEpnNUlxPjj1EQjWWmkW3Cbq/rcyaTZx I6E+wN1P01g/HVfhTferWsKDQAY0KfIEk2XhReCYl6OFv+/dj0R82Rbc8D5MyMwXJxL4Ye8t0jYew KbBVkJA5bWy9uaIcnndff/xNEcFX3IGiQdcQG4DBXp8YmCkQ/muQJwErm+jlpO+WNBrTHe//4cIuv GHnRKSnI5iC0XK13sbrQJHpdFidiX7ls+S/eLtQBIcDgXAQ7y3pn8oSk6lOKWrJpVzox1krZboBDi kcanKIAIM6lUwWEIyrlA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oqXPL-00H4yA-8p; Thu, 03 Nov 2022 10:25:11 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oqXPI-00H4xC-SX for linux-arm-kernel@lists.infradead.org; Thu, 03 Nov 2022 10:25:10 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 5E30AB826A8; Thu, 3 Nov 2022 10:25:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0722BC433D7; Thu, 3 Nov 2022 10:25:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1667471106; bh=1WjLvryUdEjCQvaGHVT4ulj0LOaBupI7N5OU9BiVl5w=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=MF+ZKTQo493m4vReC6RjdsC4JAi2ZaqHn73bOyvEx+WIcIGg+3Xd3iyEQYzVtzHKy oVi6wgoi1cjocgXOlvZe9Nbuk88wrlqofN3qL5qWkmi9ilCzWDiMeRXEbkCRWITxBD Wb24a7y/dgLeK34nevpfsa4JfAHkUI0OihIHk1wmu5PZWN3KXGwP2RR46cNka58BDD FF2IuFj1rXpsn0Y7ZK576xDKTK86az/4DotWOp5vSeJ4r37RxIk0zjMvCXistMRjnA WvGx+bpSvjFpYfO4b5PxV98bnHYGd/vqYpbjo7KT3e3kGkhkZ3xpvGc8pseTv+zER9 WDCoakY1H7PBg== Received: from [104.132.45.97] (helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1oqXPD-003TRe-JS; Thu, 03 Nov 2022 10:25:03 +0000 Date: Thu, 03 Nov 2022 10:24:33 +0000 Message-ID: <87tu3gfi8u.wl-maz@kernel.org> From: Marc Zyngier To: Reiji Watanabe Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvmarm@lists.linux.dev, kvm@vger.kernel.org, James Morse , Suzuki K Poulose , Alexandru Elisei , Oliver Upton , Ricardo Koller Subject: Re: [PATCH v2 11/14] KVM: arm64: PMU: Allow ID_AA64DFR0_EL1.PMUver to be set from userspace In-Reply-To: References: <20221028105402.2030192-1-maz@kernel.org> <20221028105402.2030192-12-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 104.132.45.97 X-SA-Exim-Rcpt-To: reijiw@google.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvmarm@lists.linux.dev, kvm@vger.kernel.org, james.morse@arm.com, suzuki.poulose@arm.com, alexandru.elisei@arm.com, oliver.upton@linux.dev, ricarkol@google.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221103_032509_228407_6CEED7FD X-CRM114-Status: GOOD ( 37.38 ) 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 Thu, 03 Nov 2022 05:31:56 +0000, Reiji Watanabe wrote: > > Hi Marc, > > On Fri, Oct 28, 2022 at 4:16 AM Marc Zyngier wrote: > > > > Allow userspace to write ID_AA64DFR0_EL1, on the condition that only > > the PMUver field can be altered and be at most the one that was > > initially computed for the guest. > > > > Signed-off-by: Marc Zyngier > > --- > > arch/arm64/kvm/sys_regs.c | 37 ++++++++++++++++++++++++++++++++++++- > > 1 file changed, 36 insertions(+), 1 deletion(-) > > > > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > > index 7a4cd644b9c0..4fa14b4ae2a6 100644 > > --- a/arch/arm64/kvm/sys_regs.c > > +++ b/arch/arm64/kvm/sys_regs.c > > @@ -1247,6 +1247,40 @@ static int set_id_aa64pfr0_el1(struct kvm_vcpu *vcpu, > > return 0; > > } > > > > +static int set_id_aa64dfr0_el1(struct kvm_vcpu *vcpu, > > + const struct sys_reg_desc *rd, > > + u64 val) > > +{ > > + u8 pmuver, host_pmuver; > > + > > + host_pmuver = kvm_arm_pmu_get_pmuver_limit(); > > + > > + /* > > + * Allow AA64DFR0_EL1.PMUver to be set from userspace as long > > + * as it doesn't promise more than what the HW gives us. We > > + * allow an IMPDEF PMU though, only if no PMU is supported > > + * (KVM backward compatibility handling). > > + */ > > It appears the patch allows userspace to set IMPDEF even > when host_pmuver == 0. Shouldn't it be allowed only when > host_pmuver == IMPDEF (as before)? > Probably, it may not cause any real problems though. Given that we don't treat the two cases any differently, I thought it would be reasonable to relax this particular case, and I can't see any reason why we shouldn't tolerate this sort of migration. > > > > + pmuver = FIELD_GET(ARM64_FEATURE_MASK(ID_AA64DFR0_EL1_PMUVer), val); > > + if (pmuver != ID_AA64DFR0_EL1_PMUVer_IMP_DEF && pmuver > host_pmuver) > > + return -EINVAL; > > + > > + /* We already have a PMU, don't try to disable it... */ > > + if (kvm_vcpu_has_pmu(vcpu) && > > + (pmuver == 0 || pmuver == ID_AA64DFR0_EL1_PMUVer_IMP_DEF)) > > + return -EINVAL; > > Nit: Perhaps it might be useful to return a different error code for the > above two (new) error cases (I plan to use -E2BIG and -EPERM > respectively for those cases with my ID register series). My worry in doing so is that we don't have an established practice for these cases. I'm fine with introducing new error codes, but I'm not sure there is an existing practice in userspace to actually interpret them. Even -EPERM has a slightly different meaning, and although there is some language there saying that it is all nonsense, we should be very careful. Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel