[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