From: "Julian Ruess" <julianr@linux.ibm.com>
To: "Niklas Schnelle" <schnelle@linux.ibm.com>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Lukas Wunner" <lukas@wunner.de>
Cc: "Gerald Schaefer" <gerald.schaefer@linux.ibm.com>,
"Christian Borntraeger" <borntraeger@linux.ibm.com>,
"Gerd Bayer" <gbayer@linux.ibm.com>,
"Matthew Rosato" <mjrosato@linux.ibm.com>,
"Heiko Carstens" <hca@linux.ibm.com>,
"Vasily Gorbik" <gor@linux.ibm.com>,
"Alexander Gordeev" <agordeev@linux.ibm.com>,
"Sven Schnelle" <svens@linux.ibm.com>,
"Julian Ruess" <julianr@linux.ibm.com>,
"Peter Oberparleiter" <oberpar@linux.ibm.com>,
"Ramesh Errabolu" <ramesh@linux.ibm.com>,
<linux-s390@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-pci@vger.kernel.org>
Subject: Re: [PATCH v3] PCI: s390: Expose the UID as an arch specific PCI slot attribute
Date: Thu, 04 Dec 2025 10:27:32 +0100 [thread overview]
Message-ID: <DEPBQ734VDZG.34XHQ5Z0KKLLQ@linux.ibm.com> (raw)
In-Reply-To: <20251015-uid_slot-v3-1-44389895c1bb@linux.ibm.com>
On Wed Oct 15, 2025 at 3:42 PM CEST, Niklas Schnelle wrote:
> On s390, an individual PCI function can generally be identified by two
> identifiers, the FID and the UID. Which identifier is used depends on
> the scope and the platform configuration.
>
> The first identifier, the FID, is always available and identifies a PCI
> device uniquely within a machine. The FID may be virtualized by
> hypervisors, but on the LPAR level, the machine scope makes it
> impossible to create the same configuration based on FIDs on two
> different LPARs of the same machine, and difficult to reuse across
> machines.
>
> Such matching LPAR configurations are useful, though, allowing
> standardized setups and booting a Linux installation on different LPARs.
> To this end the UID, or user-defined identifier, was introduced. While
> it is only guaranteed to be unique within an LPAR and only if indicated
> by firmware, it allows users to replicate PCI device setups.
>
> On s390, which uses a machine hypervisor, a per PCI function hotplug
> model is used. The shortcoming with the UID then is, that it is not
> visible to the user without first attaching the PCI function and
> accessing the "uid" device attribute. The FID, on the other hand, is
> used as the slot name and is thus known even with the PCI function in
> standby.
>
> Remedy this shortcoming by providing the UID as an attribute on the slot
> allowing the user to identify a PCI function based on the UID without
> having to first attach it. Do this via a macro mechanism analogous to
> what was introduced by commit 265baca69a07 ("s390/pci: Stop usurping
> pdev->dev.groups") for the PCI device attributes.
>
> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> ---
> Note: I considered adding the UID as a generic "index" via the hotplug
> slot driver but felt like there is probably too little commonality on
> format and usage patterns.
>
> v2->v3:
> - Rebase on v6.18-rc1 and resolve conflict with recent s390 PCI sysfs change
> - Link to v2: https://lore.kernel.org/r/20251008-uid_slot-v2-1-ef22cef27741@linux.ibm.com
> ---
-- snip --
Feel free to add my
Reviewed-by: Julian Ruess <julianr@linux.ibm.com>
Thanks,
Julian
next prev parent reply other threads:[~2025-12-04 9:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-15 13:42 [PATCH v3] PCI: s390: Expose the UID as an arch specific PCI slot attribute Niklas Schnelle
2025-12-04 9:27 ` Julian Ruess [this message]
2025-12-04 12:45 ` Gerd Bayer
2025-12-04 13:09 ` Niklas Schnelle
2025-12-04 13:32 ` Gerd Bayer
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=DEPBQ734VDZG.34XHQ5Z0KKLLQ@linux.ibm.com \
--to=julianr@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=bhelgaas@google.com \
--cc=borntraeger@linux.ibm.com \
--cc=gbayer@linux.ibm.com \
--cc=gerald.schaefer@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--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=oberpar@linux.ibm.com \
--cc=ramesh@linux.ibm.com \
--cc=schnelle@linux.ibm.com \
--cc=svens@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