Message-ID:
 <SN6PR02MB41573141969F6B3028099C65D442A@SN6PR02MB4157.namprd02.prod.outlook.com>
Date: Fri, 4 Jul 2025 02:27:01 +0000
From: Michael Kelley <mhklinux@...look.com>
To: Thomas Gleixner <tglx@...utronix.de>, Nam Cao <namcao@...utronix.de>, Marc
 Zyngier <maz@...nel.org>, Lorenzo Pieralisi <lpieralisi@...nel.org>,
	Krzysztof Wilczyński <kwilczynski@...nel.org>, Manivannan
 Sadhasivam <mani@...nel.org>, Rob Herring <robh@...nel.org>, Bjorn Helgaas
	<bhelgaas@...gle.com>, "linux-pci@...r.kernel.org"
	<linux-pci@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, Karthikeyan Mitran
	<m.karthikeyan@...iveil.co.in>, Hou Zhiqiang <Zhiqiang.Hou@....com>, Thomas
 Petazzoni <thomas.petazzoni@...tlin.com>, Pali Rohár
	<pali@...nel.org>, "K . Y . Srinivasan" <kys@...rosoft.com>, Haiyang Zhang
	<haiyangz@...rosoft.com>, Wei Liu <wei.liu@...nel.org>, Dexuan Cui
	<decui@...rosoft.com>, Joyce Ooi <joyce.ooi@...el.com>, Jim Quinlan
	<jim2101024@...il.com>, Nicolas Saenz Julienne <nsaenz@...nel.org>, Florian
 Fainelli <florian.fainelli@...adcom.com>, Broadcom internal kernel review
 list <bcm-kernel-feedback-list@...adcom.com>, Ray Jui <rjui@...adcom.com>,
	Scott Branden <sbranden@...adcom.com>, Ryder Lee <ryder.lee@...iatek.com>,
	Jianjun Wang <jianjun.wang@...iatek.com>, Marek Vasut
	<marek.vasut+renesas@...il.com>, Yoshihiro Shimoda
	<yoshihiro.shimoda.uh@...esas.com>, Michal Simek <michal.simek@....com>,
	Daire McNamara <daire.mcnamara@...rochip.com>, Nirmal Patel
	<nirmal.patel@...ux.intel.com>, Jonathan Derrick
	<jonathan.derrick@...ux.dev>, Matthias Brugger <matthias.bgg@...il.com>,
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-hyperv@...r.kernel.org"
	<linux-hyperv@...r.kernel.org>, "linux-rpi-kernel@...ts.infradead.org"
	<linux-rpi-kernel@...ts.infradead.org>, "linux-mediatek@...ts.infradead.org"
	<linux-mediatek@...ts.infradead.org>, "linux-renesas-soc@...r.kernel.org"
	<linux-renesas-soc@...r.kernel.org>
Subject: RE: [PATCH 14/16] PCI: hv: Switch to msi_create_parent_irq_domain()

From: Thomas Gleixner <tglx@...utronix.de> Sent: Thursday, July 3, 2025 2:22 PM
> 
> On Thu, Jul 03 2025 at 20:15, Michael Kelley wrote:
> > From: Thomas Gleixner <tglx@...utronix.de> Sent: Thursday, July 3, 2025 1:00 PM
> >> Does it conflict against the PCI tree?
> >
> > There's no conflict in the "next" or "for-linus" tags in
> > https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/
> >
> > The conflict is with Patch 2 of this series:
> >
> > https://lore.kernel.org/linux-hyperv/1749650984-9193-1-git-send-email-shradhagupta@linux.microsoft.com/
> >
> > which is in netdev/net-next.
> 
> That's a trivial one. There are two ways to handle it:
> 
>   1) Take it through the PCI tree and provide a conflict resolution for
>      linux-next and later for Linus as reference.
> 
>   2) Route it through the net-next tree with an updated patch.
> 
> As there are no further dependencies (aside of the missing export which
> is needed anyway) it's obvious to pick #2 as it creates the least
> headaches. Assumed that the PCI folks have no objections.
> 
> Michael, as you have resolved the conflict already, can you please
> either take care of it yourself or provide the resolution here as
> reference for Nam?

I haven't resolved the conflict. As a shortcut for testing I just
removed the conflicting patch since it is for a Microsoft custom NIC
("MANA") that's not in the configuration I'm testing with. I'll have to
look more closely to figure out the resolution.

Separately, this patch (the switch to misc_create_parent_irq_domain)
isn't working for Linux VMs on Hyper-V on ARM64. The initial symptom
is that interrupts from the NVMe controller aren't getting handled
and everything hangs. Here's the dmesg output:

[   84.463419] hv_vmbus: registering driver hv_pci
[   84.463875] hv_pci abee639e-0b9d-49b7-9a07-c54ba8cd5734: PCI VMBus probing: Using version 0x10004
[   84.464518] hv_pci abee639e-0b9d-49b7-9a07-c54ba8cd5734: PCI host bridge to bus 0b9d:00
[   84.464529] pci_bus 0b9d:00: root bus resource [mem 0xfc0000000-0xfc00fffff window]
[   84.464531] pci_bus 0b9d:00: No busn resource found for root bus, will use [bus 00-ff]
[   84.465211] pci 0b9d:00:00.0: [1414:b111] type 00 class 0x010802 PCIe Endpoint
[   84.466657] pci 0b9d:00:00.0: BAR 0 [mem 0xfc0000000-0xfc00fffff 64bit]
[   84.481923] pci_bus 0b9d:00: busn_res: [bus 00-ff] end is updated to 00
[   84.481936] pci 0b9d:00:00.0: BAR 0 [mem 0xfc0000000-0xfc00fffff 64bit]: assigned
[   84.482413] nvme nvme0: pci function 0b9d:00:00.0
[   84.482513] nvme 0b9d:00:00.0: enabling device (0000 -> 0002)
[   84.556871] irq 17, desc: 00000000e8529819, depth: 0, count: 0, unhandled: 0
[   84.556883] ->handle_irq():  0000000062fa78bc, handle_bad_irq+0x0/0x270
[   84.556892] ->irq_data.chip(): 00000000ba07832f, 0xffff00011469dc30
[   84.556895] ->action(): 0000000069f160b3
[   84.556896] ->action->handler(): 00000000e15d8191, nvme_irq+0x0/0x3e8
[  172.307920] watchdog: BUG: soft lockup - CPU#6 stuck for 26s! [kworker/6:1H:195]

Everything looks normal up to the "irq 17" line.  Meanwhile, the device probe path
is waiting with this stack trace, which I suspect is the first Interaction with the NVMe
controller:

[<0>] blk_execute_rq+0x1ec/0x348
[<0>] nvme_execute_rq+0x20/0x68
[<0>] __nvme_submit_sync_cmd+0xc8/0x170
[<0>] nvme_identify_ctrl.isra.0+0x90/0xf0
[<0>] nvme_init_identify+0x44/0xee0
[<0>] nvme_init_ctrl_finish+0x84/0x370
[<0>] nvme_probe+0x668/0x7d8
[<0>] local_pci_probe+0x48/0xd0
[<0>] pci_device_probe+0xd0/0x248
[<0>] really_probe+0xd4/0x388
[<0>] __driver_probe_device+0x90/0x1a8
[<0>] driver_probe_device+0x48/0x150
[<0>] __device_attach_driver+0xe0/0x1b8
[<0>] bus_for_each_drv+0x8c/0xf8
[<0>] __device_attach+0x104/0x1e8
[<0>] device_attach+0x1c/0x30
[<0>] pci_bus_add_device+0xe0/0x188
[<0>] pci_bus_add_devices+0x40/0x98
[<0>] hv_pci_probe+0x4b0/0x690 [pci_hyperv]
[<0>] vmbus_probe+0x4c/0xb0 [hv_vmbus]
[<0>] really_probe+0xd4/0x388
[<0>] __driver_probe_device+0x90/0x1a8
[<0>] driver_probe_device+0x48/0x150
[<0>] __driver_attach+0xe8/0x1c8
[<0>] bus_for_each_dev+0x80/0xf0
[<0>] driver_attach+0x2c/0x40
[<0>] bus_add_driver+0x118/0x260
[<0>] driver_register+0x68/0x138
[<0>] __vmbus_driver_register+0x70/0x98 [hv_vmbus]
[<0>] init_hv_pci_drv+0x1b8/0xfff8 [pci_hyperv]
[<0>] do_one_initcall+0x4c/0x2c8
[<0>] do_init_module+0x60/0x280
[<0>] load_module+0x2318/0x2448
[<0>] init_module_from_file+0x94/0xe0
[<0>] __arm64_sys_finit_module+0x228/0x3e8
[<0>] invoke_syscall+0x6c/0xf8
[<0>] el0_svc_common.constprop.0+0xc8/0xf0
[<0>] do_el0_svc+0x24/0x38
[<0>] el0_svc+0x40/0x1a0
[<0>] el0t_64_sync_handler+0xd0/0xe8
[<0>] el0t_64_sync+0x1b0/0x1b8

I'll try to figure out what's going wrong.

Michael

Powered by blists - more mailing lists