From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792670171; b=3eMThVmDNmSdparXy/qhvhdbRCogk6OYNv1xD8SlQ8+wAvgLoeN7KzrOIQG82JiOXM/b vkyU3LIUy5n42twIUV99Srvs8huSYBv9f8ZesnbP6rrQp0v7gypx2QHmi0tw0iJ9/8x/V N44qaNq/ZQseYYu53h7akp079qM27p2ldIyHh6D6bJDnULGxOqjGmNW3n9tgl8SDTkgex XOA2Enr40FUv+b7nG+3baTNmBFieWyYJtuMrLw2/x3Kht50RYlRx8M5t9U0LdHFu99wmE bEpdkNpZpJpjd8RhMzHDAS4Vpq55dmnxdAVSYD4FYs1XgGJs27v75O2eVEm8iCoFzyA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792670171; h=Received:DKIM-Signature:Received:Date:Message-ID:From:To:Cc:Subject: In-Reply-To:References:User-Agent:MIME-Version:Content-Type: X-SA-Exim-Connect-IP:X-SA-Exim-Rcpt-To:X-SA-Exim-Mail-From: X-SA-Exim-Scanned; bh=uSw0hqva5lv8jHz3IgGXQeMNYL3kw4sZIYA08yZ1Xng=; b=nmoGbEQnhd5ZaSY76Bu2moGSVJUoyC14ljD3qWyVos5+eIEp+xtGOYi4bVraYkqqM72r VywV9rNFn/hCoUzfkTG+QJMpRxkqrQdKmdNWGBdCDJOzM3187zQuurWnAkvr14debxcA2 wM2hdCaj2i38y+TiBZudfUpdamDyAKzOcw/kzUCdmbRaFBMXHrFXA3alPmA09yJxM5zr2 ASD+sKUBCk1UnPAL76sxF/yVjV/xmW/OqyF7IbCzHnhC/prFf6R8AE+ble+Nq+A2Y6yx0 ng0fTGR/s8+KCwTWZq9m5TeXadGKNBkZba1vqrZNcSx3r0uDvUdLQKwJ6O8RhUyldNA== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=XiygvKaQ; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 30014606A319; Thu, 22 Oct 2026 11:56:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=XiygvKaQ Received: by smtp.kernel.org (Postfix) with ESMTPSA id B76E91F000C1; Thu, 22 Oct 2026 11:56:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792670170; bh=uSw0hqva5lv8jHz3IgGXQeMNYL3kw4sZIYA08yZ1Xng=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=XiygvKaQqHrN8jioM3jUCOKES/mevdTuY04wOyxjToclbQdxBqa+8RX/wIr/Qe1hq 4rXbx4/0RuDJ5d4RwUpAFlAJer8xwN0XBEEJ5ZL9ZqePAPy3ZqJjiXvCXKe/A2BXSK rE+9Z9jL8Crnb65H0ssCKLvGDt00XNHcRYUjW/SybkujFPoL1Zg1yH/jo8qZIVr61r BJ8rN7A7ifsSGUD6zpKIZhbH0d0k+ry2cCMdagCrFFPg3fFExu1eELX054H/CtpoM/ 0e7NkfvITU5Ubhyj6OVQy5FflcB9Q8uw1cdrDq26AX47rQ8VrUA/PnBpUK8pJBeCV/ KdtdxPqDFo51w== 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 1xJrOy-000000062XC-1ir3; Thu, 22 Oct 2026 11:56:08 +0000 Date: Thu, 22 Oct 2026 12:56:07 +0100 Message-ID: <86ik2uymnc.wl-maz@kernel.org> From: Marc Zyngier To: Fuad Tabba Cc: Oliver Upton , kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, Joey Gouly , Suzuki K Poulose , Zenghui Yu , Steffen Eiden , Catalin Marinas , Will Deacon , Mark Rutland , Fuad Tabba , linux-kernel@vger.kernel.org Subject: Re: [PATCH] KVM: arm64: nv: Don't WARN when L1 sets IMO and FMO differently In-Reply-To: <20261022100319.3046476-1-fuad.tabba@linux.dev> References: <20261022100319.3046476-1-fuad.tabba@linux.dev> 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) X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list 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: fuad.tabba@linux.dev, oupton@kernel.org, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, seiden@linux.ibm.com, catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com, tabba@google.com, linux-kernel@vger.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, 22 Oct 2026 11:03:19 +0100, Fuad Tabba wrote: > > When L1 runs L2 with only one of IMO and FMO set in its HCR_EL2, > vgic_state_is_nested() WARNs that this isn't supported. KVM then runs > L2 as if both bits were set. > > However, IMO and FMO are independent bits, so any L1 can trigger the > WARN, which panics a host running with panic_on_warn. > > Drop the WARN. > > Fixes: 146a050f2d8c4 ("KVM: arm64: nv: Nested GICv3 emulation") > Reported-by: Sashiko > Closes: https://lore.kernel.org/all/20260714235020.2F4151F000E9@smtp.kernel.org/ > Cc: stable@vger.kernel.org > Signed-off-by: Fuad Tabba > --- > I dropped the WARN rather than demoting it to a print, the same way > e6e3e0022ef8f ("KVM: arm64: timer: Drop warning on failed interrupt > signalling") dropped one that was loud and easy to trigger from > userspace. > > Tested on QEMU with kvm-arm.mode=nested. A reproducer of mine sets > L1's HCR_EL2 to IMO=1, FMO=0, TGE=0 through KVM_SET_ONE_REG and starts > the vCPU at EL1. The host WARNs on the first KVM_RUN without this > patch, and not with it. > > Based on kvmarm/fixes (c5b7894f1a26b), which has the HCR_EL2_* rename. > > arch/arm64/kvm/vgic/vgic-v3-nested.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/arch/arm64/kvm/vgic/vgic-v3-nested.c b/arch/arm64/kvm/vgic/vgic-v3-nested.c > index 82bfc4d4f122f..c70e06c46a7a5 100644 > --- a/arch/arm64/kvm/vgic/vgic-v3-nested.c > +++ b/arch/arm64/kvm/vgic/vgic-v3-nested.c > @@ -121,9 +121,6 @@ bool vgic_state_is_nested(struct kvm_vcpu *vcpu) > > if (is_nested_ctxt(vcpu)) { > xmo = __vcpu_sys_reg(vcpu, HCR_EL2) & (HCR_EL2_IMO | HCR_EL2_FMO); > - WARN_ONCE(xmo && xmo != (HCR_EL2_IMO | HCR_EL2_FMO), > - "Separate virtual IRQ/FIQ settings not supported\n"); > - > return !!xmo; > } > No. Either we fix the bug, or the WARN_ON() stays. There is no alternative. M. -- Without deviation from the norm, progress is not possible.