Hi Bjorn, I was able to trigger an interrupt, the pciehp_isr was triggered and there are "Timeouts" while processing the hotplug, I suspect this is due to the slowness of the simulation platform, is my assumption correct? [26599.580420] pcieport 0000:02:01.0: pciehp: pending interrupts 0x0001 from Slot Status [26599.580575] pcieport 0000:02:01.0: pciehp: Slot(0): Button press: will power on in 5 sec [26599.593768] pcieport 0000:02:01.0: pciehp: Timeout on hotplug command 0x17e1 (issued 42213 msec ago) [26599.598920] pcieport 0000:02:01.0: pciehp: pciehp_set_indicators: SLOTCTRL 80 write cmd 2c0 [26605.104802] pcieport 0000:02:01.0: pciehp: pciehp_check_link_active: lnk_status = 2025 [26605.104840] pcieport 0000:02:01.0: pciehp: Slot(0): Link Up [26605.109616] pcieport 0000:02:01.0: pciehp: pciehp_get_power_status: SLOTCTRL 80 value read 16e1 [26605.126589] pcieport 0000:02:01.0: pciehp: Timeout on hotplug command 0x16e1 (issued 5528 msec ago) [26606.458516] pcieport 0000:02:01.0: pciehp: Timeout on hotplug command 0x12e1 (issued 1327 msec ago) [26606.458554] pcieport 0000:02:01.0: pciehp: pciehp_power_on_slot: SLOTCTRL 80 write cmd 0 [26606.475509] pcieport 0000:02:01.0: pciehp: Timeout on hotplug command 0x12e1 (issued 1344 msec ago) [26606.481024] pcieport 0000:02:01.0: pciehp: pciehp_set_indicators: SLOTCTRL 80 write cmd 200 [26606.618088] pcieport 0000:02:01.0: pciehp: pciehp_check_link_status: lnk_status = 2025 [26606.674790] pci 0000:03:00.0: [abcd:0000] type 00 class 0x000000 PCIe Endpoint [26606.725288] pci 0000:03:00.0: BAR 0 [mem 0xf8000000-0xf9ffffff] [26607.867503] pci 0000:03:00.0: 63.014 Gb/s available PCIe bandwidth, limited by 32.0 GT/s PCIe x2 link at 0000:02:01.0 (capable of 1024.000 Gb/s with 64.0 GT/s PCIe x16 link) [26608.386085] pci 0000:03:00.0: vgaarb: pci_notify [26608.491596] pcieport 0000:02:01.0: distributing available resources [26608.491637] pcieport 0000:02:01.0: PCI bridge to [bus 03] [26608.495947] pcieport 0000:02:01.0: bridge window [io 0x1000-0x1fff] [26608.513041] pcieport 0000:02:01.0: bridge window [mem 0xf8000000-0xf9ffffff] [26608.521771] pcieport 0000:02:01.0: bridge window [mem 0xfe200000-0xfe3fffff 64bit pref] [26608.647492] pcieport 0000:02:01.0: pciehp: Timeout on hotplug command 0x12e1 (issued 2167 msec ago) [26608.652270] pcieport 0000:02:01.0: pciehp: pciehp_set_indicators: SLOTCTRL 80 write cmd 1c0 On Tue, 1 Oct 2024 at 18:18, Maverickk 78 <maverickk1778@xxxxxxxxx> wrote: > > Hi Bjorn, > > Yes, it's a virtual x86 Qemu environment with rtl simulated pcie gen6 > switch hooked to the host controller. > > The simulation environment is 3rd party and my guess is it's a > passthrough(guessing) . > > I can confirm that msi is received to the Qemu host because the USP > port has f0, f1, f2, f3, f4 and f4 is an scsi end point function and > interrupts are used for command/response. > > I enabled a few more debugs, now I can see more information from > pciehp dumped into the kernel log. > > Thanks for the details, I was not aware that _OSC flags need to be > built by firmware to enable native PCIe hotplug. > > On Tue, 1 Oct 2024 at 00:58, Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote: > > > > On Sun, Sep 29, 2024 at 07:29:32PM +0530, Maverickk 78 wrote: > > > Hi Bjorn, > > > > > > I have a switch connecting to the Host bridge, one of the downstream > > > port(02:1.0) on the switch has the slot enabled. > > > > > > Appended pcie_ports=native along with pciehp.pciehp_force=1 > > > pciehp.pciehp_debug=1 to the cmdline and I see the driver creating symlink > > > to sysfs device node. > > > > > > Does this mean pciehp can handle the hotplug events? asking this because > > > none of the functions in pciehp_core listed in ftrace? > > > > From the dmesg log you attached: > > > > [ 0.000000] DMI: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-0-g155821a-20210629_105355-sharpie 04/01/2014 > > [ 0.000000] Hypervisor detected: KVM > > [ 0.408755] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-6.11.0+ root=UUID=f563804b-1b93-4921-90e1-4114c8111e8f ro modprobe.blacklist=mpt3sas ftrace=function_graph ftrace_graph_filter=*pcie* pciehp.pciehp_force=1 pciehp.pciehp_debug=1 pcie_ports=native quite splash crashkernel=512M-:192M vt.handoff=7 > > [ 1.640055] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 > > [ 1.736168] acpi PNP0A08:00: _OSC: platform does not support [PCIeHotplug LTR DPC] > > [ 1.738096] acpi PNP0A08:00: _OSC: OS now controls [SHPCHotplug PME AER PCIeCapability] > > [ 9.885390] pcieport 0000:02:01.0: pciehp: Slot #0 AttnBtn+ PwrCtrl+ MRL+ AttnInd+ PwrInd+ HotPlug+ Surprise+ Interlock- NoCompl- IbPresDis- LLActRep+ > > > > I assume this kernel is running as a KVM guest. The firmware _OSC > > says the platform (QEMU) doesn't support native PCIe hotplug, so > > host->native_pcie_hotplug will be false. But of course > > "pcie_ports=native" would set pcie_ports_native, so the portdrv > > get_port_device_capability() will set PCIE_PORT_SERVICE_HP, which > > allows pciehp to bind to 02:01.0. > > > > The "pcieport 0000:02:01.0: pciehp: Slot #0" line shows that > > pciehp_probe() was called. > > > > I don't know whether QEMU supports PCIe hotplug interrupts though. > > > > When do you expect pciehp to do something? Are you hotplugging a > > physical device that is passed through to this guest? > > > > Bjorn
