Re: [PATCH v2 27/28] KVM: arm64: Expose FEAT_NV3 to guests

[Marc Zyngier <maz@kernel.org>]

On Tue, 14 Jul 2026 11:15:59 +0100,
sashiko-bot@kernel.org wrote:
> 
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> 
> Pre-existing issues:
> - [High] Host nested virtualization capabilities (ID_AA64MMFR4_EL1.NV_frac) are leaked to non-NV guests, breaking live migration across heterogeneous hosts.
> --
> 
> --- Patch [27]: [PATCH v2 27/28] KVM: arm64: Expose FEAT_NV3 to guests ---
> commit 508d53194bf7ddb4e61f279e50216aa88dd973ad
> Author: Marc Zyngier <maz@kernel.org>
> 
> KVM: arm64: Expose FEAT_NV3 to guests
>     
> Further enable FEAT_NV3 by making it visible to NV guests.
> 
> > diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
> > index f646894fec9a9..70d605e60cfb3 100644
> > --- a/arch/arm64/kvm/nested.c
> > +++ b/arch/arm64/kvm/nested.c
> [ ... ]
> > @@ -1741,7 +1741,9 @@ u64 limit_nv_id_reg(struct kvm *kvm, u32 reg, u64 val)
> >  			val = 0;
> >  		} else {
> >  			val &= ID_AA64MMFR4_EL1_NV_frac;
> > -			if (cpus_have_final_cap(ARM64_HAS_NV2P1))
> > +			if (cpus_have_final_cap(ARM64_HAS_NV3))
> > +				val = ID_REG_LIMIT_FIELD_ENUM(val, ID_AA64MMFR4_EL1, NV_frac, NV3);
> > +			else if (cpus_have_final_cap(ARM64_HAS_NV2P1))
> >  				val = ID_REG_LIMIT_FIELD_ENUM(val, ID_AA64MMFR4_EL1, NV_frac, NV2P1);
> >  			else
> >  				val = SYS_FIELD_PREP_ENUM(ID_AA64MMFR4_EL1, NV_frac, NV2_ONLY);
> 
> [Severity: High]
> This isn't a bug introduced by this patch, but while looking at NV feature
> exposure here, could ID_AA64MMFR4_EL1.NV_frac leak into non-NV guests?
> 
> Looking at __kvm_read_sanitised_id_reg() in arch/arm64/kvm/sys_regs.c,
> it seems SYS_ID_AA64MMFR4_EL1 is not explicitly masked out for non-NV guests
> in the switch statement:
> 
> 	case SYS_ID_MMFR4_EL1:
> 		val &= ~ID_MMFR4_EL1_CCIDX;
> 		break;
> 	}
> 
> If a non-NV guest is created on an NV3-capable host, will the host's raw
> NV_frac leak into the VM's ID_AA64MMFR4_EL1 register?
> 
> If this VM is later migrated to a host with only NV2P1, could userspace's
> attempt to restore the capability via KVM_SET_ONE_REG fail because the
> destination host's arm64_check_features() rejects the higher NV_frac value?

Yeah, we should ignore this field being written back for a non-NV
guest. It won't be evaluated anyway in a non-NV context.

	M.

-- 
Without deviation from the norm, progress is not possible.