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

Vishnu Pajjuri
2026-03-31T06:32:16Z

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@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.

>
>> 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 bisected the failure to a single commit which is this patch which is
>> causing the issue.
>>
>> I would like to understand from you that did you observed anything
>> like that?
>
> No. If I had, I wouldn't have merged the series.
>
>>
>> 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 running L1 and L2 using latest QEMU, do you use QEMU or kvmtool run L1
and L2 in your regression tests?

>
>> 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.

Regards,
-Vishnu
>
> M.
>