Re: [dpdk-stable] [PATCH 2/2] igb_uio: fix interrupt enablement after FLR in VM

[Thomas Monjalon <thomas@monjalon.net>]

13/10/2017 22:54, Ferruh Yigit:
> On 10/9/2017 9:31 PM, Jingjing Wu wrote:
> > If pass-through a VF by vfio-pci to a Qemu VM, after FLR
> > in VM, the interrupt setting is not recoverd correctly
> > to host as below:
> >  in VM guest:
> >         Capabilities: [70] MSI-X: Enable+ Count=5 Masked-
> >  in Host:
> >         Capabilities: [70] MSI-X: Enable+ Count=5 Masked-
> > 
> > That was because in pci_reset_function, it first reads the
> > PCI configure and set FLR reset, and then writes PCI configure
> > as restoration. But not all the writing are successful to Host.
> > Becuase vfio-pci driver doesn't allow directly write PCI MSI-X
> > Cap.
> > 
> > To fix this issue, we need to move the interrupt enablement from
> > igb_uio probe to open device file. While is also the similar as
> > the behaviour in vfio_pci kernel module code.
> 
> So I guess this also explains why pci_reset in open() cause the problem,
> when this is called for VF, interrupts stays disable for both VF and PF?
> 
> > 
> > Fixes: b58eedfc7dd5 ("igb_uio: issue FLR during open and release of device file")
> > 
> > Cc: stable@dpdk.org
> > 
> > Signed-off-by: Jingjing Wu <jingjing.wu@intel.com>
> > Signed-off-by: Jianfeng Tan <jianfeng.tan@intel.com>
> 
> Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
> 
> 
> We have two options, getting this patch or revert the original patch,
> Thomas already has a patch for reverting.
> 
> The original patch is to make igb_uio safer. To not leave device in
> unwanted stated. Problem related to this has been reported a few times,
> I believe it is good to fix this problem. And since we already have some
> movement towards fix, I say lets continue instead of revert.
> 
> Only problem is the scope of the patch is wide, and in previous release
> it already break some uses cases, this is a little scary, please support
> on testing this more.
> 
> I suggest getting this fix for rc1 and let it to be tested properly, and
> if we hit some problem, we can always revert and work on problem for
> next release.

OK, let's try.

Harish, please help testing this patch with qede.

Thanks