Re: [PATCH v6 2/2] PCI: s390: Expose the UID as an arch specific PCI slot attribute

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

On Fri, 2026-04-03 at 10:19 -0700, Farhan Ali wrote:
> On 4/2/2026 1:34 PM, 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.
> > 
> > Reviewed-by: Gerd Bayer <gbayer@linux.ibm.com>
> > Reviewed-by: Julian Ruess <julianr@linux.ibm.com>
> > Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> > ---
> >   Documentation/arch/s390/pci.rst |  7 +++++++
> >   arch/s390/include/asm/pci.h     |  4 ++++
> >   arch/s390/pci/pci_sysfs.c       | 20 ++++++++++++++++++++
> >   drivers/pci/slot.c              | 13 ++++++++++++-
> >   4 files changed, 43 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/arch/s390/pci.rst b/Documentation/arch/s390/pci.rst
> > index 31c24ed5506f1fc07f89821f67a814118514f441..4c0f35c8a5588eee3cf0d596e0057f24b3ed079c 100644
> > --- a/Documentation/arch/s390/pci.rst
> > +++ b/Documentation/arch/s390/pci.rst
> > @@ -57,6 +57,13 @@ Entries specific to zPCI functions and entries that hold zPCI information.
> >   
> >     - /sys/bus/pci/slots/XXXXXXXX/power
> >   
> > +  In addition to using the FID as the name of the slot the slot directory
> > +  also contains the following s390 specific slot attributes.
> > +
> > +  - uid:
> > +    The User-defined identifier (UID) of the function which may be configured
> > +    by this slot. See also the corresponding attribute of the device.
> > +
> >     A physical function that currently supports a virtual function cannot be
> >     powered off until all virtual functions are removed with:
> >     echo 0 > /sys/bus/pci/devices/DDDD:BB:dd.f/sriov_numvf
> > diff --git a/arch/s390/include/asm/pci.h b/arch/s390/include/asm/pci.h
> > index c0ff19dab5807c7e1aabb48a0e9436aac45ec97d..5dcf35f0f325f5f44b28109a1c8d9aef18401035 100644
> > --- a/arch/s390/include/asm/pci.h
> > +++ b/arch/s390/include/asm/pci.h
> > @@ -208,6 +208,10 @@ extern const struct attribute_group zpci_ident_attr_group;
> >   			    &pfip_attr_group,		 \
> >   			    &zpci_ident_attr_group,
> >   
> > +extern const struct attribute_group zpci_slot_attr_group;
> > +
> > +#define ARCH_PCI_SLOT_GROUPS (&zpci_slot_attr_group)
> > +
> >   extern unsigned int s390_pci_force_floating __initdata;
> >   extern unsigned int s390_pci_no_rid;
> >   
> > diff --git a/arch/s390/pci/pci_sysfs.c b/arch/s390/pci/pci_sysfs.c
> > index c2444a23e26c4218832bb91930b5f0ffd498d28f..d98d97df792adb3c7e415a8d374cc2f3a65fbb52 100644
> > --- a/arch/s390/pci/pci_sysfs.c
> > +++ b/arch/s390/pci/pci_sysfs.c
> > @@ -187,6 +187,17 @@ static ssize_t index_show(struct device *dev,
> >   }
> >   static DEVICE_ATTR_RO(index);
> >   
> > +static ssize_t zpci_uid_slot_show(struct pci_slot *slot, char *buf)
> > +{
> > +	struct zpci_dev *zdev = container_of(slot->hotplug, struct zpci_dev,
> > +					     hotplug_slot);
> > +
> > +	return sysfs_emit(buf, "0x%x\n", zdev->uid);
> > +}
> 
> I think the way we assign the same pci slot to multifunctions (PF and VF 
> on the same LPAR), IIUC we could possibly display the wrong uid here. I 
> am hoping my patch [1] can fix this. I am curious, is there any 
> s390-tool that would use the uid? Though this would only impact the NETD 
> devices on newer machines, so I don't know if we want to gate this 
> behind my patch?
> 
> [1] https://lore.kernel.org/all/20260330174011.1161-2-alifm@linux.ibm.com/
> 
> Thanks
> 
> Farhan
> 
> 

In my testing the UIDs for NETD VFs were correct. This is because there
is a bit of an asymmetry in the wrong slot assignment. Without your
patch pdev->slot gets set to the wrong slot but the correct slot and
hotplug slot still exist and are reachable via the sysfs kobjects or
zdev->hotplug_slot. This is also why we do have the correct
/sys/bus/pci/slots/<FID>/ directory and why the issue of wrong slot
assignment only came up via the reset mechanism not e.g. when trying to
deconfigure a PCI function.

As for tools using this attribute there is work ongoing to add PCI
support to lszdev/chzdev and these would utilize the UID in the slot
directory for listing the PCI functions as well as by generating udev
rules based on the UID. See also Ramesh's patch for adding the missing
uevent file in /sys/bus/pci/slots/*/ for cold plug[0].

Thanks,
Niklas

[0]
https://lore.kernel.org/lkml/20260401163152.632779-1-ramesh@linux.ibm.com/