[PATCH v4 35/49] KVM: arm64: GICv3: nv: Plug L1 LR sync into deactivation primitive

[Marc Zyngier]

On Tue, 31 Mar 2026 07:31:54 +0100,
Vishnu Pajjuri <vishnu at os.amperecomputing.com> 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 <vishnu at os.amperecomputing.com> 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.