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 61484390CB7; Thu, 30 Jul 2026 08:19:39 +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=1785399585; cv=none; b=RjgwYDRQBGa9dr1FYcJtYRbFSJCIV9Pu0xlmY2Stjpfzlb8aU4o7gW504HtQj429KVPEKl2eRJn65UM2eXz6bjzBf10QfItEex4iMaxGhWGSqMJIQWa1HfMfqQB47FGwgQgOGJNNcYIBrB2jRd42Ljf3e3eEgXB6BcjMT8mz5aM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785399585; c=relaxed/simple; bh=ubDG/zR55rBrBbN+Rc6lFXrHhf+M7PgG9xflp6lGW48=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=EzofW2PY7KV2e3aNWcmrKkh3i1ycNewW+Hd18xgrzsviORkZ+JHYuoOeq5yqdZrj5Kf8gc8J2eRTFuKlS6dsJWvWdQIbDZ8cRjjLM/Ul2hYrzU0KWoFjBm1UDyOJO/giezYHF0ajZR3htSQwFZZBYBKv+3RVyaivPBjNJA4Gy1I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HVIqHf8a; 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="HVIqHf8a" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D90911F000E9; Thu, 30 Jul 2026 08:19:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785399577; bh=jkRKSSy9dVOQeTue4bRWAYRjc31aE2L4nr42iAgCTr4=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=HVIqHf8ahot71t5Sy+Ecx9cm/b1YJ25mpcIDYbg7K6bibXw9Ori+a/a2cpI9BRiH1 nxn3F3P01/Dpy5yH32VgOMA9DcybxZ0NHXJvT/hxJVvHMjNeT+g0P2OZzMVdAAtwKG AontrcOC9SLDB4bLi7/S5YaUh74Dza5ELKkYewh7MQ2iDU9j71rDt+sBBlDXpa/LmM zjxPBkjFONGPpS6R6+oR3hLigIiss1S4t3Bz+PXOsgn7pO4E4dblStlsgLRh8xlrZz /O8EaveBvYByJE2qylWEyXDOGjlr8foriYpUoAhp3Bfrlq9p15LG6yGciyHtK1uHvD gG9N//XAioupg== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-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 1wpLzL-0000000AQbx-46Up; Thu, 30 Jul 2026 08:19:36 +0000 Date: Thu, 30 Jul 2026 09:01:33 +0100 Message-ID: <86o6fodhya.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 v4 03/29] KVM: arm64: Merge guest's HCRX_EL2 using NV_HCRX_GUEST_EXCLUDE In-Reply-To: <20260730072930.85DB21F000E9@smtp.kernel.org> References: <20260730071022.296811-1-maz@kernel.org> <20260730071022.296811-4-maz@kernel.org> <20260730072930.85DB21F000E9@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, 30 Jul 2026 08:29:29 +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] The NV_HCRX_GUEST_EXCLUDE macro fails to exclude HCRX_EL2_MCE2, allowing a nested hypervisor to break KVM's transparent MOPS migration handling. > -- > > --- Patch [3]: [PATCH v4 03/29] KVM: arm64: Merge guest's HCRX_EL2 using NV_HCRX_GUEST_EXCLUDE --- > commit 32a9437b5c31bcb57be7ba071a094800d7980587 > Author: Marc Zyngier > > KVM: arm64: Merge guest's HCRX_EL2 using NV_HCRX_GUEST_EXCLUDE > > This commit refactors HCRX_EL2 handling by introducing a macro that > explicitly lists the bits excluded from the merge, preventing the nested > guest from overriding them. > > > diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h > > index 18131e395e24c..0903e08f4b6a0 100644 > > --- a/arch/arm64/kvm/hyp/include/hyp/switch.h > > +++ b/arch/arm64/kvm/hyp/include/hyp/switch.h > > [ ... ] > > > @@ -325,6 +325,24 @@ static inline void __deactivate_traps_mpam(void) > > write_sysreg_s(MPAMHCR_HOST_FLAGS, SYS_MPAMHCR_EL2); > > } > > > > +/* > > + * Just like for HCR_EL2, we can't let the guest mess with some of the > > + * basics we rely on in HCRX_EL2. However, the major difference is that > > + * HCRX_EL2 only affects EL1, and never EL2 (sudden outburst of sanity, I > > + * guess). So it is always the guest inflicting it on its own guestx. > > + * > > + * Things we don't want to let the guest control are: > > + * > > + * - TMEA: That's for us to decide how an SEA is routed, not the guest. > > + * > > + * - PTTWI: Similarly, it is for us to decide whether Reduced Coherency for > > + * the PTW is a thing. It really isn't. > > + * > > + * - EnIDCP128: We don't allow IMPDEF sysregs -- full stop. > > + */ > > +#define NV_HCRX_GUEST_EXCLUDE (HCRX_EL2_TMEA | HCRX_EL2_PTTWI | \ > > + HCRX_EL2_EnIDCP128) > > [Severity: High] > This isn't a bug introduced by this patch, but since NV_HCRX_GUEST_EXCLUDE > enumerates the bits the nested guest is not allowed to override, should > HCRX_EL2_MCE2 be excluded here as well? > > KVM (L0) relies on intercepting MOPS exceptions (via HCRX_EL2.MCE2=1) to > handle vCPU physical migrations transparently. If L0 merges a value from the > L1 hypervisor that sets MCE2 to 0 (which happens naturally if L1 does not > support MOPS), If L1 doesn't support MOPS, then HCRX_EL2.MCEn==0, and the instructions UNDEF. > and L0 then migrates the physical CPU while L2 is executing a > MOPS instruction, the MOPS exception could trap to EL1 (L2) instead of > EL2 (L0). No, the instruction will have UNDEF in L2. Furthermore, trapping non-matching CPUs is a guest decision, and L0 is not in charge of deciding this. However, what is missing is the redirection of the exception to L1 when it fires. Something else to fix at some point. M. -- Without deviation from the norm, progress is not possible.