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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx> > > > > > > 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.
