From: Niklas Schnelle <schnelle@linux.ibm.com>
To: Farhan Ali <alifm@linux.ibm.com>,
linux-s390@vger.kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
Cc: alex.williamson@redhat.com, helgaas@kernel.org, clg@redhat.com,
mjrosato@linux.ibm.com
Subject: Re: [PATCH v4 04/10] s390/pci: Add architecture specific resource/bus address translation
Date: Thu, 25 Sep 2025 12:54:07 +0200 [thread overview]
Message-ID: <2d049d60868c0f61e53e70a73881f8674368537a.camel@linux.ibm.com> (raw)
In-Reply-To: <20250924171628.826-5-alifm@linux.ibm.com>
On Wed, 2025-09-24 at 10:16 -0700, Farhan Ali wrote:
> On s390 today we overwrite the PCI BAR resource address to either an
> artificial cookie address or MIO address.
>
I'm not sure "overwrite" fits here. Maybe just "are" and also use the
plural "addresses" and drop the "we" so:
"On s390 today PCI BAR resource addresses are either artificial cookie
addresses or MIO addresses". Then also adjust for the plural below with
"these addresses are".
Backghround: The resource addresses are CPU addresses used for MMIO. On
s390 we either have to adapt the old PCI instructions, which are
distinctly not memory mapped for a memory mapping based API via the
address cookie / zpci_iomap mechanismm, or if we have memory-I/O (MIO)
support, use the MIO addresses + memory mapped PCI instructions. Even
the MIO addresses may not match the bus addresses.
> However this address is different
> from the bus address of the BARs programmed by firmware. The artificial
> cookie address was created to index into an array of function handles
> (zpci_iomap_start). The MIO (mapped I/O) addresses are provided by firmware
> but maybe different from the bus address. This creates an issue when trying
Nit: "may be different from the corresponding bus addresses."
> to convert the BAR resource address to bus address using the generic
> pcibios_resource_to_bus().
>
> Implement an architecture specific pcibios_resource_to_bus() function to
> correctly translate PCI BAR resource addresses to bus addresses for s390.
> Similarly add architecture specific pcibios_bus_to_resource function to do
> the reverse translation.
>
> Signed-off-by: Farhan Ali <alifm@linux.ibm.com>
> ---
> arch/s390/pci/pci.c | 74 +++++++++++++++++++++++++++++++++++++++
> drivers/pci/host-bridge.c | 4 +--
> 2 files changed, 76 insertions(+), 2 deletions(-)
>
> diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c
> index cd6676c2d602..3992ba44e1cf 100644
> --- a/arch/s390/pci/pci.c
> +++ b/arch/s390/pci/pci.c
> @@ -264,6 +264,80 @@ resource_size_t pcibios_align_resource(void *data, const struct resource *res,
> return 0;
> }
>
> +void pcibios_resource_to_bus(struct pci_bus *bus, struct pci_bus_region *region,
> + struct resource *res)
> +{
> + struct zpci_bus *zbus = bus->sysdata;
> + struct zpci_bar_struct *zbar;
> + struct zpci_dev *zdev;
> +
> + region->start = res->start;
> + region->end = res->end;
When we don't find a BAR matching the resource this would become the
region used. I'm not sure what a better value would be if we don't find
a match though and that should hopefully not happen in sensible uses.
Also this would keep the existing behavior so seems fine.
> +
> + for (int i = 0; i < ZPCI_FUNCTIONS_PER_BUS; i++) {
> + int j = 0;
> +
> + zbar = NULL;
> + zdev = zbus->function[i];
> + if (!zdev)
> + continue;
> +
> + for (j = 0; j < PCI_STD_NUM_BARS; j++) {
> + if (zdev->bars[j].res->start == res->start &&
> + zdev->bars[j].res->end == res->end &&
> + res->flags & IORESOURCE_MEM) {
> + zbar = &zdev->bars[j];
> + break;
> + }
> + }
> +
> + if (zbar) {
> + /* only MMIO is supported */
> + region->start = zbar->val & PCI_BASE_ADDRESS_MEM_MASK;
> + if (zbar->val & PCI_BASE_ADDRESS_MEM_TYPE_64)
> + region->start |= (u64)zdev->bars[j + 1].val << 32;
> +
> + region->end = region->start + (1UL << zbar->size) - 1;
> + return;
> + }
> + }
> +}
> +
> +void pcibios_bus_to_resource(struct pci_bus *bus, struct resource *res,
> + struct pci_bus_region *region)
> +{
> + struct zpci_bus *zbus = bus->sysdata;
> + struct zpci_dev *zdev;
> + resource_size_t start, end;
> +
> + res->start = region->start;
> + res->end = region->end;
Similar to above. One thought though, I think we could set res->flags
!= IORESOURCE_UNSET | IORESOURCE_DISABLED. Of course that would have to
be moved after the loop so it only takes effect when we don't find a
match.
> +
> + for (int i = 0; i < ZPCI_FUNCTIONS_PER_BUS; i++) {
> + zdev = zbus->function[i];
> + if (!zdev || !zdev->has_resources)
> + continue;
> +
> + for (int j = 0; j < PCI_STD_NUM_BARS; j++) {
> + if (!zdev->bars[j].size)
> + continue;
> +
> + /* only MMIO is supported */
> + start = zdev->bars[j].val & PCI_BASE_ADDRESS_MEM_MASK;
> + if (zdev->bars[j].val & PCI_BASE_ADDRESS_MEM_TYPE_64)
> + start |= (u64)zdev->bars[j + 1].val << 32;
> +
> + end = start + (1UL << zdev->bars[j].size) - 1;
> +
> + if (start == region->start && end == region->end) {
> + res->start = zdev->bars[j].res->start;
> + res->end = zdev->bars[j].res->end;
> + return;
> + }
> + }
> + }
> +}
> +
--- snip ---
With or without my suggestion this clearly looks more correct than what
we had so far, even though that hasn't caused issues as far as I'm
aware until your BAR restoration change.
Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com>
next prev parent reply other threads:[~2025-09-25 10:54 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-24 17:16 [PATCH v4 00/10] Error recovery for vfio-pci devices on s390x Farhan Ali
2025-09-24 17:16 ` [PATCH v4 01/10] PCI: Avoid saving error values for config space Farhan Ali
2025-10-01 15:15 ` Benjamin Block
2025-10-01 17:12 ` Farhan Ali
2025-10-02 9:16 ` Benjamin Block
2025-10-04 14:54 ` Lukas Wunner
2025-10-06 17:54 ` Farhan Ali
2025-10-06 19:26 ` Lukas Wunner
2025-10-06 21:35 ` Farhan Ali
2025-10-08 13:34 ` Lukas Wunner
2025-10-08 17:56 ` Farhan Ali
2025-10-08 18:14 ` Lukas Wunner
2025-10-08 21:55 ` Farhan Ali
2025-10-09 4:52 ` Lukas Wunner
2025-10-09 17:02 ` Farhan Ali
2025-10-12 6:43 ` Lukas Wunner
2025-10-09 9:12 ` Niklas Schnelle
2025-10-12 6:34 ` Lukas Wunner
2025-10-14 12:07 ` Niklas Schnelle
2025-10-16 21:00 ` Farhan Ali
2025-10-19 14:34 ` Lukas Wunner
2025-10-20 8:59 ` Niklas Schnelle
2025-11-22 10:58 ` Lukas Wunner
2025-09-24 17:16 ` [PATCH v4 02/10] PCI: Add additional checks for flr reset Farhan Ali
2025-09-30 10:03 ` Benjamin Block
2025-09-30 17:04 ` Farhan Ali
2025-10-01 8:33 ` Benjamin Block
2025-10-01 14:37 ` Benjamin Block
2025-09-24 17:16 ` [PATCH v4 03/10] PCI: Allow per function PCI slots Farhan Ali
2025-10-01 14:34 ` Benjamin Block
2025-09-24 17:16 ` [PATCH v4 04/10] s390/pci: Add architecture specific resource/bus address translation Farhan Ali
2025-09-25 10:54 ` Niklas Schnelle [this message]
2025-10-01 16:04 ` Benjamin Block
2025-10-01 18:01 ` Farhan Ali
2025-10-02 12:58 ` Niklas Schnelle
2025-10-02 17:00 ` Bjorn Helgaas
2025-10-02 17:16 ` Ilpo Järvinen
2025-10-02 18:14 ` Niklas Schnelle
2025-09-24 17:16 ` [PATCH v4 05/10] s390/pci: Restore IRQ unconditionally for the zPCI device Farhan Ali
2025-09-24 17:16 ` [PATCH v4 06/10] s390/pci: Update the logic for detecting passthrough device Farhan Ali
2025-09-24 17:16 ` [PATCH v4 07/10] s390/pci: Store PCI error information for passthrough devices Farhan Ali
2025-09-25 14:28 ` Niklas Schnelle
2025-09-25 16:29 ` Farhan Ali
2025-09-24 17:16 ` [PATCH v4 08/10] vfio-pci/zdev: Add a device feature for error information Farhan Ali
2025-09-25 8:04 ` kernel test robot
2025-09-24 17:16 ` [PATCH v4 09/10] vfio: Add a reset_done callback for vfio-pci driver Farhan Ali
2025-09-24 17:16 ` [PATCH v4 10/10] vfio: Remove the pcie check for VFIO_PCI_ERR_IRQ_INDEX 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=2d049d60868c0f61e53e70a73881f8674368537a.camel@linux.ibm.com \
--to=schnelle@linux.ibm.com \
--cc=alex.williamson@redhat.com \
--cc=alifm@linux.ibm.com \
--cc=clg@redhat.com \
--cc=helgaas@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mjrosato@linux.ibm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).