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 B89AFC433F5 for ; Sun, 21 Nov 2021 12:37:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 738DE4B154; Sun, 21 Nov 2021 07:37:16 -0500 (EST) 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 vX6j8Y3WMrqQ; Sun, 21 Nov 2021 07:37:14 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 89EBD4B13A; Sun, 21 Nov 2021 07:37:14 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 306B14B154 for ; Sun, 21 Nov 2021 07:37:14 -0500 (EST) 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 44IfVxYjpvg7 for ; Sun, 21 Nov 2021 07:37:12 -0500 (EST) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id C17274064F for ; Sun, 21 Nov 2021 07:37:12 -0500 (EST) Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 032C660E54; Sun, 21 Nov 2021 12:37:12 +0000 (UTC) Received: from ip-185-104-136-29.ptr.icomera.net ([185.104.136.29] 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.94.2) (envelope-from ) id 1mom5m-006sQU-2v; Sun, 21 Nov 2021 12:37:10 +0000 Date: Sun, 21 Nov 2021 12:37:09 +0000 Message-ID: <87k0h1sn0q.wl-maz@kernel.org> From: Marc Zyngier To: Reiji Watanabe Subject: Re: [RFC PATCH v3 03/29] KVM: arm64: Introduce struct id_reg_info In-Reply-To: <20211117064359.2362060-4-reijiw@google.com> References: <20211117064359.2362060-1-reijiw@google.com> <20211117064359.2362060-4-reijiw@google.com> 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: 185.104.136.29 X-SA-Exim-Rcpt-To: reijiw@google.com, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, james.morse@arm.com, alexandru.elisei@arm.com, suzuki.poulose@arm.com, pbonzini@redhat.com, will@kernel.org, drjones@redhat.com, liangpeng10@huawei.com, pshier@google.com, ricarkol@google.com, oupton@google.com, jingzhangos@google.com, rananta@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, Will Deacon , Peter Shier , Paolo Bonzini , 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 Wed, 17 Nov 2021 06:43:33 +0000, Reiji Watanabe wrote: > > This patch lays the groundwork to make ID registers writable. > > Introduce struct id_reg_info for an ID register to manage the > register specific control of its value for the guest, and provide set > of functions commonly used for ID registers to make them writable. > > The id_reg_info is used to do register specific initialization, > validation of the ID register and etc. Not all ID registers must > have the id_reg_info. ID registers that don't have the id_reg_info > are handled in a common way that is applied to all ID registers. > > At present, changing an ID register from userspace is allowed only > if the ID register has the id_reg_info, but that will be changed > by the following patches. > > No ID register has the structure yet and the following patches > will add the id_reg_info for some ID registers. > > Signed-off-by: Reiji Watanabe > --- > arch/arm64/include/asm/sysreg.h | 1 + > arch/arm64/kvm/sys_regs.c | 226 ++++++++++++++++++++++++++++++-- > 2 files changed, 218 insertions(+), 9 deletions(-) > > diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h > index 16b3f1a1d468..597609f26331 100644 > --- a/arch/arm64/include/asm/sysreg.h > +++ b/arch/arm64/include/asm/sysreg.h > @@ -1197,6 +1197,7 @@ > #define ICH_VTR_TDS_MASK (1 << ICH_VTR_TDS_SHIFT) > > #define ARM64_FEATURE_FIELD_BITS 4 > +#define ARM64_FEATURE_FIELD_MASK ((1ull << ARM64_FEATURE_FIELD_BITS) - 1) > > /* Create a mask for the feature bits of the specified feature. */ > #define ARM64_FEATURE_MASK(x) (GENMASK_ULL(x##_SHIFT + ARM64_FEATURE_FIELD_BITS - 1, x##_SHIFT)) > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > index 5608d3410660..1552cd5581b7 100644 > --- a/arch/arm64/kvm/sys_regs.c > +++ b/arch/arm64/kvm/sys_regs.c > @@ -265,6 +265,181 @@ static bool trap_raz_wi(struct kvm_vcpu *vcpu, > return read_zero(vcpu, p); > } > > +/* > + * A value for FCT_LOWER_SAFE must be zero and changing that will affect > + * ftr_check_types of id_reg_info. > + */ > +enum feature_check_type { > + FCT_LOWER_SAFE = 0, > + FCT_HIGHER_SAFE, > + FCT_HIGHER_OR_ZERO_SAFE, > + FCT_EXACT, > + FCT_EXACT_OR_ZERO_SAFE, > + FCT_IGNORE, /* Don't check (any value is fine) */ > +}; > + > +static int arm64_check_feature_one(enum feature_check_type type, int val, > + int limit) > +{ > + bool is_safe = false; > + > + if (val == limit) > + return 0; > + > + switch (type) { > + case FCT_LOWER_SAFE: > + is_safe = (val <= limit); > + break; > + case FCT_HIGHER_OR_ZERO_SAFE: > + if (val == 0) { > + is_safe = true; > + break; > + } > + fallthrough; > + case FCT_HIGHER_SAFE: > + is_safe = (val >= limit); > + break; > + case FCT_EXACT: > + break; > + case FCT_EXACT_OR_ZERO_SAFE: > + is_safe = (val == 0); > + break; > + case FCT_IGNORE: > + is_safe = true; > + break; > + default: > + WARN_ONCE(1, "Unexpected feature_check_type (%d)\n", type); > + break; > + } > + > + return is_safe ? 0 : -1; > +} > + > +#define FCT_TYPE_MASK 0x7 > +#define FCT_TYPE_SHIFT 1 > +#define FCT_SIGN_MASK 0x1 > +#define FCT_SIGN_SHIFT 0 > +#define FCT_TYPE(val) ((val >> FCT_TYPE_SHIFT) & FCT_TYPE_MASK) > +#define FCT_SIGN(val) ((val >> FCT_SIGN_SHIFT) & FCT_SIGN_MASK) > + > +#define MAKE_FCT(shift, type, sign) \ > + ((u64)((((type) & FCT_TYPE_MASK) << FCT_TYPE_SHIFT) | \ > + (((sign) & FCT_SIGN_MASK) << FCT_SIGN_SHIFT)) << (shift)) > + > +/* For signed field */ > +#define S_FCT(shift, type) MAKE_FCT(shift, type, 1) > +/* For unigned field */ > +#define U_FCT(shift, type) MAKE_FCT(shift, type, 0) > + > +/* > + * @val and @lim are both a value of the ID register. The function checks > + * if all features indicated in @val can be supported for guests on the host, > + * which supports features indicated in @lim. @check_types indicates how > + * features in the ID register needs to be checked. > + * See comments for id_reg_info's ftr_check_types field for more detail. > + */ > +static int arm64_check_features(u64 check_types, u64 val, u64 lim) > +{ > + int i; > + > + for (i = 0; i < 64; i += ARM64_FEATURE_FIELD_BITS) { > + u8 ftr_check = (check_types >> i) & ARM64_FEATURE_FIELD_MASK; > + bool is_sign = FCT_SIGN(ftr_check); > + enum feature_check_type fctype = FCT_TYPE(ftr_check); > + int fval, flim, ret; > + > + fval = cpuid_feature_extract_field(val, i, is_sign); > + flim = cpuid_feature_extract_field(lim, i, is_sign); > + > + ret = arm64_check_feature_one(fctype, fval, flim); > + if (ret) > + return -E2BIG; > + } > + return 0; > +} All this logic seems to reinvent what we already have in arch/arm64/kernel/cpufeature.c. I'd rather we rely on it and maintain a single idreg handling library. Could you outline what is missing in the cpufeature code that requires you to invent your own? I'm sure Suzuki could help here to make it directly usable. 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