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 68B44320F for ; Thu, 18 Sep 2025 09:53:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758189189; cv=none; b=PO4loxvfYM8Qm0GSCRQrpm7RvS9fe5MthMwgPv3vpR7pLQiBzmqptE3JQkfiiicuUbf1Cx6mln3rlUyMV6qj+J5tGw9WE4VEmrYrROkjAKaGoE1l4B+qSFzF27JupaGvSPHiAKYKwyc80zey+a9p1aqchnasFJ20zo/k9FGuaJA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758189189; c=relaxed/simple; bh=OqwqsLUwctAhMmXyW7hg6PYE3hnpufnrkvvwksaLQC0=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=Scnohtk14LTAdYzY3BhwtTiwbZdqFYcPVP3gXLNLwz5/rp3FvRXfrN41g5X5RRnYJqpCF/3BN8pYAcITE51xkVZudtYt4XJd84MeuIAvCuoKKCNMDstqsUCN1SMB1CWaptwABi5T8c9C3WBhYwficf6RyOjxoeZWxxcwaSHU1Wo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=baCGlaQj; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="baCGlaQj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3C1D3C4CEE7; Thu, 18 Sep 2025 09:53:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1758189189; bh=OqwqsLUwctAhMmXyW7hg6PYE3hnpufnrkvvwksaLQC0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=baCGlaQjwKgJVyWuAvbkoAIjoKk0acSkkVj2p6Tnf2g1yE33H9ItAQj3E3/BJg+HM orAuNkl4Rx80VrVNmhF324O+LETCRPc35ovWUtRq1YiM0jbGXH0c+KGUHb1gH4Wn/V W+Ey76H3bHqP7Ld69nXigKhRf7syRliG8Y0RdrtZ6R2fIby8lcqq8jBStiyL8XRs5n bQMoq7VnrC3xAV7fx7167Sb5fVOOIcSxckXOVyC/3ei5XMuj5bhSubRpjyqmrURvG7 XKKSL4B5HSCv/LcSZwM35PyKveY0YEhnf9aRSBimdYNingVKedTeV1Gh+QM40EAKG5 XKD0WQTkyND/g== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1uzBK7-00000007NcI-0SQw; Thu, 18 Sep 2025 09:53:07 +0000 Date: Thu, 18 Sep 2025 10:53:06 +0100 Message-ID: <86jz1w13zx.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, Joey Gouly , Suzuki K Poulose , Zenghui Yu , Jinqian Yang Subject: Re: [PATCH 1/8] KVM: arm64: Enforce absence of FEAT_FGT on FGT registers In-Reply-To: References: <20250917165840.1633412-1-maz@kernel.org> <20250917165840.1633412-2-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/30.1 (aarch64-unknown-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: 185.219.108.64 X-SA-Exim-Rcpt-To: oliver.upton@linux.dev, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, yangjinqian1@huawei.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Thu, 18 Sep 2025 07:07:26 +0100, Oliver Upton wrote: > > Hey, > > On Wed, Sep 17, 2025 at 05:58:33PM +0100, Marc Zyngier wrote: > > Did you mean to add changelogs to these patches? I actually meant to send a *different* series. Pushed out the wrong branch and sent crap. Apologies for the noise. > > > Signed-off-by: Marc Zyngier > > --- > > arch/arm64/kvm/config.c | 201 +++++++++++++++++++++++++++------------- > > 1 file changed, 137 insertions(+), 64 deletions(-) > > > > diff --git a/arch/arm64/kvm/config.c b/arch/arm64/kvm/config.c > > index da66c4a147752..42b834c82a20d 100644 > > --- a/arch/arm64/kvm/config.c > > +++ b/arch/arm64/kvm/config.c > > @@ -8,11 +8,16 @@ > > #include > > > > struct reg_bits_to_feat_map { > > - u64 bits; > > + union { > > + u64 bits; > > + u64 *res0p; > > + }; > > > > #define NEVER_FGU BIT(0) /* Can trap, but never UNDEF */ > > #define CALL_FUNC BIT(1) /* Needs to evaluate tons of crap */ > > #define FIXED_VALUE BIT(2) /* RAZ/WI or RAO/WI in KVM */ > > +#define RES0_POINTER BIT(3) /* Pointer to RES0 value instead of bits */ > > + > > unsigned long flags; > > > > union { > > @@ -28,9 +33,16 @@ struct reg_bits_to_feat_map { > > }; > > }; > > > > -#define __NEEDS_FEAT_3(m, f, id, fld, lim) \ > > +struct reg_to_feat_map { > > + const char *name; > > + const struct reg_bits_to_feat_map feat_map; > > Some documentation might help with confusion between this and > bit_feat_map. IIUC you're using a single NEEDS_FEAT() expression to RES0 > the whole sucker based on whether or not the FEAT_XXX for the EL2 > register is present? > > > + const struct reg_bits_to_feat_map *bit_feat_map; > > + const unsigned int bit_feat_map_sz; > > +}; > > Ok, differentiating "reg_to_feat_map" and "reg_bits_to_feat_map" is a > bit hard on the reader... Could this maybe be called "reg_feat_map_desc" > or similar? Sure thing. Things will be a bit noisier, but hey... > This refactoring could also be done as a separate patch. Yup, that's what I already have in the series I was suppose to send... I'll respin this shortly. Thanks, M. -- Without deviation from the norm, progress is not possible.