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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id AE5D7C4332F for ; Thu, 3 Nov 2022 05:32:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229825AbiKCFcQ (ORCPT ); Thu, 3 Nov 2022 01:32:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57948 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229436AbiKCFcO (ORCPT ); Thu, 3 Nov 2022 01:32:14 -0400 Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AC40BBC2 for ; Wed, 2 Nov 2022 22:32:13 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id f63so769959pgc.2 for ; Wed, 02 Nov 2022 22:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=plrjvAdTS0nKqwkjAzFhlx4V983yw9yOIJecZW8zvnc=; b=NcV+yCiuxWOVxIsZo319+y5TyEFngethA6CQP6BOwGlsAkmNTjQraFrrswRtPZlkpD SJRUCsZfHhroDFuc1HWmkqwVEVc2RVFlGiP5zvsmzzPynvcbshB4QamTuDtUOEEi6JX4 BmUNoa7MFmnhIEnLohD39eY/9J7H2XyS5v3+5c2obyaUdJSs75ghA1uFF39Ky7NSG8YJ Fs1aAEnOM6YE3UXbpbHYeTtl8vatHs5B63YYsi93lW77Z447BjQnB4MN173r79lfZNfs EeCfl2gHHg6Bb2KUGH/aEOT1ThtG05EipcaO2uura2cCTvv3plIIwNol/Hx+i5Ii5y9/ Z3nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=plrjvAdTS0nKqwkjAzFhlx4V983yw9yOIJecZW8zvnc=; b=ITjXq8I8YvNb5Z/eJVbmqDOJsWTZKOj2VxEAS786aUXSkZQ0+Jmhh71PJkVVJc4klz PvGbUSeqB0rX1/EEfZJXAPwbi1cmmQ3OwmcPyZkUpCaSGrGHXOo0ZakFI+VAEB18HAPE Aqz+YSU06ea9shI9/4+yXc1xKsVASCVktQPU0sOJUJffnH2O81vRIFj8ou/cQFzvR8/I jx5W8P3P7BooPIAUUHHQkF3ky+3QaVwi8Rxfq742cXIOHKEwgAvi3Mpbng+XUj8QVFKA 64KX+4g3F6dxuAY2QzI/XiFIAAmy/GMklccGCawO2d6yBcqQblT/ckXgKm310r9OM4h0 Cg6w== X-Gm-Message-State: ACrzQf1UQMlzmeYtp9/e/NRiUssU4f5TsadBzX2K8XFxuUn+1FaJEwhj mtpOmFmcq+glnRkO5y3MkVCs6s1xLe/M/+xI/3jWtA== X-Google-Smtp-Source: AMsMyM4AzbIHrwu7GJ3+G6SgGpmo5sXra8QVKVVvusdM6c9LC+09ZHIwSIQNdprt/hyAqQXhcjpMftwwP6uibr705Fk= X-Received: by 2002:a63:db58:0:b0:443:575e:d1ed with SMTP id x24-20020a63db58000000b00443575ed1edmr24344874pgi.468.1667453533101; Wed, 02 Nov 2022 22:32:13 -0700 (PDT) MIME-Version: 1.0 References: <20221028105402.2030192-1-maz@kernel.org> <20221028105402.2030192-12-maz@kernel.org> In-Reply-To: <20221028105402.2030192-12-maz@kernel.org> From: Reiji Watanabe Date: Wed, 2 Nov 2022 22:31:56 -0700 Message-ID: Subject: Re: [PATCH v2 11/14] KVM: arm64: PMU: Allow ID_AA64DFR0_EL1.PMUver to be set from userspace To: Marc Zyngier 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org 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. > + 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). Thank you, Reiji > + > + /* We can only differ with PMUver, and anything else is an error */ > + val ^= read_id_reg(vcpu, rd); > + val &= ~ARM64_FEATURE_MASK(ID_AA64DFR0_EL1_PMUVer); > + if (val) > + return -EINVAL; > + > + vcpu->kvm->arch.dfr0_pmuver = pmuver; > + > + return 0; > +} > + > /* > * cpufeature ID register user accessors > * > @@ -1508,7 +1542,8 @@ static const struct sys_reg_desc sys_reg_descs[] = { > ID_UNALLOCATED(4,7), > > /* CRm=5 */ > - ID_SANITISED(ID_AA64DFR0_EL1), > + { SYS_DESC(SYS_ID_AA64DFR0_EL1), .access = access_id_reg, > + .get_user = get_id_reg, .set_user = set_id_aa64dfr0_el1, }, > ID_SANITISED(ID_AA64DFR1_EL1), > ID_UNALLOCATED(5,2), > ID_UNALLOCATED(5,3), > -- > 2.34.1 > > 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 C5B13C43217 for ; Thu, 3 Nov 2022 05:32:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 3A35E4B6F0; Thu, 3 Nov 2022 01:32:17 -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=@google.com 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 rzsbQHkAlOJb; Thu, 3 Nov 2022 01:32:16 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 128C84B6C7; Thu, 3 Nov 2022 01:32:16 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 5B1F44B6B2 for ; Thu, 3 Nov 2022 01:32:15 -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 N1ONreOEuZu8 for ; Thu, 3 Nov 2022 01:32:14 -0400 (EDT) Received: from mail-pg1-f175.google.com (mail-pg1-f175.google.com [209.85.215.175]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 297C94B648 for ; Thu, 3 Nov 2022 01:32:14 -0400 (EDT) Received: by mail-pg1-f175.google.com with SMTP id 128so771533pga.1 for ; Wed, 02 Nov 2022 22:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=plrjvAdTS0nKqwkjAzFhlx4V983yw9yOIJecZW8zvnc=; b=NcV+yCiuxWOVxIsZo319+y5TyEFngethA6CQP6BOwGlsAkmNTjQraFrrswRtPZlkpD SJRUCsZfHhroDFuc1HWmkqwVEVc2RVFlGiP5zvsmzzPynvcbshB4QamTuDtUOEEi6JX4 BmUNoa7MFmnhIEnLohD39eY/9J7H2XyS5v3+5c2obyaUdJSs75ghA1uFF39Ky7NSG8YJ Fs1aAEnOM6YE3UXbpbHYeTtl8vatHs5B63YYsi93lW77Z447BjQnB4MN173r79lfZNfs EeCfl2gHHg6Bb2KUGH/aEOT1ThtG05EipcaO2uura2cCTvv3plIIwNol/Hx+i5Ii5y9/ Z3nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=plrjvAdTS0nKqwkjAzFhlx4V983yw9yOIJecZW8zvnc=; b=yhTvYmbVbquz58UeEeErfuvntC8WUcClEva/esKa+Zo1B6kvPR7RlsdyPCcBse/8mM cbw4yAKIAUrNQjiUDSQk1QgWsQ51NjAo7tHGcU9qnw3SAZTBQE2Ok5YNXeCDDGyJnRP6 F2N2q1jbSi/XXd9YMq15KCuAinLl05QGGn5f9owIZ7wuggwY/RlVkJIvQ3kukfrdFXhP 4Sr9ci21MUrCluFJ1KIOe4xh+ZeKslN//NwL9XMsumvjEwqB4j2NGauWHhdgYg6GD2bg qRGatcXK1fGmaJqHNYVnejw+AYbHd9/dQQwKOZ9bYeu/H0adoqxoOoaZNJkhY7D0BDh0 XNKw== X-Gm-Message-State: ACrzQf0tHtLsC7fw7z3maUt06MuVzPXKl0mbKQP4KEmno4S0eQB26xCw Vze7/9bRyZwwr9J3+++S5QeSUSxeCzNKi1fFKs889w== X-Google-Smtp-Source: AMsMyM4AzbIHrwu7GJ3+G6SgGpmo5sXra8QVKVVvusdM6c9LC+09ZHIwSIQNdprt/hyAqQXhcjpMftwwP6uibr705Fk= X-Received: by 2002:a63:db58:0:b0:443:575e:d1ed with SMTP id x24-20020a63db58000000b00443575ed1edmr24344874pgi.468.1667453533101; Wed, 02 Nov 2022 22:32:13 -0700 (PDT) MIME-Version: 1.0 References: <20221028105402.2030192-1-maz@kernel.org> <20221028105402.2030192-12-maz@kernel.org> In-Reply-To: <20221028105402.2030192-12-maz@kernel.org> From: Reiji Watanabe Date: Wed, 2 Nov 2022 22:31:56 -0700 Message-ID: Subject: Re: [PATCH v2 11/14] KVM: arm64: PMU: Allow ID_AA64DFR0_EL1.PMUver to be set from userspace To: Marc Zyngier 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 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. > + 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). Thank you, Reiji > + > + /* We can only differ with PMUver, and anything else is an error */ > + val ^= read_id_reg(vcpu, rd); > + val &= ~ARM64_FEATURE_MASK(ID_AA64DFR0_EL1_PMUVer); > + if (val) > + return -EINVAL; > + > + vcpu->kvm->arch.dfr0_pmuver = pmuver; > + > + return 0; > +} > + > /* > * cpufeature ID register user accessors > * > @@ -1508,7 +1542,8 @@ static const struct sys_reg_desc sys_reg_descs[] = { > ID_UNALLOCATED(4,7), > > /* CRm=5 */ > - ID_SANITISED(ID_AA64DFR0_EL1), > + { SYS_DESC(SYS_ID_AA64DFR0_EL1), .access = access_id_reg, > + .get_user = get_id_reg, .set_user = set_id_aa64dfr0_el1, }, > ID_SANITISED(ID_AA64DFR1_EL1), > ID_UNALLOCATED(5,2), > ID_UNALLOCATED(5,3), > -- > 2.34.1 > > _______________________________________________ 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 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 EF2EAC4332F for ; Thu, 3 Nov 2022 05:33:20 +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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=NnXG3CGK6YukPYCGPPGx1i3naRfPb7AJvl9LslGvaLg=; b=eAYd0f0KWVbBGN /uFZyDSZkjo23aSB8n0eTkUqsueJSWxKB6Revc+H19anZaNXevM2PMLfMvqGHIDRSugyWA9QIyQ/m Vj4OoUIDwPPoAw+u2prnF2jPa5dg65ylhAIR/9+NQXlOf6JixGVzKb0utKH5Rm6JUfXQZLWOwqEDL /iwqxYJh9Sk7+FauMEMoIWKaZKp3HwcOU0trlwUQg9TgDd7InbhQt2PM4G/VB960+ofxD0WPF622/ FV73uQr1L10yZceDWtRkLmPvUThiw7zzcZq0jPX65pTXRlHaFtNQe7gm8jVJv6GT6yE3l8fFoJR1n zCuQ3lg8fO6gOnVKS+cw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oqSpu-00G9sQ-9S; Thu, 03 Nov 2022 05:32:18 +0000 Received: from mail-pg1-x531.google.com ([2607:f8b0:4864:20::531]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oqSpr-00G9qt-8w for linux-arm-kernel@lists.infradead.org; Thu, 03 Nov 2022 05:32:16 +0000 Received: by mail-pg1-x531.google.com with SMTP id 78so729691pgb.13 for ; Wed, 02 Nov 2022 22:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=plrjvAdTS0nKqwkjAzFhlx4V983yw9yOIJecZW8zvnc=; b=NcV+yCiuxWOVxIsZo319+y5TyEFngethA6CQP6BOwGlsAkmNTjQraFrrswRtPZlkpD SJRUCsZfHhroDFuc1HWmkqwVEVc2RVFlGiP5zvsmzzPynvcbshB4QamTuDtUOEEi6JX4 BmUNoa7MFmnhIEnLohD39eY/9J7H2XyS5v3+5c2obyaUdJSs75ghA1uFF39Ky7NSG8YJ Fs1aAEnOM6YE3UXbpbHYeTtl8vatHs5B63YYsi93lW77Z447BjQnB4MN173r79lfZNfs EeCfl2gHHg6Bb2KUGH/aEOT1ThtG05EipcaO2uura2cCTvv3plIIwNol/Hx+i5Ii5y9/ Z3nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=plrjvAdTS0nKqwkjAzFhlx4V983yw9yOIJecZW8zvnc=; b=onvmRmtkd819mB8bhePD0ololpEXQv8t/LVJa64z6l/agUh/99Ms3yXzRT0NTrHi1S FD96Pkc/dOTR28iQKwd2KnvclLZupW5OChFTsyx2T+FFfawVNBms1vL0yb9B34/bhSvV 9Qsw+cFfzyNn2sxGJVHUEhFb2KUuN/qyXmH6VxVckFedS69eawPWYyCC4VR8Wv3yF+tP EBYUdBnoypFNMObr1pblH857m0deypKEMntPj1ka4PBf0gRJZrOqSNfsxxurnG9nYDUb AwtkJgIXPiRMBMbgcEgpLO4iLdbB3Ev3K4jkaEiGFYqAZEJT7GOwJWTiBDcYR+I5RBNY PaZw== X-Gm-Message-State: ACrzQf0EB6P6FECEjGRMsHyOo5uF16qwkMCz/rdA/Do+LGS5pP13exO7 T5vYImV9QoydyMMcKxHZgUpP2qB9H6AEK8R2dMc4FbXO+rAVmw== X-Google-Smtp-Source: AMsMyM4AzbIHrwu7GJ3+G6SgGpmo5sXra8QVKVVvusdM6c9LC+09ZHIwSIQNdprt/hyAqQXhcjpMftwwP6uibr705Fk= X-Received: by 2002:a63:db58:0:b0:443:575e:d1ed with SMTP id x24-20020a63db58000000b00443575ed1edmr24344874pgi.468.1667453533101; Wed, 02 Nov 2022 22:32:13 -0700 (PDT) MIME-Version: 1.0 References: <20221028105402.2030192-1-maz@kernel.org> <20221028105402.2030192-12-maz@kernel.org> In-Reply-To: <20221028105402.2030192-12-maz@kernel.org> From: Reiji Watanabe Date: Wed, 2 Nov 2022 22:31:56 -0700 Message-ID: Subject: Re: [PATCH v2 11/14] KVM: arm64: PMU: Allow ID_AA64DFR0_EL1.PMUver to be set from userspace To: Marc Zyngier 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221102_223215_337356_4D59C2E8 X-CRM114-Status: GOOD ( 28.58 ) 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 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. > + 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). Thank you, Reiji > + > + /* We can only differ with PMUver, and anything else is an error */ > + val ^= read_id_reg(vcpu, rd); > + val &= ~ARM64_FEATURE_MASK(ID_AA64DFR0_EL1_PMUVer); > + if (val) > + return -EINVAL; > + > + vcpu->kvm->arch.dfr0_pmuver = pmuver; > + > + return 0; > +} > + > /* > * cpufeature ID register user accessors > * > @@ -1508,7 +1542,8 @@ static const struct sys_reg_desc sys_reg_descs[] = { > ID_UNALLOCATED(4,7), > > /* CRm=5 */ > - ID_SANITISED(ID_AA64DFR0_EL1), > + { SYS_DESC(SYS_ID_AA64DFR0_EL1), .access = access_id_reg, > + .get_user = get_id_reg, .set_user = set_id_aa64dfr0_el1, }, > ID_SANITISED(ID_AA64DFR1_EL1), > ID_UNALLOCATED(5,2), > ID_UNALLOCATED(5,3), > -- > 2.34.1 > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel