[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: "Chen, Jiqian" <Jiqian.Chen@xxxxxxx>
  • Date: Wed, 13 Dec 2023 03:31:21 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=JYgQuZUw/YxUYU1oh0lyRWrpXbyROUacQ8m6s5auS74=; b=I2gWK+F82a7MhlcyDNMOY62JCrhi345Z6riaFB1Dsvj795J9foVeoKBY+IP3fbRBCQW3o2zLscXAgH8QV8R3OlyUEMytNSpvLaddjcyJ3fdfIm2tDOs4uh0admvJaJ2CaIJQZl+N+a7O+Auwv42cg2cB6uQD3GXCEcRbuoHQM/fqd6dJsTX5KCPwNJNqdmhGOvAEQzxSI9lj9GjyaW7kj3fAIDv3D48bzD10SzBtOSZ7k8+7qlZL200IYUhmki7SCigLKWSPIr0K+p1sFITXEgunDp6nhDffLGrRG2wceM0dBZ/ekNgyT8aEo8k2Mnw8r0hsGkXux8iltxKm4dj1cA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a0KmnSGD+XtvqwhWshbYe5ojnkJq4fVvtGSvTCvwaBpkQi5qPfhPHcxsYrmNk380Jdq3ppya5L9dpNn+Fpe92UDO+OMyJnEZkEAyL6VQNneNBqHglVlcR9b0VCARlJh5RLPORXJlz37KNolSczlQzrZxrX9JiYyJq6WjLYvxjw7YIenRnel8QnwUshXKRGfcv+C2SVTJj4w3/frTJGk42D96XSm6NZ4unjnkDbKenjO+WlqSX4TIYNeF7Nr2lCAbWG4KYErQ9SnoZzrv/5TPom1VuOR2em/6ML0ifdibo5URPWRd21WTMOmsqMy6bhwuxPaFszu1k8E01LjMtIojuw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com;
  • Cc: "Rafael J . Wysocki" <rafael@xxxxxxxxxx>, Len Brown <lenb@xxxxxxxxxx>, Bjorn Helgaas <bhelgaas@xxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, "linux-pci@xxxxxxxxxxxxxxx" <linux-pci@xxxxxxxxxxxxxxx>, "linux-acpi@xxxxxxxxxxxxxxx" <linux-acpi@xxxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "Deucher, Alexander" <Alexander.Deucher@xxxxxxx>, "Koenig, Christian" <Christian.Koenig@xxxxxxx>, "Huang, Ray" <Ray.Huang@xxxxxxx>, "Chen, Jiqian" <Jiqian.Chen@xxxxxxx>
  • Delivery-date: Wed, 13 Dec 2023 03:31:39 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHaK4Q534ViUL7xiE2p4ymr6ObEurCkX+6AgAFU/YD//6xNgIABr6aA
  • Thread-topic: [RFC KERNEL PATCH v3 3/3] PCI/sysfs: Add gsi sysfs for pci_dev

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?

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

> 
>>>
>>>>  
>>>>    rc = acpi_register_gsi(&dev->dev, gsi, triggering, polarity);
>>>>    if (rc < 0) {
>>>> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
>>>> index 2321fdfefd7d..c51df88d079e 100644
>>>> --- a/drivers/pci/pci-sysfs.c
>>>> +++ b/drivers/pci/pci-sysfs.c
>>>> @@ -71,6 +71,16 @@ static ssize_t irq_show(struct device *dev,
>>>>  }
>>>>  static DEVICE_ATTR_RO(irq);
>>>>  
>>>> +static ssize_t gsi_show(struct device *dev,
>>>> +                  struct device_attribute *attr,
>>>> +                  char *buf)
>>>> +{
>>>> +  struct pci_dev *pdev = to_pci_dev(dev);
>>>
>>> const
>> Do you mean "const struct pci_dev *pdev = to_pci_dev(dev);" ?
> 
> Yup.
> 
> Thanks, Roger.

-- 
Best regards,
Jiqian Chen.

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.