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 410BE342CBA; Tue, 14 Jul 2026 12:56:55 +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=1784033816; cv=none; b=o+u7C+aVSJdgqtt+AaVPFxcc+GfWiqyE0aBE0ZbEgqKkYZULzLY2UH5nTeUz7pySrQ+ZnJKZemSnrI02qxPf0YomApfNfx/D6IITMgqwAgonY6NQ9Al4ZWLrw6Mi17oqVXv/8JPIoX6/fqFI4cFbeUn22RSvK3q2NWB39JcxFBM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784033816; c=relaxed/simple; bh=Pimx1eRaDNLaPvWOwAywMPtkm45HP5qyW6AUuGlmxYE=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=Vvp8TIUhr0IHK4wLTzqo0OSkZjUdXDleJX+OefXIA1Jkm8fmbVx6z+iiCHue8t4VLp4vOs0DQlLZtBZBnEDYz7gBHGfNSZA5Ikx4A5kEt1Yk/ItTs2JLoeeFrzz8ZV/XuOyDLaEOlWTAOCk4IjuBIBN9thXsvfcTY8s6v/ogR7U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=T4yguSvy; 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="T4yguSvy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E69A11F00AC4; Tue, 14 Jul 2026 12:56:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784033814; bh=AqkB+gO3NqzY6QcNh0Spffa4y8b55Eb7I3qYIfkQ0n0=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=T4yguSvyUyBLnSEEP94ITpS6IYpT94x1xSFxLyg0jtFmOoBatX/MB7LHw0F4Dv0UG UNq0ZRsR17W/qz1SX8VgJ4elK6fsl3UbC1Ad4f6+TWPHzDkC+cdxFifCYBHqPmOj7T 24ildxcg2a86iELph1JeJT7WlGTNTwrlZBLSLDni68RDsmObfWYq/N3NCT/Kkfb1Al Ju+TINu51biRJuOv3oGiZGmmA1A9YO5i+hALg8BTfyyaHC3XpzOCAht137PGJqIYYq yob5r8EBboF9U9IvArFCGjd6TGbz5B0EpWdr3N9PUjOMNuH3pejkdFg8Wu2pk+CopI W7/CVXs4XOKbw== 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 1wjcgv-00000004tpA-04iQ; Tue, 14 Jul 2026 12:56:53 +0000 Date: Tue, 14 Jul 2026 13:56:52 +0100 Message-ID: <86v7ahohkb.wl-maz@kernel.org> From: Marc Zyngier To: sashiko-reviews@lists.linux.dev Cc: kvm@vger.kernel.org, "Oliver Upton" , kvmarm@lists.linux.dev Subject: Re: [PATCH v2 21/28] KVM: arm64: Add NVHCR_EL2 handling to the sysreg array In-Reply-To: <20260714102421.E51341F000E9@smtp.kernel.org> References: <20260714091641.1970822-1-maz@kernel.org> <20260714091641.1970822-22-maz@kernel.org> <20260714102421.E51341F000E9@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, oupton@kernel.org, kvmarm@lists.linux.dev X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Tue, 14 Jul 2026 11:24:21 +0100, sashiko-bot@kernel.org wrote: > > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: > - [Medium] Userspace writes to NVHCR_EL2 via KVM_SET_ONE_REG are silently discarded upon L1 guest entry. > -- > > --- Patch [21]: [PATCH v2 21/28] KVM: arm64: Add NVHCR_EL2 handling to the sysreg array --- > commit 40ce0e0627839603da739968567e9f3998f1ed15 > Author: Marc Zyngier > > KVM: arm64: Add NVHCR_EL2 handling to the sysreg array > > Expose NVHCR_EL2 to userspace, and treat the direct access as UNDEF, > as that would only outline a bug in our exception routing. > > > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > > index 9439c5b2b1fe8..0aeb2e736fde3 100644 > > --- a/arch/arm64/kvm/sys_regs.c > > +++ b/arch/arm64/kvm/sys_regs.c > > [ ... ] > > > @@ -3774,6 +3800,8 @@ static const struct sys_reg_desc sys_reg_descs[] = { > > sve_el2_visibility), > > > > EL2_REG_VNCR(HCRX_EL2, reset_val, 0), > > + EL2_REG_FILTERED(NVHCR_EL2, undef_access, reset_val, 0, > > + nvhcr_el2_visibility), > > [Severity: Medium] > Will userspace writes to NVHCR_EL2 be silently discarded upon L1 guest entry? Short answer: no. Longer answer follows. > Because NVHCR_EL2 is exposed without a custom .set_user handler, writes via > KVM_SET_ONE_REG will update vcpu->arch.ctxt.sys_regs[NVHCR_EL2] using the > default behavior. However, upon running the VCPU in hyp_ctxt (L1 hypervisor), > __compute_hcr() unconditionally executes: > > __vcpu_assign_sys_reg(vcpu, NVHCR_EL2, __vcpu_sys_reg(vcpu, HCR_EL2)); If userspace can write to NVHCR_EL2, that's because the guest has NV3 exposed to it. And if so, then the host also has NV3 and is using it. Then the code looks like this: /* Publish the guest's view of HCR_EL2 to the HW */ if (cpus_have_final_cap(ARM64_HAS_NV3) && vcpu_el2_e2h_is_set(vcpu)) write_sysreg_s(__vcpu_sys_reg(vcpu, HCR_EL2), SYS_NVHCR_EL2); else __vcpu_assign_sys_reg(vcpu, NVHCR_EL2, __vcpu_sys_reg(vcpu, HCR_EL2)); and the value of HCR_EL2 is written into the NVHCR_EL2 *register*. > > This seems to clobber the userspace write, causing UAPI state loss and a KVM > ABI violation where KVM_SET_ONE_REG writes are expected to be preserved. See above? > > Does this require a custom .set_user handler to maintain alias synchronization > between NVHCR_EL2 and HCR_EL2? No. M. -- Without deviation from the norm, progress is not possible.