[PATCH 13/20] KVM: arm64: Move RESx into individual register descriptors

Marc Zyngier maz at kernel.org
Fri Jan 30 01:06:00 PST 2026


On Thu, 29 Jan 2026 18:13:18 +0000,
Fuad Tabba <tabba at google.com> wrote:
> 
> >
> > Actually, this interacts badly with check_feat_map(), which tries to
> > find whether we have fully populated the registers, excluding the RESx
> > bits. But since we consider E2H to be a reserved but, we end-up with:
> >
> > [    0.141317] kvm [1]: Undefined HCR_EL2 behaviour, bits 0000000400000000
> >
> > With my approach, it was possible to distinguish the architecturally
> > RESx bits (defined as RES0 or RES1), as they were the only ones with
> > the FORCE_RESx attribute.
> >
> > I can work around it with
> >
> > diff --git a/arch/arm64/kvm/config.c b/arch/arm64/kvm/config.c
> > index 364bdd1e5be51..398458f4a6b7b 100644
> > --- a/arch/arm64/kvm/config.c
> > +++ b/arch/arm64/kvm/config.c
> > @@ -1283,7 +1283,7 @@ static void __init check_feat_map(const struct reg_bits_to_feat_map *map,
> >         u64 mask = 0;
> >
> >         for (int i = 0; i < map_size; i++)
> > -               if (!(map[i].flags & FORCE_RESx))
> > +               if (!(map[i].flags & FORCE_RESx) || !(map[i].bits & resx))
> >                         mask |= map[i].bits;
> >
> >         if (mask != ~resx)
> >
> > but it becomes a bit awkward...
> 
> If it becomes more complicated than the original, then what's the
> point. Up to you whether you want to try to pursue this or not.

Not more complicated, just moving the complexity somewhere else. I'll
add a comment explaining the logic at this point. Overall, this is a
net cleanup, I think.

> From my part:
> 
> Reviewed-by: Fuad Tabba <tabba at google.com>

Thank you!

	M.

-- 
Without deviation from the norm, progress is not possible.



More information about the linux-arm-kernel mailing list