Re: [PATCH v23 2/5] PCI: Allow per function PCI slots to fix slot reset on s390

[Niklas Schnelle <schnelle@linux.ibm.com>]

On Thu, 2026-08-13 at 18:25 -0500, Bjorn Helgaas wrote:
> On Wed, Aug 05, 2026 at 09:55:15AM -0700, Farhan Ali wrote:
> > On s390 systems, which use a machine level hypervisor, PCI devices are
> > always accessed through a form of PCI pass-through which fundamentally
> > operates on a per PCI function granularity. This is also reflected in the
> > s390 PCI hotplug driver which creates hotplug slots for individual PCI
> > functions. Its reset_slot() function, which is a wrapper for
> > zpci_hot_reset_device(), thus also resets individual functions.
> 
> Sorry to come back to this yet again.  I understand the issue with
> the wrong pci_slot being assigned for these s390 functions.
> 
> What I don't understand is why we would use slot_reset() in the first
> place.  I would expect FLR instead.
> 
> The hotplug slot_reset() path is used by pci_reset_bus_function().
> But given the order in pci_reset_fn_methods[], we would typically try
> pcie_reset_flr() first, and we would only get to
> pci_reset_bus_function() if FLR and the other resets are not
> available.
> 
> Since these are actually multi-function devices, I'm surprised that
> they wouldn't advertise FLR support.
> 


Hi Bjorn,

Good question. The problem isn't that FLR isn't advertised or
unsupported. Rather we end up needing to use the slot reset when the
platform has put the PCI function in the architected error state which
blocks both MMIO and DMA similar to DPC and which we can only get out
of with the platform specific CLP Set PCI Function Disable/Enable
hypercalls. FLR still works if you have a function that wasn't put in
the error state but for most real world errors as well as some service
scenarios we do end up in the error state where a FLR won't work.

To give an example for a service scenario because it's pretty neat. We
have up to 4 drawers of CPUs acting as a single SMP system as well as
multiple I/O cages with the PCIe cards in them. Now each I/O cage is
connected to two different PCIe root complexes on two different drawers
with only one link active. So one thing we can do is to migrate all
workload off a drawer and then swap over to the alternate root complex
with a single error event and one such zpci_hot_reset_device(). Then
with a CPU drawer evacuated you can actually replace CPUs without any
downtime beyond that reset while staying within a single machine.

Thanks,
Niklas