Re: [RFC KERNEL PATCH v3 3/3] PCI/sysfs: Add gsi sysfs for pci_dev

["Chen, Jiqian" <Jiqian.Chen@xxxxxxx>]

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@xxxxxxx>
>>>>>> Signed-off-by: Jiqian Chen <Jiqian.Chen@xxxxxxx>
>>>>>> ---
>>>>>>  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.

> 
> Thanks, Roger.

-- 
Best regards,
Jiqian Chen.