RE: [PATCH 14/16] PCI: hv: Switch to msi_create_parent_irq_domain()

Michael Kelley
2025-07-04T02:29:43Z

From: Thomas Gleixner <tglx@linutronix.de> Sent: Thursday, July 3, 2025 2:22 PM
>
> On Thu, Jul 03 2025 at 20:15, Michael Kelley wrote:
> > From: Thomas Gleixner <tglx@linutronix.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