From: Dan Williams <dan.j.williams@intel.com>
To: Nirmal Patel <nirmal.patel@linux.intel.com>,
Dan Williams <dan.j.williams@intel.com>
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
<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 17:01:57 -0700 [thread overview]
Message-ID: <66e380f5c8a50_3263b294c9@dwillia2-xfh.jf.intel.com.notmuch> (raw)
In-Reply-To: <20240912121513.000054b3@linux.intel.com>
Nirmal Patel wrote:
> On Thu, 12 Sep 2024 11:10:21 -0700
> Dan Williams <dan.j.williams@intel.com> wrote:
>
> > Manivannan Sadhasivam wrote:
> > [..]
> > > I don't think the issue should be constrained to VMD only. Based on
> > > my conversation with Nirmal [1], I understood that it is SPDK that
> > > makes wrong assumption if the device's PCI_INTERRUPT_LINE is
> > > non-zero (and I assumed that other application could do the same).
> >
> > I am skeptical one can find an example of an application that gets
> > similarly confused. SPDK is not a typical consumer of PCI device
> > information.
> >
> > > In that case, how it can be classified as the "idiosyncracy" of
> > > VMD?
> >
> > If VMD were a typical PCIe switch, firmware would have already fixed
> > up these values. In fact this problem could likely also be fixed in
> > platform firmware, but the history of VMD is to leak workaround after
> > workaround into the kernel.
>
> This is not VMD leaking workaround in kernel, rather the patch is
> trying to keep fix limited to VMD driver.
Oh, ok, I see that now, however...
> I tried over 10 different NVMes and only 1 vendor has
> PCI_INTERRUPT_LINE register set to 0xFF. The platform firmware
> doesn't change that with or without VMD.
...SPDK is still asserting that it wants to be the NVME host driver in
userspace. As part of that it gets to keep all the pieces and must
realize that a device that has MSI/-X enabled is not using INTx
regardless of that register value.
Do not force the kernel to abide by SPDK expectations when the PCI core
/ Linux-NVME driver contract does not need the PCI_INTERRUPT_LINE
cleared. If SPDK is taking over NVME, it gets to take over *all* of it.
next prev parent reply other threads:[~2024-09-13 0:02 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
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 [this message]
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=66e380f5c8a50_3263b294c9@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