[PATCH v6 01/39] KVM: arm64: vgic-v3: Drop userspace write sanitization for ID_AA64PFR0.GIC on GICv5

[Jonathan Cameron]

On Thu, 19 Mar 2026 11:35:32 +0000
Sascha Bischoff <Sascha.Bischoff at arm.com> wrote:

> 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.
> 
You have me at self tests of the infrastructure.  That bit I get :)

> 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);
> > >  }
> > >    
> >   
>