linux-kernel - Re: [PATCH v5 9/9] PCI: Add a new 'boot

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] [day] [month] [year] [list]
Message-ID: <5cc01163-1feb-4a18-8060-27f4da39b2e4@kernel.org>
Date: Thu, 26 Jun 2025 18:33:15 -0500
From: Mario Limonciello <superm1@...nel.org>
To: Bjorn Helgaas <helgaas@...nel.org>
Cc: Bjorn Helgaas <bhelgaas@...gle.com>,
 Alex Deucher <alexander.deucher@....com>,
 Christian König <christian.koenig@....com>,
 David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
 Lukas Wunner <lukas@...ner.de>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 David Woodhouse <dwmw2@...radead.org>, Lu Baolu <baolu.lu@...ux.intel.com>,
 Joerg Roedel <joro@...tes.org>, Will Deacon <will@...nel.org>,
 Robin Murphy <robin.murphy@....com>,
 Alex Williamson <alex.williamson@...hat.com>,
 Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
 "open list:DRM DRIVERS" <dri-devel@...ts.freedesktop.org>,
 open list <linux-kernel@...r.kernel.org>,
 "open list:INTEL IOMMU (VT-d)" <iommu@...ts.linux.dev>,
 "open list:PCI SUBSYSTEM" <linux-pci@...r.kernel.org>,
 "open list:VFIO DRIVER" <kvm@...r.kernel.org>,
 "open list:SOUND" <linux-sound@...r.kernel.org>,
 Daniel Dadap <ddadap@...dia.com>,
 Mario Limonciello <mario.limonciello@....com>
Subject: Re: [PATCH v5 9/9] PCI: Add a new 'boot_display' attribute



On 6/26/25 4:47 PM, Bjorn Helgaas wrote:
> On Thu, Jun 26, 2025 at 04:12:21PM -0500, Mario Limonciello wrote:
>> On 6/26/2025 3:45 PM, Bjorn Helgaas wrote:
>>> On Tue, Jun 24, 2025 at 03:30:42PM -0500, Mario Limonciello wrote:
>>>> From: Mario Limonciello <mario.limonciello@....com>
>>>>
>>>> On systems with multiple GPUs there can be uncertainty which GPU is the
>>>> primary one used to drive the display at bootup. In order to disambiguate
>>>> this add a new sysfs attribute 'boot_display' that uses the output of
>>>> video_is_primary_device() to populate whether a PCI device was used for
>>>> driving the display.
>>>>
>>>> Signed-off-by: Mario Limonciello <mario.limonciello@....com>
>>>
>>> Acked-by: Bjorn Helgaas <bhelgaas@...gle.com>
>>>
>>> Question below.
>>>
>>>> ---
>>>> v4:
>>>>    * new patch
>>>> ---
>>>>    Documentation/ABI/testing/sysfs-bus-pci |  9 +++++++++
>>>>    drivers/pci/pci-sysfs.c                 | 14 ++++++++++++++
>>>>    2 files changed, 23 insertions(+)
>>>>
>>>> diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci
>>>> index 69f952fffec72..897cfc1b0de0f 100644
>>>> --- a/Documentation/ABI/testing/sysfs-bus-pci
>>>> +++ b/Documentation/ABI/testing/sysfs-bus-pci
>>>> @@ -612,3 +612,12 @@ Description:
>>>>    		  # ls doe_features
>>>>    		  0001:01        0001:02        doe_discovery
>>>> +
>>>> +What:		/sys/bus/pci/devices/.../boot_display
>>>> +Date:		October 2025
>>>> +Contact:	Linux PCI developers <linux-pci@...r.kernel.org>
>>>> +Description:
>>>> +		This file indicates whether the device was used as a boot
>>>> +		display. If the device was used as the boot display, the file
>>>> +		will contain "1". If the device is a display device but wasn't
>>>> +		used as a boot display, the file will contain "0".
>>>
>>> Is there a reason to expose this file if it wasn't a boot display
>>> device?  Maybe it doesn't need to exist at all unless it contains "1"?
>>
>> I was mostly thinking that it's a handy way for userspace to know whether
>> the kernel even supports this feature.  If userspace sees that file on any
>> GPU as it walks a list then it knows it can use that for a hint.
>>
>> But if you would rather it only shows up for the boot display yes it's
>> possible to do I think.  It's just more complexity to the visibility lookup
>> to also call video_is_primary_device().
> 
> I think for a singleton situation like this it makes more sense to
> only expose the file for one device, not several files where only one
> of them contains "1".

I did an experiment with this but the PCI resources aren't ready at the 
time visibility is determined.

So either:
* the sysfs file creation needs to be deferred similar to 
pci_create_resource_files() does

or

* call to sysfs_update_group() is needed to recalculate visibility.

> 
>>>> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
>>>> index 268c69daa4d57..5bbf79b1b953d 100644
>>>> --- a/drivers/pci/pci-sysfs.c
>>>> +++ b/drivers/pci/pci-sysfs.c
>>>> @@ -30,6 +30,7 @@
>>>>    #include <linux/msi.h>
>>>>    #include <linux/of.h>
>>>>    #include <linux/aperture.h>
>>>> +#include <asm/video.h>
>>>>    #include "pci.h"
>>>>    #ifndef ARCH_PCI_DEV_GROUPS
>>>> @@ -679,6 +680,13 @@ const struct attribute_group *pcibus_groups[] = {
>>>>    	NULL,
>>>>    };
>>>> +static ssize_t boot_display_show(struct device *dev, struct device_attribute *attr,
>>>> +				 char *buf)
>>>> +{
>>>> +	return sysfs_emit(buf, "%u\n", video_is_primary_device(dev));
>>>> +}
>>>> +static DEVICE_ATTR_RO(boot_display);
>>>> +
>>>>    static ssize_t boot_vga_show(struct device *dev, struct device_attribute *attr,
>>>>    			     char *buf)
>>>>    {
>>>> @@ -1698,6 +1706,7 @@ late_initcall(pci_sysfs_init);
>>>>    static struct attribute *pci_dev_dev_attrs[] = {
>>>>    	&dev_attr_boot_vga.attr,
>>>> +	&dev_attr_boot_display.attr,
>>>>    	NULL,
>>>>    };
>>>> @@ -1710,6 +1719,11 @@ static umode_t pci_dev_attrs_are_visible(struct kobject *kobj,
>>>>    	if (a == &dev_attr_boot_vga.attr && pci_is_vga(pdev))
>>>>    		return a->mode;
>>>> +#ifdef CONFIG_VIDEO
>>>> +	if (a == &dev_attr_boot_display.attr && pci_is_display(pdev))
>>>> +		return a->mode;
>>>> +#endif
>>>> +
>>>>    	return 0;
>>>>    }
>>>> -- 
>>>> 2.43.0
>>>>
>>