[patch V4 05/21] irqchip/gic-v3-its: Provide MSI parent for PCI/MSI[-X]

[Marc Zyngier]

On Sat, 29 Jun 2024 10:42:35 +0100,
Marc Zyngier <maz at kernel.org> wrote:
> 
> On Sat, 29 Jun 2024 09:37:59 +0100,
> Thomas Gleixner <tglx at linutronix.de> wrote:
> > 
> > On Fri, Jun 28 2024 at 23:24, Catalin Marinas wrote:
> > > I just noticed guests (under KVM) failing to boot on my TX2 with your
> > > latest branch. I bisected to this patch as the first bad commit.
> > >
> > > I'm away this weekend, so won't have time to dive deeper. It looks like
> > > the CPU is stuck in do_idle() (no timer interrupts?). Also sysrq did not
> > > seem able to get the stack trace on the other CPUs. It fails both with a
> > > single or multiple CPUs in the same way place (shortly before mounting
> > > the rootfs and starting user space).
> > 
> > From the RH log it's clear that PCI interrupts are not delivered.
> > 
> > > I'll drop your branch from the arm64 for-kernelci for now and have a
> > > look again on Monday.
> > 
> > I stare too. Unfortunately I don't have access to such hardware :(
> 
> On the face of it, the LPIs are never unmasked (grepping in
> /sys/kernel/debug/kvm/*/vgic-state):
> 
> Distributor
> ===========
> vgic_model:	GICv3
> nr_spis:	32
> nr_lpis:	7
> enabled:	1
> 
> P=pending_latch, L=line_level, A=active
> E=enabled, H=hw, C=config (level=1, edge=0)
> G=group
> 
> VCPU 0 TYP   ID TGT_ID PLAEHCG     HWID   TARGET SRC PRI VCPU_ID
> ----------------------------------------------------------------
> [...]
>        LPI 8192      0 1000001        0        0   0 160      -1 
>        LPI 8193      1 0000001        0        0   0 160      -1 
>        LPI 8194      2 0000001        0        0   0 160      -1 
>        LPI 8256      3 0000001        0        0   0 160      -1 
>        LPI 8257      4 0000001        0        0   0 160      -1 
>        LPI 8320      5 0000001        0        0   0 160      -1 
>        LPI 8321      6 1000001        0        0   0 160      -1
> 
> 8192 and 8321 are pending, but never enabled.
> 
> This is further confirmed by placing traces in the guest. Now trying
> to find my way through the new maze of callbacks, because something is
> clearly missing there.

This is clearly related to MSI_FLAG_PCI_MSI_MASK_PARENT which is not
seen as being set from cond_unmask_parent(), and ignoring this
condition results in a booting VM.

I have the ugly feeling that the flag is applied at the wrong level,
or not propagated.

	M.

-- 
Without deviation from the norm, progress is not possible.