From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ED3042571A0; Thu, 2 Jul 2026 21:02:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783026178; cv=none; b=PPj5yS8HNofLrmPN6xNfkCYKpOh8uIs5hVwxJ4rRXazZs6sg4gtWYjA34/8QthJy3paHKPqjxX/fzzK8xyK+rHzXIf6bm8a0+n39Z9rJTnCfgg3PlqGs3i53KC2DAAxO1T+9ZsfUELO3jwetUQ8rO+G+/ijPUrFJ7Ct9KmXJouw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783026178; c=relaxed/simple; bh=oRoobASajO99MaP1F2kZ5hI2McBFNYeAI9TMQVWz778=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=jd3ZzrzM6IgPB1M6rTngS3tI7TaHY8x/0pASZ1FQKUccpMmvXKIb+7FqffG1MLn+UtLMX5RKYFk+V8ktyp4s5ATbF0+Gzvy8CAG6IdQ2IqmisbrtbGUKbU78kDWj+gElf/VLGzcLqpkwTOtsDbFXG8Wkma4fiMOgfoY3QvYoR9A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IDRpBlz9; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="IDRpBlz9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7985E1F000E9; Thu, 2 Jul 2026 21:02:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783026176; bh=S5P/GL2wpYH6WTHGlfcwNG/3r8kbd7VYOP/LEq11yIA=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=IDRpBlz9hdFz+BiW11MKcOAQT91a8+5OO3K/evQvsCSf1w5tNXeYeSrVOANZOxybx RdTCX/EyD3hpBJfm7IoQc+Im51boWUZu7H9Lg/UFS/KFs342DAkdK0fkvu/FFjK1xh zLyIYNsOoBwhjnm00OZJE9aq/BI03w1t10Xa3MfGRxoou6BDLDqLd/Rkr1YCUomOZ3 Fbhn8eLv2lPZ4Hrb4LdMXcofRjHS1uTnqmNbBM6+IHmcuK4z2kiJisPbr+5QFCz//D BoC4EC5fqO/YDwSvsLPcNhN2lINj5WbToWR+vW1darGaKFJUI5pmU+w8JRnVyB+DL6 NOuuEKvqj0WHQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=lobster-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wfOYg-00000000ukk-2tSs; Thu, 02 Jul 2026 21:02:54 +0000 Date: Thu, 02 Jul 2026 22:04:43 +0100 Message-ID: <87mrw96r2s.wl-maz@kernel.org> From: Marc Zyngier To: sashiko-reviews@lists.linux.dev Cc: kvm@vger.kernel.org, kvmarm@lists.linux.dev, "Oliver Upton" Subject: Re: [PATCH 25/28] KVM: arm64: Engage NV3 TLBI trap elision In-Reply-To: <20260702164514.C41EF1F00A3D@smtp.kernel.org> References: <20260702160248.1377250-1-maz@kernel.org> <20260702160248.1377250-26-maz@kernel.org> <20260702164514.C41EF1F00A3D@smtp.kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: sashiko-reviews@lists.linux.dev, kvm@vger.kernel.org, kvmarm@lists.linux.dev, oupton@kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Thu, 02 Jul 2026 17:45:14 +0100, sashiko-bot@kernel.org wrote: > > Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider: > > New issues: > - [Critical] Enabling FEAT_NV3 TLBI elision (NVnTTLB) breaks KVM's nested S2 MMU caching, leaving stale L2 guest S1 TLB entries across cached physical VMIDs. > - [High] TLBI trap elision for NV1 guests is nested inside a check requiring the guest to use VHE, rendering the optimization dead code. > - [Medium] NV3 TLBI trap elision is incomplete because HCRX_EL2_NVnTTLBOS is omitted from the TLBI elision mask. > > Pre-existing issues: > - [High] vcpu_set_hcrx() statically evaluates the guest's dynamic HCR_EL2.E2H state at boot, permanently disabling HCRX_EL2_NVTGE even if the guest later enables VHE. > -- > > commit e34c9c8b4a16d0026abc090c888c49e7f1c66d8a > Author: Marc Zyngier > > KVM: arm64: Engage NV3 TLBI trap elision > > This commit enables FEAT_NV3 TLBI trap elision for guests that are not > NV2-aware. It relaxes TLBI traps to only TGE=0 using HCRX_EL2 bits. > > > diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h > > index b32870a5e1236..d6f432b1558f5 100644 > > --- a/arch/arm64/include/asm/kvm_emulate.h > > +++ b/arch/arm64/include/asm/kvm_emulate.h > > @@ -715,6 +715,15 @@ static inline void vcpu_set_hcrx(struct kvm_vcpu *vcpu) > > if (cpus_have_final_cap(ARM64_HAS_NV3) && > > vcpu_has_nv(vcpu) && vcpu_el2_e2h_is_set(vcpu)) { > > [Severity: High] > This isn't a bug introduced by this patch, but because vcpu_set_hcrx is > called once during kvm_calculate_traps at the first VCPU run, the guest > has not yet executed and its virtual HCR_EL2.E2H is 0. > > Since vcpu_el2_e2h_is_set checks the dynamic HCR_EL2 register, does this > evaluate to false and permanently disable HCRX_EL2_NVTGE even if the guest > later sets HCR_EL2.E2H at runtime? No. E2H is never configurable in KVM. You should know it by now. > > [Severity: High] > Does checking vcpu_el2_e2h_is_set here prevent the NV1 TLBI elision > optimization from ever being reached? > > Since an NV1 guest does not have VHE enabled (E2H=0), this outer condition > will evaluate to false, meaning the inner !kvm_has_nv2(vcpu->kvm) block > added below will be skipped. And that's on purpose. FEAT_NV3 doesn't apply to E2H==0. Because frankly, it is about as useful as a concrete parachute. > > > vcpu->arch.hcrx_el2 |= HCRX_EL2_NVTGE; > > + > > + /* > > + * If the guest is NV2-capable, then we need to see > > + * all the TLBIs, as configured in HCR_EL2. > > + * Otherwise, relax the TLBI traps to only TGE=0. > > + */ > > + if (!kvm_has_nv2(vcpu->kvm)) > > + vcpu->arch.hcrx_el2 |= (HCRX_EL2_NVnTTLB | > > + HCRX_EL2_NVnTTLBIS); > > [Severity: Medium] > Does this mask omit the Outer Shareable S1 TLBI elision bit > (HCRX_EL2_NVnTTLBOS)? It does. > > Without it, will Outer Shareable S1 TLBI instructions continue to > trap to KVM, missing out on the intended performance optimization? > Yeah. Not that it matters, but might as well be consistent. But that can't be unconditional (we rely on trapping all OS TLBIs if OS TLBIs are not advertised to the guest. > [Severity: Critical] > Does enabling hardware TLBI elision here break KVM's nested S2 MMU > caching? > > KVM caches multiple S2 MMU contexts (with distinct physical VMIDs) for > the same virtual VMID, and defers physical VMID switches until guest entry. > Not really, but hey, I'm getting tired of explaining stuff to a machine that won't even read my emails. > If a guest hypervisor writes to VTTBR_EL2 and executes an S1 TLBI natively, > hardware will only invalidate the currently active physical VMID. > This depends on the value of NVHCR_EL2.TGE. > Could this cause the hardware to invalidate the wrong context (the > hypervisor's own S1 TLB instead of the L2 guest's) and miss other cached > physical VMIDs sharing the virtual VMID, potentially leading to stale > TLB entries? If NVHCR_EL2.TGE == 1, then this will only invalidate L1's own TLBs, as per the architecture (TGE controls whether TLBI S1E1* affects the host or the guest). If L1 does the wrong thing, that's its problem, not the host's, and this is no different from what already happens in KVM or on bare metal. So no, that doesn't cause anything wrong. M. -- Jazz isn't dead. It just smells funny.