archive mirror
 help / color / mirror / Atom feed
From: Niklas Schnelle <>
To: Greg Kroah-Hartman <>
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 13:02:51 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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.
"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.

>> +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. 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

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.

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.


> thanks,
> greg k-h

  reply	other threads:[~2021-02-04 12:06 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 [this message]
2021-02-04 13:38       ` Greg Kroah-Hartman
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).