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 matches the already existing behaviour for GICv3-native VMs. Signed-off-by: Sascha Bischoff --- 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 a7cd0badc20cc..b4e78958ede12 100644 --- a/arch/arm64/kvm/sys_regs.c +++ b/arch/arm64/kvm/sys_regs.c @@ -2174,14 +2174,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); } -- 2.34.1