Re: [PATCH v2 1/8] KVM: arm64: Remove VM-wide VNCR mapping counter

[Marc Zyngier <maz@kernel.org>]

On Thu, 06 Aug 2026 10:35:41 +0100,
sashiko-bot@kernel.org wrote:
> 
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> 
> Pre-existing issues:
> - [High] S1E2 TLBI instructions fail to invalidate the VNCR pseudo-TLB when TGE=0 or E2H=0.
> - [High] Hardcoded `TR_EL20` in `kvm_translate_vncr` misinterprets `TCR_EL2` for non-VHE guests.
> --
> 
> --- Patch [1]: [PATCH v2 1/8] KVM: arm64: Remove VM-wide VNCR mapping counter ---
> commit 9a09630623c9341a08c8ecea540015307bde098c
> Author: Marc Zyngier <maz@kernel.org>
> Subject: KVM: arm64: Remove VM-wide VNCR mapping counter
> 
> The global VNCR mapping counter is used to decide whether an L1
> provided VNCR page is mapped in L0 on any CPU at the point of
> dealing with a TLB invalidation. It is incremented when a mapping
> is made in the fixmap, and decremented when unmapped.
> 
> > diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c
> > index bbe9cebd3d9d5..c09b1d411c584 100644
> > --- a/arch/arm64/kvm/hyp/vhe/switch.c
> > +++ b/arch/arm64/kvm/hyp/vhe/switch.c
> > @@ -427,8 +427,7 @@ static bool kvm_hyp_handle_tlbi_el2(struct kvm_vcpu *vcpu, u64 *exit_code)
> >  	 * If we have to check for any VNCR mapping being invalidated,
> >  	 * go back to the slow path for further processing.
> >  	 */
> > -	if (vcpu_el2_e2h_is_set(vcpu) && vcpu_el2_tge_is_set(vcpu) &&
> > -	    atomic_read(&vcpu->kvm->arch.vncr_map_count))
> > +	if (vcpu_el2_e2h_is_set(vcpu) && vcpu_el2_tge_is_set(vcpu))
> 
> [Severity: High]
> This is a pre-existing issue, but does this condition incorrectly limit the
> slow-path fallback to only E2H=1 and TGE=1 contexts?
> 
> If a non-VHE guest (E2H=0) or a VHE guest running a VM (TGE=0) executes an
> S1E2 TLBI instruction (e.g. TLBI VAE2), the fast-path handler
> kvm_hyp_handle_tlbi_el2() performs the hardware TLBI but will evaluate the
> above condition as false.

"Stuck record".

There is no such thing as NV together with a non-VHE guest, so no
VNCR, and no need for taking the invalidation on the slow path.

	M.

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