linux-kernel - Re: [RFC KERNEL PATCH v3 3/3] PCI/sysfs: Add gsi sysfs for pci

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: <BL1PR12MB5849A269A09CB3837F2B3FA9E78CA@BL1PR12MB5849.namprd12.prod.outlook.com>
Date:   Thu, 14 Dec 2023 09:03:26 +0000
From:   "Chen, Jiqian" <Jiqian.Chen@....com>
To:     Roger Pau Monné <roger.pau@...rix.com>
CC:     "Rafael J . Wysocki" <rafael@...nel.org>,
        Len Brown <lenb@...nel.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
        "xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>,
        "Deucher, Alexander" <Alexander.Deucher@....com>,
        "Koenig, Christian" <Christian.Koenig@....com>,
        "Huang, Ray" <Ray.Huang@....com>,
        "Chen, Jiqian" <Jiqian.Chen@....com>
Subject: Re: [RFC KERNEL PATCH v3 3/3] PCI/sysfs: Add gsi sysfs for pci_dev

On 2023/12/14 16:46, Roger Pau Monné wrote:
> On Thu, Dec 14, 2023 at 07:08:32AM +0000, Chen, Jiqian wrote:
>> On 2023/12/13 20:12, Roger Pau Monné wrote:
>>> On Wed, Dec 13, 2023 at 03:31:21AM +0000, Chen, Jiqian wrote:
>>>> On 2023/12/12 17:18, Roger Pau Monné wrote:
>>>>> On Tue, Dec 12, 2023 at 06:34:27AM +0000, Chen, Jiqian wrote:
>>>>>>
>>>>>> On 2023/12/12 01:57, Roger Pau Monné wrote:
>>>>>>> On Mon, Dec 11, 2023 at 12:15:19AM +0800, Jiqian Chen wrote:
>>>>>>>> There is a need for some scenarios to use gsi sysfs.
>>>>>>>> For example, when xen passthrough a device to dumU, it will
>>>>>>>> use gsi to map pirq, but currently userspace can't get gsi
>>>>>>>> number.
>>>>>>>> So, add gsi sysfs for that and for other potential scenarios.
>>>>>>>>
>>>>>>>> Co-developed-by: Huang Rui <ray.huang@....com>
>>>>>>>> Signed-off-by: Jiqian Chen <Jiqian.Chen@....com>
>>>>>>>> ---
>>>>>>>>  drivers/acpi/pci_irq.c  |  1 +
>>>>>>>>  drivers/pci/pci-sysfs.c | 11 +++++++++++
>>>>>>>>  include/linux/pci.h     |  2 ++
>>>>>>>>  3 files changed, 14 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
>>>>>>>> index 630fe0a34bc6..739a58755df2 100644
>>>>>>>> --- a/drivers/acpi/pci_irq.c
>>>>>>>> +++ b/drivers/acpi/pci_irq.c
>>>>>>>> @@ -449,6 +449,7 @@ int acpi_pci_irq_enable(struct pci_dev *dev)
>>>>>>>>  		kfree(entry);
>>>>>>>>  		return 0;
>>>>>>>>  	}
>>>>>>>> +	dev->gsi = gsi;
>>>>>>>
>>>>>>> It would be better if the gsi if fetched without requiring calling
>>>>>>> acpi_pci_irq_enable(), as the gsi doesn't require the interrupt to be
>>>>>>> enabled.  The gsi is known at boot time and won't change for the
>>>>>>> lifetime of the device.
>>>>>> Do you have any suggest places to do this?
>>>>>
>>>>> I'm not an expert on this, but drivers/pci/pci-sysfs.c would seem like
>>>>> a better place, together with the rest of the resources.
>>>> I'm not familiar with this too. But it seems pci-sysfs.c only creates sysfs node and supports the read/write method without initializing the values.
>>>> If want to initialize the value of gsi here. An approach to initialize it is to call acpi_pci_irq_lookup to get gsi number when the first time it is read?
>>>
>>> Hm, maybe, I don't really have much experience with sysfs, so don't
>>> know how nodes are usually initialized.
>> Maybe the maintainers of sysfs can give some suggest places to initialize the value of gsi.
>>
>>>
>>>>>
>>>>> Maybe my understanding is incorrect, but given the suggested placement
>>>>> in acpi_pci_irq_enable() I think the device would need to bind the
>>>>> interrupt in order for the gsi node to appear on sysfs?
>>>> No, gsi sysfs has existed there, in acpi_pci_irq_enable is to initialize the value of gsi.
>>>>
>>>>>
>>>>> Would the current approach work if the device is assigned to pciback
>>>>> on the kernel command line, and thus never owned by any driver in
>>>>> dom0?
>>>> If assigned to pciback, I think pciback will enable the device, and then acpi_pci_irq_enable will be called, and then the gsi will be initialized. So, current can work.
>>>
>>> This needs checking to be sure, I'm certainly not that familiar.  You
>>> would need to at least test that it works properly when the device is
>>> hidden using xen-pciback.hide=(SBDF) in the Linux kernel command line.
>> Sure, I have validated it on my side. Both the "Static assignment for built-in xen-pciback(xen-pciback.hide=(SBDF))" and the "Dynamic assignment with xl(sudo modprobe xen-pciback & sudo xl pci-assignable-add SBDF)" can work fine with current implementation.
> 
> Oh, OK, if that's the case I don't have much objection in doing the
> initialization in acpi_pci_irq_enable(), that's an internal Linux
> detail.  I mostly care about the GSI being exposed in sysfs in a
> non-Xen specific way.
Yes, current implementation is a Linux internal way, not a Xen specific. In baremetal Linux, I also can see gsi sysfs. Thank you.

> 
> Thanks, Roger.

-- 
Best regards,
Jiqian Chen.