From: Dan Williams <dan.j.williams@intel.com>
To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
Nirmal Patel <nirmal.patel@linux.intel.com>
Cc: <linux-pci@vger.kernel.org>, <paul.m.stillwell.jr@intel.com>
Subject: Re: [PATCH v2] PCI: vmd: Clear PCI_INTERRUPT_LINE for VMD sub-devices
Date: Thu, 12 Sep 2024 10:11:25 -0700 [thread overview]
Message-ID: <66e320bd9c800_3263b29421@dwillia2-xfh.jf.intel.com.notmuch> (raw)
In-Reply-To: <20240912143657.sgigcoj2lkedwfu4@thinkpad>
Manivannan Sadhasivam wrote:
> On Thu, Aug 22, 2024 at 11:30:10AM -0700, Nirmal Patel wrote:
> > On Thu, 22 Aug 2024 15:18:06 +0530
> > Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> wrote:
> >
> > > On Tue, Aug 20, 2024 at 03:32:13PM -0700, Nirmal Patel wrote:
> > > > VMD does not support INTx for devices downstream from a VMD
> > > > endpoint. So initialize the PCI_INTERRUPT_LINE to 0 for all NVMe
> > > > devices under VMD to ensure other applications don't try to set up
> > > > an INTx for them.
> > > >
> > > > Signed-off-by: Nirmal Patel <nirmal.patel@linux.intel.com>
> > >
> > > I shared a diff to put it in pci_assign_irq() and you said that you
> > > were going to test it [1]. I don't see a reply to that and now you
> > > came up with another approach.
> > >
> > > What happened inbetween?
> >
> > Apologies, I did perform the tests and the patch worked fine. However, I
> > was able to see lot of bridge devices had the register set to 0xFF and I
> > didn't want to alter them.
>
> You should've either replied to my comment or mentioned it in the changelog.
>
> > Also pci_assign_irg would still set the
> > interrupt line register to 0 with or without VMD. Since I didn't want to
> > introduce issues for non-VMD setup, I decide to keep the change limited
> > only to the VMD.
> >
>
> Sorry no. SPDK usecase is not specific to VMD and so is the issue. So this
> should be fixed in the PCI core as I proposed. What if another bridge also wants
> to do the same?
Going to say this rather harshly, but there is no conceivable universe I
can imagine where the Linux PCI core should be bothered with the
idiosyncracies of VMD. VMD is not a PCI bridge.
SPDK is fully capable of doing this fixup itself in the presence of VMD.
Unless and until this problem is apparent in more than just a kernel
bypass development kit should the kernel worry about it, and even then
the fixup must be contained to the VMD driver with all its other
workarounds that to try to get back to standards compliant PCI bridge
behavior.
next prev parent reply other threads:[~2024-09-12 17:11 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-20 22:32 [PATCH v2] PCI: vmd: Clear PCI_INTERRUPT_LINE for VMD sub-devices Nirmal Patel
2024-08-22 9:48 ` Manivannan Sadhasivam
2024-08-22 18:30 ` Nirmal Patel
2024-09-12 14:36 ` Manivannan Sadhasivam
2024-09-12 15:31 ` Nirmal Patel
2024-09-12 16:47 ` Manivannan Sadhasivam
2024-09-12 17:11 ` Dan Williams [this message]
2024-09-12 17:25 ` Manivannan Sadhasivam
2024-09-12 18:10 ` Dan Williams
2024-09-12 19:15 ` Nirmal Patel
2024-09-13 0:01 ` Dan Williams
2024-09-13 10:55 ` Manivannan Sadhasivam
2024-09-13 16:02 ` Nirmal Patel
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=66e320bd9c800_3263b29421@dwillia2-xfh.jf.intel.com.notmuch \
--to=dan.j.williams@intel.com \
--cc=linux-pci@vger.kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=nirmal.patel@linux.intel.com \
--cc=paul.m.stillwell.jr@intel.com \
/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;
as well as URLs for NNTP newsgroup(s).