[PATCH v2 02/36] KVM: arm64: gic-v3: Switch vGIC-v3 to use generated ICH_VMCR_EL2
Jonathan Cameron
jonathan.cameron at huawei.com
Mon Jan 12 04:41:43 PST 2026
On Fri, 9 Jan 2026 16:57:18 +0000
Sascha Bischoff <Sascha.Bischoff at arm.com> wrote:
> On Wed, 2026-01-07 at 10:55 +0000, Sascha Bischoff wrote:
> > On Tue, 2026-01-06 at 18:00 +0000, Jonathan Cameron wrote:
> > > On Fri, 19 Dec 2025 15:52:36 +0000
> > > Sascha Bischoff <Sascha.Bischoff at arm.com> wrote:
> > >
> > > > From: Sascha Bischoff <Sascha.Bischoff at arm.com>
> > > >
> > > > The VGIC-v3 code relied on hand-written definitions for the
> > > > ICH_VMCR_EL2 register. This register, and the associated fields,
> > > > is
> > > > now generated as part of the sysreg framework. Move to using the
> > > > generated definitions instead of the hand-written ones.
> > > >
> > > > There are no functional changes as part of this change.
> > > >
> > > > Signed-off-by: Sascha Bischoff <sascha.bischoff at arm.com>
> > > Hi Sascha
> > >
> > > Happy new year. There is a bit in here that isn't obviously going
> > > to result in no functional change. I'm too lazy to chase where the
> > > value
> > > goes to check it it's a real bug or not.
> > >
> > > Otherwise this is inconsistent on whether the _MASK or define
> > > without
> > > it from the sysreg generated header is used in FIELD_GET() /
> > > FIELD_PREP()
> > >
> > > I'd always use the _MASK version.
> >
> > Hi Jonathan,
> >
> > I've updated the code to use the _MASK version.
> >
> Hi Jonathan,
>
> I've actually had a change of heart (sorry!). I think it is clearer to
> use the _MASK version when explicitly using the value as a mask, but to
> drop that for the FIELD_x() ops as in that case we're naming a field.
>
> I've gone through and made the usage of those consistent.
Fair enough. I'd have argued that there should never have been both
in the first place in the generated header as the non _MASK ones add
no value. The only argument I can think of is that we don't normally
use _MASK for single bit defines when doing doing it by hand, but such
is life. I do think you are setting yourself up for a world in which new
patches mix these up and you get to post lots of review feedback on it ;)
Jonathan
>
> Sascha
>
> >
More information about the linux-arm-kernel
mailing list