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. 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 not tied to VMD, isn't it? > > It is not, but SPDK replaces significant pieces of the kernel with > userspace drivers. In this respect a VMD driver quirk in SPDK is no > different than the NVME driver quirks it already needs to carry in its > userspace NVME driver. > > Now, if you told me that the damage was more widespread than a project > that is meant to replace kernel drivers, then a kernel fix should be > explored. Until then, let SPDK carry the quirk until it becomes clear > that there are practical examples of wider damage.
