Nirmal Patel wrote: > On Thu, 12 Sep 2024 11:10:21 -0700 > Dan Williams <dan.j.williams@xxxxxxxxx> 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.
