From: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>,
Linux PCI <linux-pci@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 5/8] PCI PCIe portdrv: Fix allocation of interrupts
Date: Thu, 08 Jan 2009 17:20:30 +0900 [thread overview]
Message-ID: <4965B74E.8000309@jp.fujitsu.com> (raw)
In-Reply-To: <200901080813.47650.rjw@sisk.pl>
Rafael J. Wysocki wrote:
> On Thursday 08 January 2009, Kenji Kaneshige wrote:
>> Rafael J. Wysocki wrote:
>>> From: Rafael J. Wysocki <rjw@sisk.pl>
>>>
>>> If MSI-X interrupt mode is used by the PCI Express port driver, too
>>> many vectors are allocated and it is not ensured that the right
>>> vectors will be used for various services. Namely, the PCI Express
>>> specification states that both PCI Express native PME and PCI Express
>>> hotplug will always use the same MSI or MSI-X message for signalling
>>> interrupts, which implies that the same vector will be used by both
>>> of them. Also, the VC service does not use interrupts at all.
>>> Moreover, is not clear which of the vectors allocated by
>>> pci_enable_msix() will be used for PME and hotplug and which of them
>>> will be used for AER if all of these services are configured.
>>>
>>> For these reasons, rework the allocation of interrupts for PCI
>>> Express ports so that at most two vectors are allocated and ensure
>>> that the right vector will be used for the right purpose.
>>>
>>> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
>>> ---
>>> drivers/pci/pcie/portdrv.h | 1
>>> drivers/pci/pcie/portdrv_core.c | 155 +++++++++++++++++++++++++++++-----------
>>> 2 files changed, 117 insertions(+), 39 deletions(-)
>>>
>>> Index: linux-2.6/drivers/pci/pcie/portdrv.h
>>> ===================================================================
>>> --- linux-2.6.orig/drivers/pci/pcie/portdrv.h
>>> +++ linux-2.6/drivers/pci/pcie/portdrv.h
>>> @@ -25,6 +25,7 @@
>>> #define PCIE_CAPABILITIES_REG 0x2
>>> #define PCIE_SLOT_CAPABILITIES_REG 0x14
>>> #define PCIE_PORT_DEVICE_MAXSERVICES 4
>>> +#define PORT_MSI_VECTOR_MASK 0x1f
>>>
>>> #define get_descriptor_id(type, service) (((type - 4) << 4) | service)
>>>
>>> Index: linux-2.6/drivers/pci/pcie/portdrv_core.c
>>> ===================================================================
>>> --- linux-2.6.orig/drivers/pci/pcie/portdrv_core.c
>>> +++ linux-2.6/drivers/pci/pcie/portdrv_core.c
>>> @@ -30,55 +30,120 @@ static void release_pcie_device(struct d
>>> }
>>>
>>> /**
>>> + * fix_up_vectors - ensure the right ordering of MSI-X interrupt vectors
>>> + * @dev: PCI Express port that is going to use the vectors
>>> + * @vectors: Array of interrupt vectors to check (2 entries)
>>> + *
>>> + * Return value:
>>> + * 0 on success, error code if the values read from config registers are not as
>>> + * expected
>>> + *
>>> + * If this function is called, we are going to use two interrupt vectors which
>>> + * may be different, but we have to make sure they are in the right order such
>>> + * that the vector to be used for PME and hotplug signalling is the first one.
>>> + *
>>> + * NOTE: The assumption here is that MSI message offset (with respect to the
>>> + * base Message Data) equal to N corresponds to index N in the array of vectors
>>> + * returned by pci_enable_msix().
>>> + */
>> I've posted the similar patch recently, which doesn't have this
>> assumption.
>
> Actually, this assumption is in agreement with PCI Express Base Specification
> 2.0, which very clearly states in Section 7.8.2 that:
>
> "[...] Interrupt Message Number – This field indicates which
> MSI/MSI-X vector is used for the interrupt message generated in
> association with any of the status bits of this Capability structure.
>
> [...]
>
> For MSI-X, the value in this field indicates which MSI-X Table
> entry is used to generate the interrupt message. The entry must
> be one of the first 32 entries even if the Function implements
> more than 32 entries. For a given MSI-X implementation, the
> entry must remain constant."
>
Though I might be misunderstanding something, my understanding is
that this implies that there can be more MSI-X table entries than
number of interrupts, and PME/HotPlug or AER interrupts can be
mapped to other than first two entries. If my understanding is
correct, your patch would not work if PME/HotPlug or AER interrupts
were mapped to other than first two.
Regardless of my understanding is correct or not, I have another
concern. I think there are two interrupts for PCIe port service
currently as your patch indicates. But new interrupts can be added
in the future. With the assumption, PME/HotPlug and/or AER interrupts
would not work if the first several entries are mapped to other new
interrupts. Therefore, with the assumption, we need to fix MSI-X
initialization code whenever new interrupts are defined.
> Well, I have to update the comment. :-)
>
>> Please take a look.
>>
>> http://marc.info/?l=linux-pci&m=122992792507715&w=2
>
> OK, thanks. I can easily change my patch to follow this behavior, although
> I don't really think it's necessary given the above.
>
Please see above mentioned my concerns.
>> NOTE: I've confirmed MSI and INTx still work with my patch, but it
>> is not tested on the machine with MSI-X capable port, since I don't
>> have such environment.
>
> I also have tested my patch with both MSI and INTx, but I also don't have
> MSI-X capable root ports in any of my test boxes.
>
Though the patch is not tested with MSI-X capable ports, I think it
is much better than the current code.
Thanks,
Kenji Kaneshige
next prev parent reply other threads:[~2009-01-08 8:20 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-04 22:46 [PATCH 0/8] PCI Express port driver fixes and cleanups Rafael J. Wysocki
2009-01-04 22:48 ` [PATCH 1/8] PCI PCIe portdrv: Remove root ports MSI quirk Rafael J. Wysocki
2009-01-09 23:12 ` Jesse Barnes
2009-01-09 23:18 ` Jesse Barnes
2009-01-09 23:33 ` Rafael J. Wysocki
2009-01-04 22:49 ` [PATCH 2/8] PCI PCIe portdrv: Aviod using service devices with wrong interrupts Rafael J. Wysocki
2009-01-09 23:23 ` Jesse Barnes
2009-01-04 22:51 ` [PATCH 3/8] PCI PCIe portdrv: Remove unused device extension Rafael J. Wysocki
2009-01-09 23:23 ` Jesse Barnes
2009-01-04 22:54 ` [PATCH 4/8] PCI PCIe portdrv: Do not enable port device before setting up interrupts Rafael J. Wysocki
2009-01-09 23:25 ` Jesse Barnes
2009-01-04 22:55 ` [PATCH 5/8] PCI PCIe portdrv: Fix allocation of interrupts Rafael J. Wysocki
2009-01-08 3:02 ` Kenji Kaneshige
2009-01-08 7:13 ` Rafael J. Wysocki
2009-01-08 8:20 ` Kenji Kaneshige [this message]
2009-01-08 16:53 ` Rafael J. Wysocki
2009-01-08 20:45 ` Rafael J. Wysocki
2009-01-09 23:33 ` Jesse Barnes
2009-01-09 23:38 ` Rafael J. Wysocki
2009-01-13 2:47 ` Kenji Kaneshige
2009-01-13 11:17 ` Rafael J. Wysocki
2009-01-14 6:08 ` Kenji Kaneshige
2009-01-14 10:35 ` Rafael J. Wysocki
2009-01-14 10:57 ` Rafael J. Wysocki
2009-01-15 6:24 ` Kenji Kaneshige
2009-01-15 7:38 ` Hidetoshi Seto
2009-01-15 10:31 ` Kenji Kaneshige
2009-01-15 16:42 ` Rafael J. Wysocki
2009-01-15 19:05 ` Rafael J. Wysocki
2009-01-15 19:10 ` Rafael J. Wysocki
2009-01-16 7:33 ` Hidetoshi Seto
2009-01-16 9:29 ` Rafael J. Wysocki
2009-01-17 0:20 ` Rafael J. Wysocki
2009-01-19 1:52 ` Hidetoshi Seto
2009-01-19 6:27 ` Kenji Kaneshige
2009-01-13 2:34 ` Kenji Kaneshige
2009-01-04 22:57 ` [PATCH 6/8] PCI PCIe portdrv: Remove unnecessary function Rafael J. Wysocki
2009-01-04 22:59 ` [PATCH 7/8] PCI PCIe portdrv: Simplily probe callback of service drivers Rafael J. Wysocki
2009-01-07 12:15 ` Rafael J. Wysocki
2009-01-04 23:01 ` [PATCH 8/8] PCI PCIe portdrv: Remove struct pcie_port_service_id Rafael J. Wysocki
2009-01-07 12:16 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4965B74E.8000309@jp.fujitsu.com \
--to=kaneshige.kenji@jp.fujitsu.com \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=rjw@sisk.pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome