Re: [PATCH v2 1/8] KVM: arm64: Remove VM-wide VNCR mapping counter
Marc Zyngier <[email protected]> Thu, 06 Aug 2026 12:53:38 +0100
| Newsgroups | dev.linux.lists.kvmarm,dev.linux.lists.sashiko-reviews,org.kernel.vger.kvm |
|---|---|
| Message-ID | <[email protected]> |
On Thu, 06 Aug 2026 10:35:41 +0100, [email protected] 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 <[email protected]> > 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.