archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <>
To: Niklas Schnelle <>
Cc: Bjorn Helgaas <>,,,,
	Peter Oberparleiter <>,
	Viktor Mihajlovski <>
Subject: Re: [RFC v2 1/1] PCI: Add s390 specific UID uniqueness attribute
Date: Thu, 4 Feb 2021 14:38:44 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, Feb 04, 2021 at 01:02:51PM +0100, Niklas Schnelle wrote:
> On 2/4/21 11:40 AM, Greg Kroah-Hartman wrote:
> > On Thu, Feb 04, 2021 at 10:43:53AM +0100, Niklas Schnelle wrote:
> >> The global UID uniqueness attribute exposes whether the platform
> >> guarantees that the user-defined per-device UID attribute values
> >> (/sys/bus/pci/device/<dev>/uid) are unique and can thus be used as
> >> a global identifier for the associated PCI device. With this commit
> >> it is exposed at /sys/bus/pci/zpci/unique_uids
> >>
> >> Signed-off-by: Niklas Schnelle <>
> >> ---
> >>  Documentation/ABI/testing/sysfs-bus-pci |  9 +++++++++
> >>  drivers/pci/pci-sysfs.c                 | 21 +++++++++++++++++++++
> >>  2 files changed, 30 insertions(+)
> >>
> >> diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci
> >> index 25c9c39770c6..812dd9d3f80d 100644
> >> --- a/Documentation/ABI/testing/sysfs-bus-pci
> >> +++ b/Documentation/ABI/testing/sysfs-bus-pci
> >> @@ -375,3 +375,12 @@ Description:
> >>  		The value comes from the PCI kernel device state and can be one
> >>  		of: "unknown", "error", "D0", D1", "D2", "D3hot", "D3cold".
> >>  		The file is read only.
> >> +What:		/sys/bus/pci/zpci/unique_uids
> > 
> > No blank line before this new line?
> Good catch, thanks!
> > 
> > And why "zpci"?
> There doesn't seem to be a precedent for arch specific attributes under
> /sys/bus/pci so I went with a separate group for the RFC.

Why?  There's nothing arch-specific here, right?  Either the file is
present or not.

> "zpci" since that's what we've been calling the s390 specific PCI.
> I'm not attached to that name or having a separate group, from
> my perspective /sys/bus/pci/unique_uids would actually be ideal
> if Bjorn is okay with that, we don't currently foresee any additional
> global attributes and no one else seems to have them but
> one never knows and a separate group would then of course,
> well group them.

Why not just a simple file, no need for arch-specific names if this
really can show up under other arches?

> >> +Date:		February 2021
> >> +Contact:	Niklas Schnelle <>
> >> +Description:
> >> +		This attribute exposes the global state of UID Uniqueness on an
> >> +		s390 Linux system. If this file contains '1' the per-device UID
> >> +		attribute is guaranteed to provide a unique user defined
> >> +		identifier for that PCI device. If this file contains '0' UIDs
> >> +		may collide and do not provide a unique identifier.
> > 
> > What are they "colliding" with?  And where does the UID come from, the
> > device itself or somewhere else?
> If this attribute is 0 multiple PCI devices seen by Linux may have the same UID i.e.
> they may collide with each other on the same Linux instance.

So can't userspace figure this out on its own?

> The
> UIDs are exposed under /sys/bus/pci/devices/<dev>/uid. Even if the attribute is 1
> multiple Linux instances will often see the same UID. The main use case
> we currently envision is naming PCI based network interfaces "eno<UID>"
> which of course only works if the UIDs are unique for that Linux.
> On the same mainframe multiple Linux instances may then e.g. use the same
> UID for VFs from the same physical PCI network card or different cards
> but the same physical network all defined by an administrator/management
> system.
> The UIDs come from the platform/firmware/hypervisor and are provided
> for each device by the CLP List PCI Functions "instruction" that is used
> on s390x where an OS can't probe the physical PCI bus but instead
> that is done by firmware. On QEMU/KVM they can be set on the QEMU cli,
> on our machine hypervisor they are defined by the machine administrator/management
> software as part of the definition of VMs/Partitions on that mainframe which includes
> everything from the number of CPUs, memory, I/O devices etc. With the exposed UID uniqueness
> attribute the platform then certifies that it will ensure that a UID is set to
> a unique non-zero value. I can of course add more of this explanation
> in the documentation too.

Please explain it more, but why would userspace care about this?  If
userspace sees a UID "collision" then it just adds something else to the
end of the name to make it unique.

What is it supposed to do differently based on the value/presense of
this file?

> Both the uniqueness guarantee (this attribute) as well as the UIDs themselves
> are part of the Z (s390x) architecture so fall under the mainframe typical
> backwards compatibility considerations.

So what can userspace do with this?  What tool is going to rely on this?


greg k-h

  reply	other threads:[~2021-02-04 13:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-04  9:43 [RFC v2 0/1] s390/pci: expose UID checking state in sysfs Niklas Schnelle
2021-02-04  9:43 ` [RFC v2 1/1] PCI: Add s390 specific UID uniqueness attribute Niklas Schnelle
2021-02-04 10:40   ` Greg Kroah-Hartman
2021-02-04 12:02     ` Niklas Schnelle
2021-02-04 13:38       ` Greg Kroah-Hartman [this message]
2021-02-04 14:41         ` Niklas Schnelle

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \

* 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).