[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: Thu, 14 Dec 2023 09:03:26 +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=qiD1twIm+7M1Z3FKTgqVyLuFi2s6IY/iZq7/xn5tyCk=; b=F/ZtMkJXDGlaE7xIZZ6OrTPWGnWi+CowOOlxwDOP6hsaivyFHwLcHOk7jO5f+P18Ksbi+jaLtKzgAYWolMYQAznd1hGrU2m7YhLFY06qC1RCXe0EEJuXurVSwnAdIdAF/Z1Z0ePM+QNCv+56LViQ8PvtPiCpK2pghzcm+K6zHgFXnWfhrmgTcHJwkZYQrc4fSauSRKiM2KMSIrBStoswiU1R3bMeRl1claP+ZLUSIu3mIvLAS+Bs6Y+4tpFAffCaBSyyV7DPb2O+D7uYiumgDINt2FjQv1y8LnG32cb0p4+vuUc9VQ4/8ReNFk+/za70APlLSI+59fReAYfWoHE7yQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i5TuH6qm9sIaFJo9n3S0YOhfFMHRGf7qw6yT+OVI8Kwf+bjfjwEw1MWJfAigsBdlA7UG2S3RkzDF4Y9psNom4+DbiT0+X4zJjoDEKEkAnzHFMdS4rnbZyME4bQ87n1SzD2DarOihT9QlGKbq/ZYVcpWq8oErpA2i1c9bTy5hXH8TLvpReU9gV1S7eF3hcdvgwzEPSzN3KW8dSXvPvSLsVhKP2RhzOBrw9bKf7K+FK7mcMTwuoThFdmicKBEWiAE5dkgAmQwd2QpSz9u+Ftj+gQaWP+Uc2WJsJAuF5oRqVJEQ9nN4gYZFscvWnDzwMfChmwi7mMydqyNMnj8/NcU4LQ==
  • 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: Thu, 14 Dec 2023 09:03:39 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHaK4Q534ViUL7xiE2p4ymr6ObEurCkX+6AgAFU/YD//6xNgIABr6aAgAATSoCAAcFZAP//l6EAgACJ0wA=
  • Thread-topic: [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@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.
> 
> 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.

 


Rackspace

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