Re: [PATCH 1/8] KVM: arm64: Enforce absence of FEAT_FGT on FGT registers

[Marc Zyngier <maz@kernel.org>]

On Thu, 18 Sep 2025 07:07:26 +0100,
Oliver Upton <oliver.upton@linux.dev> 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 <maz@kernel.org>
> > ---
> >  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 <asm/sysreg.h>
> >  
> >  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.