From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 F370B70809; Thu, 16 Apr 2026 14:20:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776349207; cv=none; b=bF6K4eYzGYYALdbEcZM4Jh7sTYbJ+PyLb+lGhkS31w3AGdJ04C6gp+kYn/QhXYIC1zt/i6vc/KgUSqKfEbPWTnPUqi4SSn9mWS+sWSPie7ZBaC4HRgBIDyrY3tzCe8zS79Tu/chM5wfPqCKnfjcHeER+dnd6W8B9SvtWYHbo09M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776349207; c=relaxed/simple; bh=RZuDXw+JiK6q6buh+87zhYDDJVKlnTY4BAiLSYnFAnw=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=BBeb2oZ6WtMujQ9oCdlW/SiaUNfDAenejcKl7a3uM+kbFxGzvSu5eKyOnjpBMEe30eC0AiGBXmPiteKx0IxoAaskzEEF6sXUtzS9yruOKYceLm6HEw/7D0BiHdePZ7OYWHJuVwi/3U4U5DSmX10MsBqD83O2KVEea88O31LGSKQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Wnrj4HaQ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Wnrj4HaQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8C44BC2BCAF; Thu, 16 Apr 2026 14:20:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776349206; bh=RZuDXw+JiK6q6buh+87zhYDDJVKlnTY4BAiLSYnFAnw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Wnrj4HaQioAqql2JiUoVFNbDaNJECfQmKpB6ww0lhWxdspI1oBPGYEeEi/m4yIpeo z5wd9tHlkizhYQJCpY4zjtMYUchFm0vIi9JZKrrWIgUNWzHts6aap8ISQStiYuCrB2 SAnB3WtP2eYIAoGPxnJm901QZMcOOWpaQ9jenaBVIhDaSKbei2h3XzN52VcyRhBbND 3cKEkjoMSxE4SlWnFqwMrtRnoq9kL5X8hKVWaG5FFhPmowd0wx+x6gysPyN3TRLwqs vvYMoYcMgrzhpwlQvMDCTV/H186bXcSxHyRcsa3giGWs+P8lbV3an/9KJKIr7ZnJcB B3EPJledMvYPQ== 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 1wDNZc-0000000CATP-1O6U; Thu, 16 Apr 2026 14:20:04 +0000 Date: Thu, 16 Apr 2026 15:20:03 +0100 Message-ID: <865x5r2dik.wl-maz@kernel.org> From: Marc Zyngier To: Deepanshu Kartikey Cc: oupton@kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, drjones@redhat.com, christoffer.dall@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, syzbot+12b178b7c756664d2518@syzkaller.appspotmail.com Subject: Re: [PATCH] arm64: KVM: Initialize vGIC before preempt-disabled section in kvm_reset_vcpu() In-Reply-To: <20260412080437.38782-1-kartikey406@gmail.com> References: <20260412080437.38782-1-kartikey406@gmail.com> 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: linux-kernel@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: kartikey406@gmail.com, oupton@kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, drjones@redhat.com, christoffer.dall@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, syzbot+12b178b7c756664d2518@syzkaller.appspotmail.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Sun, 12 Apr 2026 09:04:37 +0100, Deepanshu Kartikey wrote: > > kvm_reset_vcpu() calls kvm_timer_vcpu_reset() inside a preempt-disabled > section to avoid races with preempt notifiers that also call vcpu put/load. > > However, kvm_timer_vcpu_reset() eventually calls kvm_vgic_inject_irq() > which triggers vgic_lazy_init() if the vGIC has not been initialized yet. > vgic_lazy_init() acquires a mutex and calls vgic_init() which invokes > synchronize_srcu_expedited() -- both of which may sleep. Sleeping inside > a preempt-disabled section is illegal and causes: > > BUG: scheduling while atomic: syz.1.49/3699/0x00000002 > > Fix this by calling vgic_lazy_init() before preempt_disable(). On the > second call inside kvm_vgic_inject_irq(), vgic_initialized() will return > true and vgic_lazy_init() will return immediately without sleeping. > I think this really goes in the wrong direction. Forcing the vgic (a global resource) to initialise when the vcpu's timer (a local resource) is reset feels at best bizarre. Now you are promoting it to be forced at vcpu reset. This makes things worse. You probably want to take a step back and look at *why* we end-up here. The core reason seems to be that the timer emulation caches the level in a per-timer structure, and tries hard not call into the vgic unless the level changes. Which means that unless the vgic is initialised and is able to latch that state, the initial pending state will not be propagated to the guest. But do we need this optimisation? I don't think so. Other emulated devices don't require it. We can let the vgic know the state of the timer at every vcpu entry, just like we do for other virtual interrupts that the kernel injects (PMU, vgic MI). Once you remove the this cache and the need for the vgic to buffer things outside of normal execution, you can also drop the magic init from the interrupt injection path, because the injection will happen on the run path, just like any other PPI. That'd be a much better approach IMO. Thanks, M. -- Without deviation from the norm, progress is not possible.