From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B16F2FF60F7 for ; Tue, 31 Mar 2026 09:43:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=zG4AXIEUaBaR53lnhGCsA3UJJe4kq+cAopamF4Dq/84=; b=DYleU0akDamXktUGy+4f+3OvPC VcAGp1XVRcdkhfkE1hEkEkYgqonReagXaQX6luIMV9kdt+k/JUv035rgFzT2MTxQav51AO7SycUo2 cVdXXtl5FY59p7ia/Xf8qfaX1t3S0yDaCkZkdVKeJjM2/X0O9BYInlo47PWcx5rjAGgWzP3f69TBa svyrv60Gc8HHUorDQCtYegyGUqdN+gzsCHy7oYpaqRtV8f3Cp2Que7T1DFLcCeb6ylELJN8ncictO kSb61XPdQJaHVv7P9ODe+53wjyZatq/ZqlbmWDKy+1rZtrxL1HDi+knOoFYjQuJeiEJ3ghy4vAjQU ll0IGZkg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1w7Vcl-0000000Chtx-1Dvu; Tue, 31 Mar 2026 09:43:03 +0000 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1w7Vcj-0000000Chth-1spw for linux-arm-kernel@lists.infradead.org; Tue, 31 Mar 2026 09:43:01 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 7F27D60103; Tue, 31 Mar 2026 09:43:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0E8C3C19423; Tue, 31 Mar 2026 09:43:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774950180; bh=Wz1JPZfYFZ/7NHEBqvrgk49xoWPlVfGaLJ0JuwcL59Y=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=IgEPV76ClMMw4kJ9lusAJKJ3rOwdntvbZsOyRSsNzCGLJlYx0/MeL3ZmWEVr+ANjG rns8L+YdnWl0TNfyDYr9PgggVNaBtIY87RZ0ZZLIdVyvanagus9T9Cb3JPS9/1Ieh3 xuboOczfpKyIABb2MVZbS7zNBflmHiD3cE/O6WawXn7X8tvwT5JCWWVe4AQFs03APD IIl6Z0NqjTqCgz3UYcn6UywafENS29rI+MG9Q2Mek6ObjJ70Cewq7+0Mvcy9YXK6HA GpDfbyLvd+bpH2hrudIXWwH0ZJ9JqmqE9884adyi0iNPwQIeFrXjl7nxiX1j498eaF ybb1Y0dELnRYA== 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 1w7Vcf-00000007Pek-20fN; Tue, 31 Mar 2026 09:42:57 +0000 Date: Tue, 31 Mar 2026 10:42:57 +0100 Message-ID: <86a4vo49ni.wl-maz@kernel.org> From: Marc Zyngier To: Vishnu Pajjuri Cc: Fuad Tabba , Joey Gouly , Suzuki K Poulose , Oliver Upton , Zenghui Yu , Christoffer Dall , Mark Brown , kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev Subject: Re: [PATCH v4 35/49] KVM: arm64: GICv3: nv: Plug L1 LR sync into deactivation primitive In-Reply-To: <1e050b67-2276-41ad-9265-796ba853dc7c@os.amperecomputing.com> References: <20251120172540.2267180-1-maz@kernel.org> <20251120172540.2267180-36-maz@kernel.org> <2e12c5c2-a1b6-47b7-b54c-7281a77bbe0a@os.amperecomputing.com> <878qb9cxzr.wl-maz@kernel.org> <1e050b67-2276-41ad-9265-796ba853dc7c@os.amperecomputing.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) 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: vishnu@os.amperecomputing.com, tabba@google.com, joey.gouly@arm.com, suzuki.poulose@arm.com, oupton@kernel.org, yuzenghui@huawei.com, christoffer.dall@arm.com, broonie@kernel.org, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.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 X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, 31 Mar 2026 07:31:54 +0100, Vishnu Pajjuri wrote: > > Hi Marc, > Many thanks for your reply. > > On 30-03-2026 17:47, Marc Zyngier wrote: > > On Mon, 30 Mar 2026 12:51:51 +0100, > > Vishnu Pajjuri wrote: > >> > >> Hi Fuad Tabba, > > > > To be brutally honest, I doubt Fuad really cares about NV, > > I see Tested-by: fuad Tabba on this patch so tried to reach out him. Rather than the author of the patch? > > > > >> I'm trying to run nested VMs on Ampere platforms after this patch > >> series(v6.19+) but nested VMs are not booting and triggering soft > >> lockups on L0 and L0 hang. But just before this patch I could able to > >> successfully boot the Nested VMs. > > > > So the host dies? There isn't much here that interacts with the host > > at all. Worse case, the L1 dies by not making progress. > > Initially L1 become unresponsive then L0 becomes unresponsive, soft > lockups and L0 hang. I've never seen this in the past 6 months. Doesn't mean there is no bug, but so far I haven't seen any of that. [...] > >> Were you able to boot Nested VMs successfully after v6.19+? > > > > I boot L3s every day. > > Do you mean L2s or L3s on top of L2s? I'm running an L0 host, itself running L1 guests, themselves running L2 guests, themselves running L3 guests. That's what "running L3s" means. > I running L1 and L2 using latest QEMU, do you use QEMU or kvmtool run > L1 and L2 in your regression tests? Both. And that really shouldn't matter. > > > > > >> LOG: > >> [ 164.647367] Call trace: > >> [ 164.647368] smp_call_function_many_cond+0x334/0x7a0 (P) > >> [ 164.647372] smp_call_function_many+0x20/0x40 > >> [ 164.647374] kvm_make_all_cpus_request+0xec/0x1b8 > >> [ 164.647377] vgic_queue_irq_unlock+0x1c8/0x2c8 > >> [ 164.647380] kvm_vgic_inject_irq+0x194/0x1e0 > >> [ 164.647381] kvm_vm_ioctl_irq_line+0x170/0x400 > >> [ 164.647386] kvm_vm_ioctl+0x7b8/0xc88 > >> [ 164.647389] __arm64_sys_ioctl+0xb4/0x118 > >> [ 164.647393] invoke_syscall+0x6c/0x100 > >> [ 164.647397] el0_svc_common.constprop.0+0x48/0xf0 > >> [ 164.647398] do_el0_svc+0x24/0x38 > >> [ 164.647400] el0_svc+0x3c/0x170 > >> [ 164.647403] el0t_64_sync_handler+0xa0/0xe8 > >> [ 164.647405] el0t_64_sync+0x1b0/0x1b8 > > > > This trace is about interrupt injection from userspace, not > > deactivation of a HW interrupt. > > None of that makes much sense. > > Although this behavior is puzzling, it matches the trace I typically > observe on L0. After reverting the patch, I was able to boot L2 guests > successfully. Well, this patch fixes real bugs, so it isn't going anywhere. The patch you are reverting addresses the deactivation of a HW interrupt, which is likely to be a timer (that's the only one we support). The stacktrace points to the userspace injection of an SPI. If we need to broadcast IPI, that's because there is no other SPI currently in flight. But if a CPU is not responding to the IPI, what is it doing? How does this interact with the patch you are reverting? Given that I don't know what you're running, how you are running it, that I don't have access to whatever HW you are using, and that you are providing no useful information that'd help me debug this, I will leave it up to you to debug it and come back with a detailed analysis of the problem. Thanks, M. -- Without deviation from the norm, progress is not possible.