From: Bjorn Helgaas <helgaas@kernel.org>
To: Farhan Ali <alifm@linux.ibm.com>
Cc: linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, lukas@wunner.de, alex@shazbot.org,
kbusch@kernel.org, clg@redhat.com, stable@vger.kernel.org,
schnelle@linux.ibm.com, mjrosato@linux.ibm.com
Subject: Re: [PATCH v11 1/9] PCI: Allow per function PCI slots
Date: Tue, 24 Mar 2026 16:55:13 -0500 [thread overview]
Message-ID: <20260324215513.GA1157029@bhelgaas> (raw)
In-Reply-To: <20260316191544.2279-2-alifm@linux.ibm.com>
On Mon, Mar 16, 2026 at 12:15:36PM -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.
I think this "pass-through" is from the hypervisor to Linux, i.e.,
what we think of as the host kernel, right?
> Currently, the kernel's PCI_SLOT() macro assigns the same pci_slot object
> to multifunction devices. This approach worked fine on s390 systems that
> only exposed virtual functions as individual PCI domains to the operating
> system. Since commit 44510d6fa0c0 ("s390/pci: Handling multifunctions")
> s390 supports exposing the topology of multifunction PCI devices by
> grouping them in a shared PCI domain. When attempting to reset a function
> through the hotplug driver, the shared slot assignment causes the wrong
> function to be reset instead of the intended one. It also leaks memory as
> we do create a pci_slot object for the function, but don't correctly free
> it in pci_slot_release().
This alludes to the patch fixing a reset issue, but I think it should
be more prominent, e.g., the reset and leak fixes could be a separate
paragraph. The subject line should also mention at least the reset
fix.
> Add a flag for struct pci_slot to allow per function PCI slots for
> functions managed through a hypervisor, which exposes individual PCI
> functions while retaining the topology. Since we can use all 8 bits
> for slot 'number' (for ARI devices), change slot 'number' u16 to
> account for special values -1 and PCI_SLOT_ALL_DEVICES.
> ...
> static ssize_t address_read_file(struct pci_slot *slot, char *buf)
> {
> - if (slot->number == 0xff)
> + if (slot->number == (u16)-1)
This "-1" is mentioned in the commit log, but I don't know where it
came from. I guess we must assign -1 as a default somewhere? Could
this be a #define to connect that assignment with this test?
> return sysfs_emit(buf, "%04x:%02x\n",
> pci_domain_nr(slot->bus),
> slot->bus->number);
next prev parent reply other threads:[~2026-03-24 21:55 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-16 19:15 [PATCH v11 0/9] Error recovery for vfio-pci devices on s390x Farhan Ali
2026-03-16 19:15 ` [PATCH v11 1/9] PCI: Allow per function PCI slots Farhan Ali
2026-03-24 21:55 ` Bjorn Helgaas [this message]
2026-03-24 23:08 ` Farhan Ali
2026-03-24 23:20 ` Bjorn Helgaas
2026-03-16 19:15 ` [PATCH v11 2/9] s390/pci: Add architecture specific resource/bus address translation Farhan Ali
2026-03-24 23:06 ` Bjorn Helgaas
2026-03-24 23:47 ` Farhan Ali
2026-03-25 11:58 ` Ilpo Järvinen
2026-03-25 17:44 ` Farhan Ali
2026-03-16 19:15 ` [PATCH v11 3/9] PCI: Avoid saving config space state if inaccessible Farhan Ali
2026-03-24 21:40 ` Bjorn Helgaas
2026-03-24 22:38 ` Farhan Ali
2026-03-24 22:52 ` Bjorn Helgaas
2026-03-16 19:15 ` [PATCH v11 4/9] PCI: Add additional checks for flr reset Farhan Ali
2026-03-24 22:49 ` Bjorn Helgaas
2026-03-24 23:22 ` Farhan Ali
2026-03-25 16:25 ` Alex Williamson
2026-03-25 18:40 ` Farhan Ali
2026-03-16 19:15 ` [PATCH v11 5/9] s390/pci: Update the logic for detecting passthrough device Farhan Ali
2026-03-25 16:46 ` Alex Williamson
2026-03-16 19:15 ` [PATCH v11 6/9] s390/pci: Store PCI error information for passthrough devices Farhan Ali
2026-03-25 17:01 ` Alex Williamson
2026-03-25 18:06 ` Farhan Ali
2026-03-16 19:15 ` [PATCH v11 7/9] vfio-pci/zdev: Add a device feature for error information Farhan Ali
2026-03-25 17:18 ` Alex Williamson
2026-03-16 19:15 ` [PATCH v11 8/9] vfio: Add a reset_done callback for vfio-pci driver Farhan Ali
2026-03-25 17:30 ` Alex Williamson
2026-03-16 19:15 ` [PATCH v11 9/9] vfio: Remove the pcie check for VFIO_PCI_ERR_IRQ_INDEX Farhan Ali
2026-03-24 21:26 ` Bjorn Helgaas
2026-03-24 22:30 ` Farhan Ali
2026-03-25 17:50 ` Alex Williamson
2026-03-24 19:34 ` [PATCH v11 0/9] Error recovery for vfio-pci devices on s390x Farhan Ali
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260324215513.GA1157029@bhelgaas \
--to=helgaas@kernel.org \
--cc=alex@shazbot.org \
--cc=alifm@linux.ibm.com \
--cc=clg@redhat.com \
--cc=kbusch@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mjrosato@linux.ibm.com \
--cc=schnelle@linux.ibm.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.