lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <DEPBQ734VDZG.34XHQ5Z0KKLLQ@linux.ibm.com>
Date: Thu, 04 Dec 2025 10:27:32 +0100
From: "Julian Ruess" <julianr@...ux.ibm.com>
To: "Niklas Schnelle" <schnelle@...ux.ibm.com>,
        "Bjorn Helgaas"
 <bhelgaas@...gle.com>,
        "Lukas Wunner" <lukas@...ner.de>
Cc: "Gerald Schaefer" <gerald.schaefer@...ux.ibm.com>,
        "Christian
 Borntraeger" <borntraeger@...ux.ibm.com>,
        "Gerd Bayer"
 <gbayer@...ux.ibm.com>,
        "Matthew Rosato" <mjrosato@...ux.ibm.com>,
        "Heiko
 Carstens" <hca@...ux.ibm.com>,
        "Vasily Gorbik" <gor@...ux.ibm.com>,
        "Alexander Gordeev" <agordeev@...ux.ibm.com>,
        "Sven Schnelle"
 <svens@...ux.ibm.com>,
        "Julian Ruess" <julianr@...ux.ibm.com>,
        "Peter
 Oberparleiter" <oberpar@...ux.ibm.com>,
        "Ramesh Errabolu"
 <ramesh@...ux.ibm.com>,
        <linux-s390@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-pci@...r.kernel.org>
Subject: Re: [PATCH v3] PCI: s390: Expose the UID as an arch specific PCI
 slot attribute

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@...ux.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@...ux.ibm.com>

Thanks,
Julian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ