On Fri, 13 Sep 2024 16:25:41 +0530 Manivannan Sadhasivam <manivannan.sadhasivam@xxxxxxxxxx> wrote: > On Thu, Sep 12, 2024 at 05:01:57PM -0700, Dan Williams wrote: > > 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. > > In that case, we do not need a fix at all (even for VMD). My initial > assumption was that, some other userspace applications may also > behave the same way as SPDK. But I agree with you that unless we hear > about them, it doesn't warrant a fix in the kernel. Thanks! Okay, We can drop this patch for now. Thanks. > > - Mani >
