[PATCH v6 01/39] KVM: arm64: vgic-v3: Drop userspace write sanitization for ID_AA64PFR0.GIC on GICv5
Sascha Bischoff
Sascha.Bischoff at arm.com
Thu Mar 19 04:35:32 PDT 2026
On Thu, 2026-03-19 at 10:02 +0000, Jonathan Cameron wrote:
> On Tue, 17 Mar 2026 11:40:13 +0000
> Sascha Bischoff <Sascha.Bischoff at arm.com> wrote:
>
> > Drop a check that blocked userspace writes to ID_AA64PFR0_EL1 for
> > writes that set the GIC field to 0 (NI) on GICv5 hosts. There is no
> > such check for GICv3 native systems, and having inconsistent
> > behaviour
> > both complicates the logic and risks breaking existing userspace
> > software that expects to be able to write the register.
> >
> > This means that userspace is now able to create a GICv3 guest on
> > GICv5
> > hosts, and disable the guest from seeing that it has a GICv3. This
>
> Just to clarify this is removing a check on a nonsensical setup?
> I'm not against it if that simplifies things but I couldn't quite
> parse the description.
Effectively, we were being more strict when running with GICv3 on a
GICv5 host than when running natively on a GICv3 host. This by itself
wasn't too big an issue, but it can cause existing software break if it
relies on being able to hide GICv3 this way (for whatever reason...),
and somewhat breaks the portability story.
Moreover, we test these sorts of things in the selftests. If a virtual
GICv3 is created but then userspace comes along and zeros the feature
bits (so, hides the feature), we expect the FGU infrastructure to take
over to undef registers/instructions related to that feature. So, in
this case, rather than letting userspace hide the virtual GICv3 from
the guest, we instead stopped it from hiding it.
Does that make some sort of sense?
Thanks,
Sascha
>
> > matches the already existing behaviour for GICv3-native VMs.
> >
> > Signed-off-by: Sascha Bischoff <sascha.bischoff at arm.com>
> > ---
> > arch/arm64/kvm/sys_regs.c | 8 --------
> > 1 file changed, 8 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> > index 1b4cacb6e918a..4b9f4e5d946b1 100644
> > --- a/arch/arm64/kvm/sys_regs.c
> > +++ b/arch/arm64/kvm/sys_regs.c
> > @@ -2177,14 +2177,6 @@ static int set_id_aa64pfr0_el1(struct
> > kvm_vcpu *vcpu,
> > (vcpu_has_nv(vcpu) && !FIELD_GET(ID_AA64PFR0_EL1_EL2,
> > user_val)))
> > return -EINVAL;
> >
> > - /*
> > - * If we are running on a GICv5 host and support
> > FEAT_GCIE_LEGACY, then
> > - * we support GICv3. Fail attempts to do anything but set
> > that to IMP.
> > - */
> > - if (vgic_is_v3_compat(vcpu->kvm) &&
> > - FIELD_GET(ID_AA64PFR0_EL1_GIC_MASK, user_val) !=
> > ID_AA64PFR0_EL1_GIC_IMP)
> > - return -EINVAL;
> > -
> > return set_id_reg(vcpu, rd, user_val);
> > }
> >
>
More information about the linux-arm-kernel
mailing list